by Donald C. Gause and Gerald M. Weinberg
(Dorset House, 1989, ISBN 0-932633-13-7)
reviewed by Brian Marick on October 17, 1996
Buy this book from fatbrain.com technical bookstore
From the preface:
"Development is the process of transforming someone's desires into a product that satisfies those desires. This book is about the requirements process - the part of development in which people attempt to discover what is desired.
"To understand this process, the reader should focus on five critical words: desire, product, people, attempt, and discover.
"First, consider the word "desire". Some readers would prefer that we say "attempt to discover what is needed", but we don't know how to figure out what people need, as opposed to what they desire. Besides, people don't always buy what they need, but they always desire what they buy, even if the desire is only transitory. We do observe, however, that by clarifying their desires, people sometimes clarify what they really need and don't need."
Everyone agrees that inadequate requirements are a major reason for product failure, but that's about as far as agreement goes. We don't even agree on what we mean by the word "requirement". Much of the writing about requirements seems to me descriptions of how to rigorously describe a slightly abstracted version of the product interface, especially the user interface. I think that misses the point. What if the user interface is wrong? A small example of this is the print dialog box in a certain semi-popular word processor. It remembers previous print settings, which seems like a nice service but isn't. For example, suppose that you change one page in a document (adding a copyright notice to the title page, for example), then print that one page. Two months later, someone asks for a copy of the document. You enter the word processor, select 'Print', hit OK. You expected a copy of the document. Instead, you get a copy of the title page.
This particular example is not a big deal - although this particular product's collection of similar mis-steps caused me at one point to hurl the user's manual across the room, only the second time I've ever done that. The question is, how can such annoyances - and more fatal flaws - be avoided? Not by describing them more unambiguously. No, we need some way to represent user desires, explore user desires, and rank user desires. This product's makers needed a set of requirements like:
The second and third requirements should prevent the particular mis-implementation I described.
Now, these requirements are not particularly rigorous, but it's more important that they exist. Since people are not inherently rigorous, premature rigor will lead to overlooked requirements. It's better to do what you need to do to get the requirements down, then improve them. Unfortunately, "what you need to do" is fuzzy, maddeningly imprecise, dependent on circumstance - in a word, human. Gause & Weinberg's book discusses techniques for finding requirements, then improving them.
One way to improve requirements is to remove ambiguity. The "Mary had a little lamb heuristic" is a good example of the book's style. To use it, you say each requirement out loud, unnaturally emphasizing each word in turn, and think about what such a strong emphasis implies. As an example, I'll apply the heuristic to the first requirement above.
These heuristics and tricks of the trade make the book essential. However, the book suffers from two substantial flaws:
I've read this book twice and recommend it - it's really the only game in town - but I look forward to the rumored sequel.
Click on the task name to see other works that address the same task.
One of the hardest tasks in requirements work is winnowing the set of possible requirements down to the ones you should implement. This book doesn't help much. Microsoft Secrets describes activity-based planning, which Microsoft uses to select requirements for new releases of existing products. Crossing the Chasm describes target-customer characterization, which is a similar process but focused more on new products.
1. Methodologies Aren't Enough
2. Ambiguity in Stating Requirements
3. Sources of Ambiguity
4. The Tried but Untrue Use of Direct Questions
5. Starting Points
6. Context-Free Questions
7. Getting the Right People Involved
8. Making Meetings Work for Everybody
9. Reducing Ambiguity from Start to Finish
10. Idea-Generation Meetings
11. Right-Brain Methods
12. The Project's Name
13. Facilitating in the Face of Conflict
19. Ambiguity Metrics
20. Technical Reviews
21. Measuring Satisfaction
22. Test Cases
23. Studying Existing Products
24. Making Agreements