This review covers Exploring Requirements: Quality Before Design by Donald Gause and Gerald Weinberg. New York: 1989, Dorset House Publishing.
On page 1, the authors summarize the outcome of experiments they performed to find out “how computer programmers were influenced by what they were asked to do”. Their conclusions based on these experiments were:
- If you tell what you want, you’re quite likely to get it.
- If you don’t tell what you want, you’re quite unlikely to get it.
The book is about getting to a shared understanding of what your product should be, for the purpose of making it much more likely you’ll get that.
Some interesting topics the book covers:
- Costs of ambiguity (p.17), and how to avoid it
- The side effects a hastily chosen project name can have on the design of the product (p. 57)
- How to design meetings so they minimize wasted time (p.89)
- Arguments about facts in the future (p.143)
- Functions, Attributes, Constraints, Preferences, and Expectations (chapters 14-18)
- The value of making requirements traceable, so designers can tell where they came from (choices versus assumptions versus impositions, chapter 24). For example (p.271):
2. The elevators will travel vertically only.
2. The elevators will travel vertically only because none of the states in our marketing area legally allow nonvertical elevators.
2. The elevators will travel vertically only because we don’t see any appreciable market for nonvertical elevators at this time.
The difference could be important for designers to know.
Things That I Found Helpful
(This book is enough outside of my area of expertise that I hesitate to use my normal “Good/Bad” categories.)
- Chapters are short and to the point.
- Not only points out dangers, but provides help in avoiding them.
- Helps you remember to move on. Example: Chapter 12 explores the influence a project’s name has on the project, but also notes that you need to know when to move on. (“At some point…we’ll stop and use what we have because the important thing is not the name, but the naming” (p.132)). Another example: Chapter 11 talks about the value of sketching rather than trying to be too precise early in the process (pp. 120-121).
- Gives good reasoning for things. For example:
Some people resist black box testing of requirements with the argument that this opens the danger of “studying for the test.” They fear that the designers will build a product or system that does no more than these tests specify, rather than one that will be wise enough to cover cases nobody thought of. Well, if the designer knows other important questions and their proper answers, why not put them on the list? There they will be subject to public scrutiny and also be available for constructing acceptance tests. (p.257)
- The Studying Existing Products chapter (Chapter 23) provides guidance for when you’re developing a new product that is akin to an existing product: ways to make sure that the new product is like the old one where it should be and not where it shouldn’t be.
- Chapter 25, “Ending”, provides helpful thoughts on the courage, risk-taking, and professionalism necessary to do good requirements work.
The requirements phase ends with agreement, but the requirements work never ends until the product is finished. There simply comes a moment when you decide you have enough agreement to risk moving on into the design phase (p. 277).
The purpose of requirements work is to avoid making mistakes, and to do a complete job. In the end, however, you can’t avoid all mistakes, and you can’t be omniscient. If you can’t risk being wrong, if you can’t risk being inadequate to the task you’ve taken on, you will never succeed in requirements work. If you want the reward, you will have to take the risk (pp.282-283).
Things I Wished For
- Could use an update. It’s twenty years old and cites experiments performed ten years before that. (I doubt that the nature of large-scale human efforts has really changed since then though.)
- Doesn’t address agile software development (being written in 1989!). I’m thinking that changes in light of agile principles would affect more the organization-level aspects (suggested meetings, client interactions) than the specific advice. Would delivering working software obviate the need for some of these activities? It would be neat to see the author’s opinion on this.
The book covers a topic that is outside of my day-to-day responsibilities: by the time work gets to me the requirements have solidified quite a bit. But sometimes things slip through as undocumented assumptions and bite us later. This book raised my awareness of some common places those assumptions sneak in and gave me some simple tools to help turn them into documented decisions.
To use the book as I did was 283 pages of quick reading. There’s more depth available if more of your work involves exploring requirements (how to run effective meetings, questions to ask clients, etc.)
I recommend this book.