Mastering the Requirements Process: Getting Requirements Right / Edition 3 available in Hardcover, eBook
Mastering the Requirements Process: Getting Requirements Right / Edition 3
- ISBN-10:
- 0321815742
- ISBN-13:
- 9780321815743
- Pub. Date:
- 08/06/2012
- Publisher:
- Pearson Education
- ISBN-10:
- 0321815742
- ISBN-13:
- 9780321815743
- Pub. Date:
- 08/06/2012
- Publisher:
- Pearson Education
Mastering the Requirements Process: Getting Requirements Right / Edition 3
Buy New
$72.99Buy Used
$63.86-
-
SHIP THIS ITEM
Temporarily Out of Stock Online
Please check back later for updated availability.
-
Overview
“If the purpose is to create one of the best books on requirements yet written, the authors have succeeded.”
—Capers Jones
Software can solve almost any problem. The trick is knowing what the problem is. With about half of all software errors originating in the requirements activity, it is clear that a better understanding of the problem is needed.
Getting the requirements right is crucial if we are to build systems that best meet our needs. We know, beyond doubt, that the right requirements produce an end result that is as innovative and beneficial as it can be, and that system development is both effective and efficient.
Mastering the Requirements Process: Getting Requirements Right, Third Edition, sets out an industry-proven process for gathering and verifying requirements, regardless of whether you work in a traditional or agile development environment. In this sweeping update of the bestselling guide, the authors show how to discover precisely what the customer wants and needs, in the most efficient manner possible.
Features include
- The Volere requirements process for discovering requirements, for use with both traditional and iterative environments
- A specification template that can be used as the basis for your own requirements specifications
- Formality guides 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
- Checklists to help identify stakeholders, users, non-functional requirements, and more
- Methods for reusing requirements and requirements patterns
New features include
- Strategy guides for different environments, including outsourcing
- Strategies for gathering and implementing requirements for iterative releases
- “Thinking above the line” to find the real problem
- How to move from requirements to finding the right solution
- The Brown Cow model for clearer viewpoints of the system
- Using story cards as requirements
- Using the Volere Knowledge Model to help record and communicate requirements
- Fundamental truths about requirements and system development
Product Details
| ISBN-13: | 9780321815743 |
|---|---|
| Publisher: | Pearson Education |
| Publication date: | 08/06/2012 |
| Edition description: | New Edition |
| Pages: | 576 |
| Product dimensions: | 9.60(w) x 7.70(h) x 1.40(d) |
About the Author
Suzanne Robertson and James Robertson have, over many years, helped hundreds of companies improve their requirements techniques and move into the fast lane of system development. Their courses and seminars on requirements, analysis, and design are widely praised for their innovative approach. The Robertsons are principals of the Atlantic Systems Guild, a well-known consultancy specializing in the human dimensions of complex system building. They are also the coauthors of Requirements-Led Project Management (Addison-Wesley, 2005).
James Robertson and Suzanne Robertson have, over many years, helped hundreds of companies improve their requirements techniques and move into the fast lane of system development. Their courses and seminars on requirements, analysis, and design are widely praised for their innovative approach. The Robertsons are principals of the Atlantic Systems Guild, a well-known consultancy specializing in the human dimensions of complex system building. They are also the coauthors of Requirements-Led Project Management (Addison-Wesley, 2005).
Read an Excerpt
In the six years since we published the first edition of this book, the world's knowledge of requirements has grown, and more people have a job called "business analyst," "requirements engineer," or something similar. The Volere Requirements Specification Template has been downloaded countless times. The Volere Requirements Process is in use by thousands of people who are engaged in the activity of successful requirements gathering. They, in turn, have given us feedback over the years about what they needed to know, and what they are doing when gathering requirements.
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.
Table of Contents
Preface to the Third Edition xxi
Foreword to the First Edition xxiii
Acknowledgments xxv
Chapter 1: Some Fundamental Truths 1
in which we consider the essential contribution of requirements
Truth 1 1
Truth 2 2
Truth 3 3
Truth 4 4
Truth 5 5
Truth 6 6
Truth 7 7
Truth 8 7
Truth 9 8
Truth 10 8
Truth 11 9
What Are These Requirements Anyway? 9
The Volere Requirements Process 11
Chapter 2: The Requirements Process 13
in which we present a process for discovering requirements and discuss how you might use it
The Requirements Process in Context 14
A Case Study 15
Project Blastoff 15
Trawling for Requirements 17
Quick and Dirty Modeling 19
Scenarios 20
Writing the Requirements 20
Quality Gateway 22
Reusing Requirements 23
Reviewing the Requirements 23
Iterative and Incremental Processes 24
Requirements Retrospective 25
Evolution of Requirements 26
The Template 27
The Snow Card 29
Your Own Requirements Process 31
Formality Guide 32
The Rest of This Book 33
Chapter 3: Scoping the Business Problem 35
in which we establish a definition of the business area to be changed, thereby ensuring that the project team has a clear vision of what their project is meant to achieve
Project Blastoff 35
Formality Guide 38
Setting the Scope 38
IceBreaker 41
Scope, Stakeholders, and Goals 43
Stakeholders 44
Other Stakeholders 50
Finding the Stakeholders 54
Goals: What Do You Want to Achieve? 54
Constraints 59
Naming Conventions and Definitions 60
How Much Is This Going to Cost? 61
Risks 62
To Go or Not to Go 63
Blastoff Meetings 64
Summary 65
Chapter 4: Business Use Cases 67
in which we discuss a fail-safe way of partitioning the work and so smooth the way for your requirements investigation
Understanding the Work 67
Formality Guide 69
Use Cases and Their Scope 69
The Scope of the Work 70
Business Events 73
Why Business Events and Business Use Cases Are a Good Idea 75
Finding the Business Events 78
Business Use Cases 80
Business Use Cases and Product Use Cases 82
Summary 85
Chapter 5: Investigating the Work 87
in which we come to an understanding of what the business is doing, and start to think about what it might like to do
Trawling the Business 87
Formality Guide 89
Trawl for Knowledge 89
The Business Analyst 91
Trawling and Business Use Cases 92
The Brown Cow Model 93
The Current Way of Doing Things (How-Now) 94
Apprenticing 98
Business Use Case Workshops 99
Interviewing the Stakeholders 102
Looking for Reusable Requirements 106
Quick and Dirty Process Modeling 107
Prototypes and Sketches 109
Mind Maps 116
The Murder Book 119
Video and Photographs 120
Wikis, Blogs, Discussion Forums 122
Document Archeology 123
Family Therapy 125
Choosing the Best Trawling Technique 125
Finally . . . 127
Chapter 6: Scenarios 129
in which we look at scenarios, and how the business analyst uses them to communicate with the stakeholders
Formality Guide 129
Scenarios 130
The Essence of the Business 135
Diagramming the Scenario 138
Alternatives 139
Exceptions 140
What if? Scenarios 142
Misuse Cases and Negative Scenarios 142
Scenario Template 143
Summary 145
Chapter 7: Understanding the Real Problem 147
in which we “think above the line” to find the true essence of the business, and so deliver the right product–one that solves the right problem
Formality Guide 149
The Brown Cow Model: Thinking Above the Line 149
Solving the Right Problem 156
Moving into the Future 157
How to Be Innovative 160
Systemic Thinking 162
Value 165
Personas 166
Challenging Constraints 169
Innovation Workshops 171
Brainstorming 173
Back to the Future 174
Chapter 8: Starting the Solution 177
in which we bring the essence of the business into the technological world of the implementation
Iterative Development 179
Essential Business 179
Determine the Extent of the Product 180
Consider the Users 181
Designing the User Experience 183
Innovation 184
Sketching the Interface 188
The Real Origin of the Business Event 189
Adjacent Systems and External Technology 190
Cost, Benefit, and Risks 194
Document Your Design Decisions 195
Product Use Case Scenarios 196
Putting It All Together 199
Chapter 9: Strategies for Today’s Business Analyst 203
in which we consider strategies for the business analyst to guide requirements discovery in today’s changing environments
Balancing Knowledge, Activities, and People 204
Common Project Requirements Profiles 204
How Much Knowledge Is Needed Before Each Breakout? 205
External Strategy 206
Iterative Strategy 210
Sequential Strategy 212
Your Own Strategy 215
Sharpening Your Requirements Skills 215
Summary 222
Chapter 10: Functional Requirements 223
in which we look at those requirements that cause the product to do something
Formality Guide 224
Functional Requirements 225
Uncovering the Functional Requirements 225
Level of Detail or Granularity 228
Description and Rationale 229
Data, Your Secret Weapon 231
Exceptions and Alternatives 233
Conditional Requirements 234
Avoiding Ambiguity 234
Technological Requirements 237
Grouping Requirements 237
Alternatives to Functional Requirements 238
Requirements for COTS 241
Summary 242
Chapter 11: Non-functional Requirements 245
in which we look at the requirements that specify how well your product does what it does
An Introduction to Non-functional Requirements 246
Formality Guide 246
Functional Versus Non-functional Requirements 247
Use Cases and Non-functional Requirements 248
The Non-functional Requirements Types 249
Look and Feel Requirements: Type 10 250
Usability and Humanity Requirements: Type 11 253
Performance Requirements: Type 12 257
Operational and Environmental Requirements: Type 13 259
Maintainability and Support Requirements: Type 14 261
Security Requirements: Type 15 262
Cultural Requirements: Type 16 266
Legal Requirements: Type 17 268
Finding the Non-functional Requirements 271
Blogging the Requirements 271
Don’t Write a Solution 276
Summary 277
Chapter 12: Fit Criteria and Rationale 279
in which we show how measuring requirements makes them unambiguous, understandable, communicable, and testable
Formality Guide 280
Why Does Fit Need a Criterion? 280
The Rationale for the Rationale 282
Deriving Fit Criteria 284
Scale of Measurement 285
Fit Criteria for Non-functional Requirements 286
Fit Criteria for Functional Requirements 295
Forms of Fit Criteria 296
Use Cases and Fit Criteria 299
Fit Criterion for Project Purpose 299
Fit Criteria for Solution Constraints 300
Summary 301
Chapter 13: The Quality Gateway 303
in which we prevent unsuitable requirements from becoming part of the specification
Formality Guide 304
Requirements Quality 305
Using the Quality Gateway 306
Within Scope? 307
Testing Completeness 311
Testing the Fit Criterion 312
Consistent Terminology 313
Viable within Constraints? 314
Requirement or Solution? 316
Requirement Value 316
Gold Plating 317
Requirements Creep 317
Implementing the Quality Gateway 319
Summary 321
Chapter 14: Requirements and Iterative Development 323
in which we look at how to discover and implement requirements in an iterative development environment
The Need for Iterative Development 323
An Iterative Requirements Process 324
Business Value Analysis and Prioritization 327
How to Write a Good User Story 329
Iterative Requirements Roles 333
Summary 335
Chapter 15: Reusing Requirements 337
in which we look for requirements that have already been written and explore ways to make use of them
What Is Reusing Requirements? 338
Sources of Reusable Requirements 341
Requirements Patterns 342
A Business Event Pattern 344
Forming Patterns by Abstracting 346
Domain Analysis 351
Summary 351
Chapter 16: Communicating the Requirements 353
in which we turn the requirements into communicable form
Formality Guide 353
Turning Potential Requirements into Written Requirements 354
Knowledge Versus Specification 354
The Volere Requirements Specification Template 357
Discovering Atomic Requirements 359
Attributes of Atomic Requirements 361
Assembling the Specification 365
Automated Requirements Tools 366
Functional Requirements 367
Non-functional Requirements 368
Project Issues 369
Summary 369
Chapter 17: Requirements Completeness 371
in which we decide whether our specification is complete, and set the priorities of the requirements
Formality Guide 372
Reviewing the Specification 373
Inspections 373
Find Missing Requirements 374
Have All Business Use Cases Been Discovered? 376
Prioritizing the Requirements 382
Conflicting Requirements 386
Ambiguous Specifications 388
Risk Assessment 388
Measure the Required Cost 391
Summary 391
Appendix A: Volere Requirements Specification Template 393
a guide for writing a rigorous and complete requirements specification
Contents 393
Use of This Template 394
Volere 394
Requirements Types 395
Testing Requirements 396
Atomic Requirements Shell 396
1. The Purpose of the Project 397
2. The Stakeholders 400
3. Mandated Constraints 407
4. Naming Conventions and Terminology 415
5. Relevant Facts and Assumptions 416
6. The Scope of the Work 420
7. Business Data Model and Data Dictionary 425
8. The Scope of the Product 429
9. Functional and Data Requirements 433
Non-functional Requirements 435
10. Look and Feel Requirements 435
11. Usability and Humanity Requirements 437
12. Performance Requirements 441
13. Operational and Environmental Requirements 447
14. Maintainability and Support Requirements 449
15. Security Requirements 451
16. Cultural Requirements 454
17. Legal Requirements 455
Project Issues 457
18. Open Issues 457
19. Off-the-Shelf Solutions 458
20. New Problems 460
21. Tasks 462
22. Migration to the New Product 463
23. Risks 465
24. Costs 467
25. User Documentation and Training 468
26. Waiting Room 470
27. Ideas for Solutions 471
Appendix B: Stakeholder Management Templates 473
Stakeholder Map 473
Stakeholder Template 475
Appendix C: Function Point Counting: A Simplified Introduction 479
in which we look at a way to accurately measure the size or functionality of the work area, with a view toward using the measurement to estimate the requirements effort
Measuring the Work 479
A Quick Primer on Counting Function Points 481
Counting Function Points for Business Use Cases 484
Counting the Stored Data 489
Adjust for What You Don’t Know 492
Now That I Have Counted Function Points, What’s Next? 492
Appendix D: Volere Requirements Knowledge Model 495
Definitions of Requirements Knowledge Classes and Associations 495
Glossary 511
Bibliography 517
Index 523
Preface
In the six years since we published the first edition of this book, the world's knowledge of requirements has grown, and more people have a job called "business analyst," "requirements engineer," or something similar. The Volere Requirements Specification Template has been downloaded countless times. The Volere Requirements Process is in use by thousands of people who are engaged in the activity of successful requirements gathering. They, in turn, have given us feedback over the years about what they needed to know, and what they are doing when gathering requirements.
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.