Exploring Requirements

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:

• remember previous print settings
• print the entire document to the default printer with the minimum number of steps
• perform operations common to competing products, using the same conceptual steps

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.

REMEMBER previous print settings

Just remember it? What else do you do with it? Oh, you mean "remember and automatically apply it"?

Remember PREVIOUS print settings

Not the current print setting? (This is a question that's likely to get the answer "it's obvious what was meant". Well, sometimes it is, sometimes it isn't. Make sure. What if what you think is obvious is exactly the opposite of what the customers think?)

Which previous print setting? Maybe this latest printing shouldn't change what was remembered. Maybe there's a need to remember several different print settings for different purposes: "print final copy," "print double-spaced review copy," etc.

Remember previous PRINT settings

Are there other settings a user might want to remember?

Remember previous print SETTINGS

What is a setting? Perhaps it's "whatever the user wants to remember," in which case it might not be everything in the dialog box.

These heuristics and tricks of the trade make the book essential. However, the book suffers from two substantial flaws:

1. It appears to provide a step-by-step process for discovering requirements, mainly in Part IV, but that process is essentially impossible to follow. There are too many gaps in the presentation.
2. It contains a flood of ideas, many of them presented without enough depth. I'd have particularly appreciated discussions of common pitfalls. (It would have saved me some embarrassment.)

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.

This book will help you with the following tasks

Click on the task name to see other works that address the same task.

Discovering requirements

The best book for this task.

Having meetings

There are brief chapters on making meetings work and the special role of the facilitator. There's a chapter on the important technique of brainstorming.

Inspecting or reviewing

A brief overview of the subject.

Notes on using this book

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.

This book's table of contents

Part I - Negotiating a Common Understanding

1. Methodologies Aren't Enough
2. Ambiguity in Stating Requirements
3. Sources of Ambiguity
4. The Tried but Untrue Use of Direct Questions

Part II - Ways to Get Started

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

Part III - Exploring the Possibilities

10. Idea-Generation Meetings
11. Right-Brain Methods
12. The Project's Name
13. Facilitating in the Face of Conflict

Part IV - Clarifying Expectations

14. Functions
15. Attributes
16. Constraints
17. Preferences
18. Expectations

Part V - Greatly Improving the Odds of Success

19. Ambiguity Metrics
20. Technical Reviews
21. Measuring Satisfaction
22. Test Cases
23. Studying Existing Products
24. Making Agreements
25. Ending