Mastering the Requirements Process, 2nd Edition
- By Suzanne Robertson, James C. Robertson
- Published Mar 17, 2006 by Addison-Wesley Professional.
Book
- Sorry, this book is no longer in print.
Also available in other formats.
Register your product to gain access to bonus material or receive a coupon.
Description
- Copyright 2006
- Edition: 2nd
- Book
- ISBN-10: 0-321-41949-9
- ISBN-13: 978-0-321-41949-1
"If the purpose is to create one of the best books on requirements yet written, the authors have succeeded."
—Capers Jones
It is widely recognized that incorrect requirements account for up to 60 percent of errors in software products, and yet the majority of software development organizations do not have a formal requirements process. Many organizations appear willing to spend huge amounts on fixing and altering poorly specified software, but seem unwilling to invest a much smaller amount to get the requirements right in the first place.
Mastering the Requirements Process, Second Edition, sets out an industry-proven process for gathering and verifying requirements with an eye toward today's agile development environments. In this total update of the bestselling guide, the authors show how to discover precisely what the customer wants and needs while doing the minimum requirements work according to the project's level of agility.
Features include
- The Volere requirements process—completely specified, and revised for compatibility with agile environments
- A specification template that can be used as the basis for your own requirements specifications
- New agility ratings that help you funnel your efforts into only the requirements work needed for your particular development environment and project
- How to make requirements testable using fit criteria
- Iterative requirements gathering leading to faster delivery to the client
- Checklists to help identify stakeholders, users, nonfunctional requirements, and more
- Details on gathering and implementing requirements for iterative releases
- An expanded project sociology section for help with identifying and communicating with stakeholders
- Strategies for exploiting use cases to determine the best product to build
- Methods for reusing requirements and requirements patterns
- Examples showing how the techniques and templates are applied in real-world situations
Sample Content
Online Sample Chapter
Mastering the Requirements Process
Downloadable Sample Chapter
Table of Contents
Preface to the Second Edition xxi
Foreword to the First Edition xxiii
Acknowledgments xxiv
Chapter 1 What Are Requirements? 1
Requirements Gathering and Systems Modeling 3
Agile Software Development 4
Why Do I Need Requirements? 8
What Is a Requirement? 9
Evolution of Requirements 11
The Template 11
The Shell 14
The Volere Requirements Process 15
Chapter 2 The Requirements Process 17Agility Guide 19
Requirements Process in Context 20
The Process 21
A Case Study 21
Trawling for Requirements 24
Prototyping the Requirements 25
Scenarios 25
Writing the Requirements 26
The Quality Gateway 28
Reusing Requirements 29
Reviewing the Specification 29
Iterative and Incremental Processes 30
Requirements Retrospective 31
Your Own Requirements Process 31
In Conclusion 33
Chapter 3 Project Blastoff 35Agility Guide 38
IceBreaker 38
Scope, Stakeholders, Goals 40
Setting the Scope 40
Stakeholders 45
Other Stakeholders 51
Finding the Stakeholders 54
Goals: What Do You Want to Achieve? 55
Requirements Constraints 60
Naming Conventions and Definitions 61
How Much Is This Going to Cost? 62
Risks 63
To Go or Not to Go 64
Blastoff Alternatives 65
Summary 65
Chapter 4 Event-Driven Use Cases 67Agility Guide 67
Understanding the Work 67
Use Cases and Their Scope 69
The Work 70
The Context of the Work 70
Business Events 73
Why Business Events and Business Use Cases Are a Good Idea 75
Finding the Business Events 76
Business Use Cases 78
The Role of Adjacent Systems 79
Business Use Cases and Product Use Cases 86
Summary 90
Chapter 5 Trawling for Requirements 93Agility Guide 93
Responsibility 94
Trawling and Business Use Cases 96
The Role of the Current Situation 98
Apprenticing 101
Observing Structures and Patterns 103
Interviewing the Stakeholders 104
Getting to the Essence of the Work 107
Solving the Right Problem 109
Innovative Products 110
Business Use Case Workshops 113
Creativity Workshops 116
Brainstorming 117
Personas 119
Mind Maps 122
Wallpaper 124
Video and Photographs 124
Wikis, Blogs, and Discussion Forums 125
Document Archeology 126
Some Other Requirements-Gathering Techniques 128
Determining What the Product Should Be 129
Does Technology Matter? 131
Choosing the Best Trawling Technique 132
Summary 134
Chapter 6 Scenarios and Requirements 135Agility Guide 135
Scenarios 136
Normal Case Scenarios 140
Diagramming the Scenario 142
Alternative Cases 144
Exception Cases 145
What If? Scenarios 146
Misuse Cases and Negative Scenarios 147
Scenario Template 148
Product Use Case Scenarios 150
Summary 152
Chapter 7 Functional Requirements 155Agility Guide 155
Functional Requirements 157
Finding the Functional Requirements 157
Level of Detail or Granularity 160
Exceptions and Alternatives 161
Avoiding Ambiguity 162
Technological Requirements 164
Requirements, Not Solutions 165
Grouping Requirements 166
Alternatives to Functional Requirements 167
Summary 169
Chapter 8 Nonfunctional Requirements 171Agility Guide 172
Nonfunctional Requirements 173
Use Cases and Nonfunctional Requirements 174
The Nonfunctional Requirements 174
Look and Feel Requirements: Type 10 176
Usability and Humanity Requirements: Type 11 178
Performance Requirements: Type 12 182
Operational and Environmental Requirements: Type 13 184
Maintainability and Support Requirements: Type 14 186
Security Requirements: Type 15 187
Cultural and Political Requirements: Type 16 190
Legal Requirements: Type 17 192
Finding the Nonfunctional Requirements 195
Don't Write a Solution 199
Summary 201
Chapter 9 Fit Criteria 203Agility Guide 203
Why Does Fit Need a Criterion? 204
Scale of Measurement 206
Rationale 206
Fit Criteria for Nonfunctional Requirements 208
Fit Criteria for Functional Requirements 217
Use Cases and Fit Criteria 218
Fit Criterion for Project Purpose 219
Fit Criteria for Solution Constraints 219
Summary 220
Chapter 10 Writing the Requirements 223Agility Guide 223
Turning Potential Requirements into Written Requirements 225
Knowledge Versus Specification 225
The Volere Requirements Specification Template 227
1 The Purpose of the Project 229
2 The Client, the Customer, and Other Stakeholders 232
3 Users of the Product 233
4 Mandated Constraints 234
5 Naming Conventions and Definitions 237
6 Relevant Facts and Assumptions 238
7 The Scope of the Work 240
8 The Scope of the Product 241
The Shell 241
The Atomic Requirement 243
Writing the Specification 248
9 Functional Requirements 249
Nonfunctional Requirements 251
Project Issues 252
18 Open Issues 252
19 Off-the-Shelf Solutions 253
20 New Problems 254
21 Tasks 254
22 Migration to the New Product 254
23 Risks 254
24 Costs 255
25 User Documentation and Training 256
26 Waiting Room 256
27 Ideas for Solutions 257
Summary 257
Chapter 11 The Quality Gateway 259Agility Guide 260
Requirements Quality 261
Using the Quality Gateway 262
Testing Completeness 263
Testing Traceability 265
Consistent Terminology 267
Relevant to Purpose? 268
Testing the Fit Criterion 270
Viable within Constraints? 272
Requirement or Solution? 273
Customer Value 274
Gold Plating 275
Requirements Creep 276
Implementing the Quality Gateway 279
Summary 281
Chapter 12 Prototyping the Requirements 283Agility Guide 285
Prototypes and Reality 286
Low-Fidelity Prototypes 288
High-Fidelity Prototypes 292
Storyboards 294
Object Life History 296
The Prototyping Loop 297
Summary 301
Chapter 13 Reusing Requirements 303What Is Reusing Requirements? 303
Sources of Reusable Requirements 306
Requirements Patterns 307
A Business Event Pattern 309
Forming Patterns by Abstracting 313
Domain Analysis 317
Trends in Reuse 318
Reuse and Objects 318
Summary 319
Chapter 14 Reviewing the Specification 321Agility Guide 322
Reviewing the Specification 323
Inspections 323
Find Missing Requirements 324
Have All Business Use Cases Been Discovered? 325
Define the Scope 326
Customer Value 332
Prioritizing the Requirements 333
Conflicting Requirements 337
Ambiguous Specifications 339
Risk Analysis 340
Measure the Required Effort 342
Summary 342
Chapter 15 Whither Requirements? 345Adapting the Process 345
What About Requirements Tools? 347Mapping Tools to Purpose 348
Publishing the Requirements 350
Requirements Traceability 353
Dealing with Change 357
Requirements Retrospective 360
Your Notebook 363
The End 363
Appendix A Volere Requirements Process Model 365Appendix B Volere Requirements Specification Template 451Appendix C Function Point Counting: A Simplified Introduction 507Appendix D Project Sociology Analysis Templates 523Glossary 531Bibliography 535Index 539Preface
This book is a reflection of the feedback we have received, and of the way people have made use of the first edition.
The requirements activity has moved away from wanting to be seen as an engineering discipline, to the realization that it is a sociotechnical activity. Requirements analysts now see their role first as one of communication, and second as a technician adding rigor and precision to the results of the human communication.
As a result, we have updated and expanded the project sociology analysis section
of the book. In a similar vein, we have added the appropriate rigor to the technicalities
of recording and measuring the requirements.
Perhaps the greatest change to come along since the first edition has been the
arrival of agile methods, accompanied by some wonderful technological advances.
Agile methods have influenced the way people develop software, with the result
being that greater emphasis is placed on close customer relationships, and less
emphasis is placed on documentation. We heartily applaud this advance. However,
we have also seen too many people, who, in the name of agility, rush to a solution
without first understanding the real business problem to be solved.
This, then, is the role of requirements in the agile world: to ensure that we hear not only one customer's voice, but also the voices of the other stakeholders—those with some value to add to the requirements for the product. Agile requirements analysts ensure that the work is considered, not just the product, and that the nonfunctional requirements are studied, not left to the whim of the programmer.
Agile methods have brought with them a healthy disdain for documentation. We agree with this view. Throughout this second edition we urge you to consider the benefit before committing anything to writing. But while we suggest sometimes you can develop software successfully without formally written requirements, we never suggest you can do it without understanding the requirements.
The emphasis on iterative development means that the requirements "phase" is no longer completed before building begins. The drive toward short, sharp release cycles means requirements analysts get feedback on their requirements efforts more quickly. Stakeholders receive positive reinforcement when they see the time they invest in requirements paid back with progressive versions of working software that does what they expect, and what they need.
Technological advances have changed requirements gathering. Blogs and wikis mean that requirements analysts can gather their requirements informally and iteratively using the convenience of networking with their stakeholders. Desktop videoconferencing and instant messaging mean closer, quicker communication with stakeholders, which is, of course, necessary for good requirements gathering.
The gap between what we wrote in 1999 and what we found ourselves doing when gathering requirements gradually grew wider, until we knew it was time to update our book. The volume that you hold in your hands is the result of the last few years of our work and teaching. We trust you find it interesting, enlightening, and useful.
Index