Gottesdiener describes a way to get requirements right. The technique combines a meeting format dating from the 1970s with modeling from the 1990s. The format requires the leader to find out and record what worked best and worst in each “workshop.” In this book, the author shares the results. The result is flexible, but not cheap.

This is a handbook for facilitators who are running workshops to elicit software requirements. It is not a textbook, and adds nothing to current research. Nevertheless, I may make it part of the reading list for students in my Computer Systems undergraduate course. Practitioners with large projects need this book, as well as books on modeling. Object zealots may prefer Graham [1], because Gottesdiener does not use objects. She mentions one object-oriented technique, class-responsibility-collaboration (CRC) on page 246, and notes that it left the team confused.

The book has three parts. The first part, “Overview,” has three chapters. Chapter 1 provides the motivation and history. Requirements workshops arose from joint applications development (JAD). Pages 17 and 18 describe projects where requirements workshops are not useful. Chapter 2 classifies 19 models of requirements; the book describes how to select the right ones for different situations. To describe these models, the author uses text, tables, and diagrams. She includes prototypes and glossaries as models. Models are presented using use cases, scenarios, statecharts, entity relationship diagrams, and so on. Chapter 3 introduces 14 ingredients of a good workshop, which are discussed in detail later in the book. This chapter makes it clear that the leader has to take time to plan the meeting; a one-day workshop takes a day of preparation. The facilitator must then be ready to change plans as the meeting unfolds.

The second part covers the “Six P’s”: purpose, participants, principles, products, place, and process. It places them in a 14-step cycle. Chapter 4 describes how the facilitator diagnoses problems. The facilitator, with a planning team, works out the purpose and program for the workshop. This includes noting risks and contingency plans. The plan also states what the participants must prepare for the meeting. Chapter 5 looks at the participants. The facilitator, recorder (or “technographer”), observers, and sponsor play special roles. The stakeholders (customers, suppliers, and users) do the work. Here, the author gives much good advice. Chapter 6 describes how the facilitator starts the workshop, by helping the participants agree on some principles governing the meeting; getting commitment to these is important. The discussion of decision-making rules is valuable. Chapter 7 describes workshop products. These include pre-work and intangibles like decisions and issues. Chapter 8 is about the location of the workshop. It discusses equipment, layout, and preparation. Gottesdiener warns the facilitator to check the room days before the meeting. The chapter also covers electronic communication. Apparently, meetings distributed in time and space work well only when the group has already gelled. Chapter 8 describes the detailed programming of a workshop. Collaboration patterns contribute to designing a workable process; these are described in an appendix. Chapter 8 also gives the reader hints for handling problem participants.

The third part of the book has three chapters. Chapter 10 presents alternative sequences for moving between models. Chapter 11 describes four particular workshops as case studies. For each, the author explains the problems, the process chosen, and the good and bad outcomes. This is the best chapter in the book. Finally, chapter 12 is about activities for facilitators after the workshop. Facilitators must evaluate workshops and seek feedback. They need to assemble the business case for future workshops. This chapter also provides resources for improving the facilitator’s skills and knowledge.

The book includes cartoons in the text, and has a preface, appendix, bibliography, glossary, and an index. It is supported by an excellent Web site. The cartoons are well done and appropriate. The appendix describes a set of “collaboration patterns.” These are eight ways for a group to solve problems by working together. For each, the author provides a name, context, problem, solution, consequences, entry and exit criteria, and when it should be used.

Some editing would improve the book. It needs better citations and definitions. The definitions of “use case,” “lateral thinking,” “force field,” and “flow” may surprise their originators (Jacobson, de Bono, Lewin, and Csikzentmihalyi respectively). The bibliography is also incomplete.