"provides an excellent set of principles
amply illustrated by relevant and thought-provoking examples."
- Barry Boehm, UCLA
"Anyone who wants to build a product should understand this book."
- Watts S. Humphrey, Software Engineering Institute of Carnegie Mellon University
Order now from Dorset House Books!
(translated into Japanese, Portuguese, German, Chinese)
A high-quality requirements process is an essential part of producing quality software. This book explores all aspects of the requirements process, developing practical new techniques and putting new vigor into old ones. It shows how to get all essential parties involved, test requirements, measure user satisfaction, ensure coverage of all requirements, detect and remove ambiguity, facilitate various types of requirements meetings, handle conflicting notational systems, and precisely defining functions, constraints, preferences, and expectations. The information in this book will allow you to improve your present requirements process, regardless of what you are now doing.
A classic that will be around a decade from now, March 26, 2001
Reviewer: Mike Tarrani from Tustin, CA USA (Source: Amazon.com)
In the decade since I last read this book I've gained a wealth of experience in requirements elicitation and management. So why bother re-reading the book and taking the time to write a review? Because I strongly believe that this is one of the classics and should be *required* reading by anyone in the IT profession (it also crosses over into just about any profession).
What makes this book a classic? After all, we practitioners have software tools such as DOORS and Requisite Pro, advanced techniques such as quality function deployment, specialized modeling languages such as UML, and a keener understanding of the importance in business rules.
All of these innovations and advances are technical in nature. The authors address something much deeper and more fundamental that will apply a decade from now: human nature and critical thinking. They lead you to an understanding of these keys to exploring requirements, and they do so in with subtle humor, common sense and clear writing. One example of how they delve into the deeper subjects of human nature and critical thinking is a true story about an advertisement for a "cockroach killer" that is guaranteed to be 100% effective. After your initial chuckles die down you begin to see things in a different way. The authors lead you from this humorous story into one discussion or example after another and how they apply to requirements. By the time you finish this book you will begin looking at the requirements process in a different way, and perhaps, the world around you as well. You will also approach the requirements elicitation and management process differently - all of a sudden those wonderful requirements management software tools and techniques will become the infrastructure of the process instead of the necessities for performing that they too often become.
This is not a technical book. If you are looking for advanced techniques look elsewhere. This book is about shaping how you see things, think and apply principles to "techniques". I personally believe it will remain a classic for many years to come, and strongly encourage IT professionals, regardless of their technical specialty, to read it.
----
Essential Reading, July 24, 2000
Reviewer: Daniel Read from Atlanta, GA USA (Source: Amazon.com)
By no means have I read everything there is to read on the subject of software requirements, but I've not read anything better than this book. What I really like about this book, and about Weinberg's writings in general, is that it does not get bogged down in a bunch of academic methodology mumbo jumbo. Gause and Weinberg's approach is imminently practical and free of buzzwords and complicated steps and models and CASE tools. No special equipment or licensing is required in order to take the advice in this book and make a huge difference in your current and future projects.
That said, do not let me give the impression that this book is vague or that it does not get into specifics or that it does not contain some useful step-by-step approaches. It is not vague at all, and it gets into plenty of specifics. What impresses me the most is the way it achieves complete coverage of the subject without bogging down or becoming boring. After reading this book, it is very likely that you will not feel the need to read much else on the subject of software requirements.
Now, what is most amazing is this: this is *not* specifically a book about *software* requirements. It is about any kind of requirements for any kind of project that requires a design, be it a new and better mousetrap or a large software system. My comments have used the term "software requirements" because this is why I read the book, and why I think a lot of people will read it. But this book is for anyone who must specify the requirements for something that must be designed and/or built, no matter what field you are in. The lessons here are so univeral that it does not matter which context you use them in. Essential reading.
Preface
"There's no sense being exact about something if you don't even know what you're talking about." - John von Neumann
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.
By "product", we mean any product that attempts to satisfy a complex set of desires. One reason the desires are complex is that they come from many people. When we create a product to satisfy our own desires--as when we build a garden, for example, or a bookcase -- we don't often need an explicit requirements process. We simply build something, look at it, and make adjustments until we are satisfied.
But "people" might include many different people, and discovering who "people" are is a major part of the requirements process. When many people are involved--and when the product is large--the kind of iterative process used to discover personal requirements may simply prove too drawn out, too costly, and too risky.
What about "attempt"? If we're writing a book, shouldn't we be more certain, more certain, more positive? Shouldn't we guarantee results? Well, we've used the requirements techniques in this book to help our clients develop all types of products--computer hardware, computer software, automobiles, furniture, buildings, innovative consumer products, books, films, organizations, training courses, and research plans. Nobody yet has demanded money back, but we can't prove no client ever will, because we do not know how to make product development into an exact discipline.
Before working with us, many of our clients hoped that product development was an exact discipline. Many of those clients were in the software business--a business that has been plagued by ill-founded fantasies of an exact discipline for development products. We like to quote John von Neumann because many of our clients consider him to be the founding father of software. They pay attention when he says, "There's no sense being exact about something if you don't even know what you are talking about."
If people don't know what they want, no development process--no mater how exact, how clever, or how efficient--will satisfy them. And that's why we do requirements work--so we don't design systems that people don't want.
Effectiveness always comes before efficiency. But even if efficiency is your hot button, the most important route to efficiency in development is to eliminate those products nobody wanted in the first place. Another way to put this is,
Anything not worth doing is not worth doing right.
Which brings us to "discover," the most critical word. In this book, we're trying to help people discover what's really worth doing.
Dwight Eisenhower once said, "The plan is nothing; the planning is everything." We agree, and we also extend the same thinking to the requirements process:
The product is nothing; the process is everything.
Or, put another way,
The discovery is nothing the discovering (the exploring) is everything.
which explains the title, Exploring Requirements.
A data dictionary, for example, is a way of preserving the definitions that are painstakingly derived with the aid of some of the methods in this book. In practice, however, hardly anybody reads the data dictionary, or possibly any of the documents that are developed in the requirements process. That observation bothers some people, but not us because we believe that
The document is nothing; the documenting is everything.
If you watch how people really develop systems, you'll see that the process of developing requirements is actually a process of developing a team of people who:
1. understand the requirements
2. (mostly) stay together to work on the project
3. know how to work effectively as a team
We believe that if one of these conditions is not met, the project will probably fail. Of course, there are many other reasons why a product development project might fail, and there are many books about methods to avoid such pitfalls. This book, however, will concentrate on these three critical but neglected human aspects of the requirements process:
1. developing a consistent understanding of requirements among all participant2. developing the desire to work as a team on the project
3. developing the necessary skills and tools for working effectively as a team to define requirements
Because these topics are somewhat neglected in the systems development literature, Exploring Requirements can be used as a supplement to any requirements process that you now use, formal or informal. Most of the chapters are designed as standalone modules, each presenting one of more tools or methods to enhance your requirements process. You can read the book from cover to cover, or read only the one chapter that's most needed at any given moment. Either way, it should help you do a better job of knowing what you're talking about.
Acknowledgments vi
Preface xv
Part I: Negotiating a Common Understanding 1
1. Methodologies Aren't Enough 3
1.1. CASE, CAD, and the Cockroach Killer 3
1.2 Methods' Effects on Problems 4
1.3 Maps and Their Notation 6
1.4 Making Sure that Everyone Can Read the Map 8
1.5 Maps of Requirements Are Not Requirements 9
1.6 Helpful Hints and Variations 9
1.7 Summary 12
2. Ambiguity in Stating Requirements 14
2.1 Examples of Ambiguity 14
2.1.1 Missing requirements 16
2.1.2 Ambiguous words 16
2.1.3 Introduced elements 16
2.2 Cost of Ambiguity 17
2.3 Exploring to Remove Ambiguity 19
2.3.1 A picture of requirements 19
2.3.2 A model of exploration 20
2.4 Helpful Hints and Variations 21
2.5 Summary 21
3. Sources of Ambiguity 22
3.1 An Example: The Convergent Design Processes Lecture 22
3.2 A Test for Attentiveness 25
3.3 The Clustering Heuristic 26
3.3.1 Observational and recall errors 28
3.3.2 Interpretation errors 28
3.3.3 Mixtures of sources of error 29
3.3.4 Effects of human interaction 29
3.4 Problem statement Ambiguity 30
3.5 Helpful Hints and Variations 32
3.6 Summary 32
4. The Tried but Untrue Use of Direct Questions 34
4.1 Decision Trees 34
4.1.1 Order of questions 36
4.1.2 Traversing the decision tree: an example 36
4.2 Results of an Ambiguity Poll 42
4.3 What Could Possibly be Wrong? 43
4.4 Real Life Is More Real Than We Like to Think 44
4.5 Helpful Hints and Variations 44
4.6 Summary 45
Part II: Ways to Get Started 47
5. Starting Points 49
5.1 A Universal Starting Point 49
5.2 Universalizing a Variety of Starting Points 50
5.2.1 Solution idea 50
5.2.2. Technology idea 51
5.2.3 Simile 52
5.2.4 Norm 53
5.2.5 Mockup 53
5.2.6 Name 54
5.3 The Can-Exist Assumption 55
5.4 An Elevator Example 55
5.4.1 Naming our project 56
5.5 Helpful Hints and Variations 57
5.6 Summary 58
6. Context-Free Questions 59
6.1 Context-Free Process Questions 59
6.2 Potential Impact of a Context-Free Questions 60
6.3 Context-Free Questions 61
6.4 Metaquestions 62
6.5 Advantages of Context-Free Questions 64
6.6 Helpful Hints and Variations 65
6.7 Summary 67
7. Getting the Right People Involved 68
7.1 Identifying the Right People 68
7.1.1 Customers versus users 68
7.1.2 Why include the users? 69
7.1.3 The Railroad Paradox 69
7.1.4 The product can create users 70
7.1.5 Are losers users? 71
7.2 A User-Inclusion Heuristic 72
7.2.1 Listing possible user constituencies 72
7.2.2 Pruning the user list 73
7.3 Participation 74
7.3.1 Who participates? 74
7.3.2 When do they participate? 76
7.3.3 How do we get their judgments? 76
7.4 Plan for Capturing Users 77
7.5 Helpful Hints and Variations 78
7.6 Summary 78
8. Making Meetings Work for Everybody 80
8.1 Meetings: Tools We Can't Live With, or Without 80
8.1.1 A terrible, but typical, meeting 80
8.1.2 Meetings as measurements 83
8.2 Participation and Safety 84
8.2.1 Establishing an interruption policy 84
8.2.2 Setting time limits 84
8.2.3 Outlawing personal attacks and put-downs 85
8.2.4 Reducing pressure 85
8.3 Making It Safe Not to Attend a Meeting 86
8.2.1 Publishing an agenda and sticking to it 87
8.3.2 Staying out of emergency mode 87
8.3.3 Handling people who don't belong 87
8.3.4 Including the right people 89
8.4 Designing the Meeting You Need 89
8.5 Helpful Hints and Variations 89
8.6 Summary 91
9. Reducing Ambiguity from Start to Finish 92
9.1 Using the Memorization Heuristic 92
9.2 Extending the Ambiguity Poll 93
9.3 "Mary had a little lamb" Heuristic 94
9.4 Developing the "Mary conned the trader" Heuristic 95
9.5 Applying the Heuristics to the Star Problem 97
9.6 Helpful Hints and Variations 101
9.7 Summary 102
Part III: Exploring the Possibilities 105
10. Idea-Generation Meetings 109
10.1 A Typical Brainblizzard 109
10.2 First Part of the Brainstorm 111
10.2.1 Do not allow criticism or debate 111
10.2.2 Let your imagination soar 111
10.2.3 Shoot for quantity 112
10.2.4 Mutate and combine ideas 114
10.3 Second Part of the Brainstorm 115
10.3.1 Voting with a threshold 116
10.3.2 Voting with campaign speeches 117
10.3.3 Blending ideas 117
10.3.4 Applying criteria 117
10.3.5 Scoring or ranking systems 117
10.4 Helpful Hints and Variations 117
10.5 Summary 118
11. Right-Brain Methods 120
11.1 Mapping Tools 120
11.1.1 Sketching 120
11.1.2 Sketching Wiggle Charts 122
11.2 Braindrawing 123
11.3 Right-Braining 123
11.4 Helpful Hints and Variations 125
11.5 Summary 127
12. The Project's Name 128
12.1 Working Titles, Nicknames, and Official Names 128
12.2 The Influence of Names 129
12.2.1 A naming demonstration 129
12.2.2 What naming accomplishes 131
12.3 The Naming Heuristic 132
12.4 Helpful Hints and Variations 134
12.5 Summary 134
13 Facilitating in the Face of Conflict
13.1 Handling the Inessential Conflicts 136
13.1.1 Wrong time, wrong project 137
13.1.2 Personality clashes 137
13.1.3 Indispensable people 138
13.1.4 Intergroup prejudice 139
13.1.5 Level differences 139
13.2 The Art of being Fully Present 140
13.3 Handling Essential Conflicts 141
13.3.1 Reframing personality differences 141
13.3.2 Negotiating 143
13.3.3 Handling political conflicts 144
13.4 Helpful Hints and Variations 144
13.5 Summary 145
Part IV: Clarifying Expectations 147
14. Functions 149
14.1 Defining a Function 149
14.1.1 Existence function 149
14.1.2 Testing for a function 150
14.2 Capturing All and Only Functions 150
14.2.1 Capturing all potential functions 150
14.2.2 Understanding evident, hidden, and frill functions 152
14.2.3 Identifying overlooked functions 155
14.2.4 Avoiding implied solutions 156
14.2.5 The "Get It If You Can" List 157
14.3 Helpful Hints and Variations 158
14.4 Summary 159
15. Attributes 161
15.1 Attribute Wish List 161
15.2 Transforming the Wish List 163
15.2.1 Distinguishing between attributes and attribute details 163
15.2.2 Uncovering attribute ambiguity 163
15.2.3 Organizing the list 164
15.2.4 Discovering insights from the transformed list 165
15.3 Assigning Attributes to Functions 166
15.3.1 How attributes can modify functions 166
15.3.2 Gaining insights from the new format 167
15.4 Excluding Attributes 167
15.4.1 Categorizing into must, want, and ignore attributes 167
15.4.2 Implicit versus explicit elimination of attributes 168
15.5 Helpful Hints and Variations 169
15.6 Summary 169
16. Constraints 171
16.1 Defining Constraints 171
16.2 Thinking of Constraints as Boundaries 172
16.3 Testing the Constraints 174
16.3.1 Too strict? 174
16.3.2 Not strict enough? 175
16.3.3 Unclear? 176
16.3.4 Generating new ideas 176
16.4 Interrelated Constraints 177
16.5 Overconstraint 179
16.6 Psychology of Constraints 180
16.6.1 The tilt concept 180
16.6.2 Breaking constraints 181
16.6.3 The self-esteem bad-design cycle 182
16.7 Constraint Produces Freedom 182
16.7.1 Standards 182
16.7.2 Languages and other tools 183
16.8 Helpful Hints and Variations 183
16.9 Summary 185
17. Preferences 186
17.1 Defining a Preference 187
17.1.1 An example 187
17.1.2 The origin of preferences 188
17.2 Making Preferences Measurable 188
17.2.1 A reasonable approach to metrics 188
17.2.2 Making the preference measurable 189
17.3 Distinguishing Between Constraints and Preferences 189
17.3.1 Is meeting the schedule a constraint? 190
17.4 Constrained Preferences 191
17.4.1 What's-it-worth? graphs 192
17.4.2 When-do-you-need-it? graphs 193
17.5 Reframing Constraints into Preferences 194
17.5.1 Trading off among preferences 195
17.5.2 Zeroth Law of Product Development 198
17.6 Helpful Hints and Variations 198
17.7 Summary 199
18. Expectations 201
18.1 Reasons to Limit Expectations 201
18.1.1 People are not perfect 202
18.1.2 People are not logical 202
18.1.3 People perceive things differently 202
18.1.4 Designers are people too 204
18.2 Applying the Expectation Limitation Process 204
18.2.1 Generate a specific expectation list 204
18.2.2 The elevator example 204
18.2.3 Generalize the expectation list 206
18.2.4 Limit the expectations 208
18.3 Limitations Need Not Be Limiting 209
18.3.1 The wheelchair example 209
18.3.2 Keeping possibilities open 209
18.3.3 Include the source of the limitation 210
18.4 Helpful Hints and Variations 210
18.5 Summary 212
Part V: Greatly Improving the Odds of Success 215
19. Ambiguity Metrics 217
19.1 Measuring ambiguity 217
19.1.1 Using the ambiguity poll 217
19.1.2 Applying the polling method 218
19.1.3 Polling on different bases 218
19.2 Using the Metric as a Test 219
19.2.1 Measuring three kinds of ambiguity 219
19.2.2 Interpreting the results 220
19.2.3 Information from clustering 221
19.2.4 Choosing the group to be polled 221
19.3 Helpful Hints and Variations 222
19.4 Summary 223
20. Technical Reviews 225
20.1 A Walkover Example 225
20.2 The Role of Technical Reviews 227
20.2.1 Formal and informal reviews 227
20.2.2 Technical reviews versus project reviews 228
20.3 Review Reports 230
20.3.1 Need for review reports 230
20.3.2 Creating the issues list 231
20.3.3 Technical review summary report 232
20.4 Principal Types of Review 232
20.4.1 Vanilla reviews 233
20.4.2 Inspections 234
20.4.3 Walkthroughs 234
20.4.4 Round robin reviews 234
20.5 Real Versus Ideal Reviews 235
20.6 Helpful Hints and Variations 236
20.7 Summary 236
21. Measuring Satisfaction 238
21.1 Creating a User Satisfaction Test 238
21.1.1 Test attributes 238
21.1.2 A custom test for each project 239
21.2 Using the Test 240
21.2.1 Benefits 241
21.2.2 Plotting shifts and trends 241
21.2.3 Interpreting the comments 242
21.2.4 Feelings are facts 242
21.3 Other Uses of the Test 244
21.3.1 A communication vehicle 244
21.3.2 Continued use throughout the project 245
21.3.3 Use by designers 245
21.4 Other Tests 246
21.4.1 Prototypes as satisfaction tests 246
21.5 Helpful Hints and Variations 247
21.6 Summary 248
22. Test Cases 249
22.1 Black Box Testing 249
22.1.1 External versus internal knowledge 249
22.1.2 Constructing black box test cases 250
22.1.3 Testing the test cases 251
22.2 Applying the Test Cases 252
22.2.1 Examples 252
22.2.2 Iterating tests and answers 254
22.2.3 Clearly specifying ambiguity 255
22.3 Documenting the Test Cases 256
22.4 Helpful Hints and Variations 257
22.5 Summary 258
23. Studying Existing Products 260
23.1 Use of the Existing Product as the Norm 260
23.2 Interviewing 261
23.2.1 What's missing in the new product? 262
23.2.2 Why is it missing? 262
23.2.3 What's missing in the old product? 263
23.2.4 What's missing in the old requirements? 263
23.3 Substituting Features for Functions 264
23.4 Helpful Hints and Variations 266
23.5 Summary 266
24. Making Agreements 268
24.1 Where Decisions Come From 268
24.1.1 Choices, assumptions, and impositions 268
24.1.2 Elevator design decision examples 269
24.1.3 Writing traceable requirements 271
24.2 Where False Assumptions Come From 271
24.2.1 Lack of valid information 272
24.2.2 Invalidation over time 272
24.2.3 The turnpike effect 272
24.2.4 Requirements leakage 272
24.3 Converting Decisions to Agreements 273
24.4 Helpful Hints and Variations 274
24.5 Summary 275
25. Ending 277
25.1 The Fear of Ending 277
25.2 The Courage to End It All 277
25.2.1 Automatic design and development 278
25.2.2 Hacking 279
25.2.3 Freezing requirements 280
25.2.4 The renegotiation process 280
25.2.5 The fear of making assumptions explicit 281
25.3 The Courage to Be Inadequate 282
25.4 Helpful Hints and Variations 283
25.5 Summary 285
Bibliography 285
Index 293