-
Mastering theRequirements ProcessSecond Edition
Suzanne RobertsonJames Robertson
/•Addison-Wesley
Upper Saddle River, NJ Boston Indianapolis San Francisco
New York Toronto Montreal London Munich Paris Madrid
Capetown Sydney Tokyo § Singapore m Mexico City
-
Contents
Preface to the Second Edition xxi
Foreword to the First Edition xxiii
Acknowledgments xxiv
What Are Requirements? 1in which we consider why we are
interested in requirementsRequirements Gathering and Systems
Modeling 3Agile Software Development 4Why Do I Need Requirements?
8What Is a Requirement? 9
Functional Requirements 9Nonfunctional Requirements
10Constraints 10
Evolution of Requirements 11The Template 11The Shell 14The
Volere Requirements Process 15
The Requirements Process 17in which we look at a process for
gatheringrequirements and discuss how you might use itAgility Guide
19Requirements Process in Context 20The Process 21A Case Study
21
Project Blastoff 22Trawling for Requirements 24Prototyping the
Requirements 25Scenarios 25Writing the Requirements 26The Quality
Gateway 28Reusing Requirements 29Reviewing the Specification
29Iterative and Incremental Processes 30Requirements Retrospective
31Your Own Requirements Process 31In Conclusion 33
VII
-
viii • Contents
Project Blastoff 35in which we establish a solid foundation for
the requirements,and ensure that the members of the project team
all startrowing in the same directionAgility Guide 38IceBreaker
38Scope, Stakeholders, Goals 40Setting the Scope 40
Domains of Interest 42First-Cut Work Context 44
Stakeholders 45The Client 47The Customer 48The Users: Get to
Know Them 49
Other Stakeholders 51Consultants 52Management 52Subject Matter
Experts 52Core Team 52Inspectors 53Market Forces 53Legal 53Negative
Stakeholders 53Industry Standard Setters 53Public Opinion
53Government 53Special-Interest Groups 54Technical Experts
54Cultural Interests 54Adjacent Systems 54
Finding the Stakeholders 54Goals: What Do You Want to Achieve?
55
Keeping Track of the Purpose 59Requirements Constraints 60
Solution Constraints 60Project Constraints 61
Naming Conventions and Definitions 61How Much Is This Going to
Cost? 62Risks 63To Go or Not to Go 64Blastoff Alternatives
65Summary 65
Event-Driven Use Cases 67in which we discuss a fail-safe way of
partitioning the workinto use cases, and along the way discover the
best product to buildAgility Guide 67Understanding the Work 67
-
Use Cases and Their ScopeThe WorkThe Context of the Work
The Outside WorldBusiness Events
Time-Triggered Business EventsWhy Business Events and Business
Use Cases Are a Good IdeaFinding the Business EventsBusiness Use
CasesThe Role of Adjacent Systems
Active Adjacent SystemsAutonomous Adjacent SystemsCooperative
Adjacent Systems
Business Use Cases and Product Use CasesActors
Summary
69707072737475767879808385868990
Contents IX
Trawling for Requirementsin which we drag the net through the
work area looking forrequirements, and discuss some useful
techniques for doingAgility GuideResponsibility
The Requirements AnalystTrawling and Business Use CasesThe Role
of the Current SituationApprenticingObserving Structures and
PatternsInterviewing the Stakeholders
Asking the Right QuestionsGetting to the Essence of the
WorkSolving the Right ProblemInnovative ProductsBusiness Use Case
Workshops
OutcomeScenariosBusiness Rules
Creativity WorkshopsBrainstormingPersonasMind MapsWallpaperVideo
and PhotographsWikis, Blogs, and Discussion ForumsDocument
ArcheologySome Other Requirements-Gathering Techniques
Family TherapySoft Systems and Viewpoints
Determining What the Product Should BeThe True Origin of the
Business Event
Does Technology Matter?
SO
93
9394949698101103104106107109110113114115115116117119122124124125126128128129129131131
-
Contents
Choosing the Best Trawling Technique 132Summary 134
6 Scenarios and Requirements 135in which we look at scenarios as
a way of helping thestakeholders to discover their
requirementsAgility Guide 135Scenarios 136Normal Case Scenarios
140Diagramming the Scenario 142Alternative Cases 144Exception Cases
145What If? Scenarios 146Misuse Cases and Negative Scenarios
147Scenario Template 148Product Use Case Scenarios 150Summary
152
7 Functional Requirements 155in which we look at those
requirements that cause theproduct to do somethingAgility Guide
155Functional Requirements 157Finding the Functional Requirements
157Level of Detail or Granularity 160Exceptions and Alternatives
161Avoiding Ambiguity 162Technological Requirements
164Requirements, Not Solutions 165Grouping Requirements
166Alternatives to Functional Requirements 167Summary 169
8 Nonfunctional Requirements 171in which we look at those
requirements that specify howwell your product does what it
doesAgility Guide 172Nonfunctional Requirements 173Use Cases and
Nonfunctional Requirements 174The Nonfunctional Requirements
174Look and Feel Requirements: Type 10 176Usability and Humanity
Requirements: Type 11 178Performance Requirements: Type 12
182Operational and Environmental Requirements: Type 13
184Maintainability and Support Requirements: Type 14 186Security
Requirements: Type 15 187
-
Contents • xi
Confidentiality 187Availability 188Integrity 188Auditing
189...And No More 189
Cultural and Political Requirements: Type 16 190Legal
Requirements: Type 17 192
Sarbanes-Oxley Act 194Other Legal Obligations 194Standards
194
Finding the Nonfunctional Requirements 195Blogging the
Requirements 195Use Cases 195The Template 197Prototypes and
Nonfunctional Requirements 197The Client 198
Don't Write a Solution 199Summary 201
Fit Criteria 203in which we show how measuring a requirement
makes itunambiguous, understandable, and, importantly,
testableAgility Guide 203Why Does Fit Need a Criterion? 204Scale of
Measurement 206Rationale 206Fit Criteria for Nonfunctional
Requirements 208
Product Failure? 209Subjective Tests 210Look and Feel
Requirements 211Usability and Humanity Requirements 212Performance
Requirements 213Operational Requirements 214Maintainability
Requirements 215Security Requirements 215Cultural and Political
Requirements 216Legal Requirements 216
Fit Criteria for Functional Requirements 217Test Cases 218
Use Cases and Fit Criteria 218Fit Criterion for Project Purpose
219Fit Criteria for Solution Constraints 219Summary 220
Writing the Requirements 223in which we turn the requirements
into written formAgility Guide 223Turning Potential Requirements
into Written Requirements 225Knowledge Versus Specification 225
-
xii • Contents
The Volere Requirements Specification Template 2271 The Purpose
of the Project 229
1 a The User Business or Background of the Project Effort 229lb
Goals of the Project 230
2 The Client, the Customer, and Other Stakeholders 2322a The
Client 2322b The Customer 2332c Other Stakeholders 233
3 Users of the Product 2334 Mandated Constraints 234
4a Solution Constraints 2354b Implementation Environment of the
Current System 2354c Partner or Collaborative Applications 2364d
Off-the-Shelf Software 2364e Anticipated Workplace Environment
2364f Schedule Constraints 2364g Budget Constraints 237
5 Naming Conventions and Definitions 2375a Definitions of All
Terms, Including Acronyms, Used in the Project 2375b Data
Dictionary for Any Included Models 238
6 Relevant Facts and Assumptions 2386a Facts 2386b Assumptions
239
7 The Scope of the Work 2407c Work Partitioning 240
8 The Scope of the Product 2418a Product Boundary 2418b Product
Use Case List 2418c Individual Product Use Cases 241
The Shell 241Snow Cards 242Automated Requirements Tools 243
The Atomic Requirement 243Requirement Number 244Requirement Type
244Event/Use Case Number 244Description 245Rationale 245Originator
245Fit Criterion 245Customer Satisfaction and Customer
Dissatisfaction 246Priority 247Conflicts 247Supporting Materials
248History 248
Writing the Specification 2489 Functional Requirements 249
Description 250Nonfunctional Requirements 251
-
Contents xiii
Project Issues 25218 Open Issues 25219 Off-the-Shelf Solutions
25320 New Problems 25421 Tasks 25422 Migration to the New Product
25423 Risks 25424 Costs 25525 User Documentation and Training 25626
Waiting Room 25627 Ideas for Solutions 257Summary 25 7
11 The Quality Gateway 259in which we prevent unworthy
requirements becoming
v part of the specificationAgility Guide 260Requirements Quality
261Using the Quality Gateway 262Testing Completeness 263
Are There Any Missing Components? 264Meaningful to All
Stakeholders? 265
Testing Traceability 265Consistent Terminology 267
i Relevant to Purpose? 268' Testing the Fit Criterion 270t
Viable within Constraints? 272
Requirement or Solution? 273' Customer Value 274« Gold Plating
275
Requirements Creep 276• Requirements Leakage 278* Implementing
the Quality Gateway 279v. Alternative Quality Gateways 280' Summary
281
%2 Prototyping the Requirements 283,t in which we use
simulations to help find requirements\ Agility Guide 285i
Prototypes and Reality 286
n Low-Fidelity Prototypes 288\ High-Fidelity Prototypes 292
pr Storyboards 294{ Object Life History 296f The Prototyping
Loop 2971 Design and Build 298
H Testing in the User Environment 299Analyzing the Results
300
Summary 301
-
xiv • Contents
13 Reusing Requirements 303in which we look for requirements
that have alreadybeen written and explore ways to reuse themWhat Is
Reusing Requirements? 303Sources of Reusable Requirements
306Requirements Patterns 307
Christopher Alexander's Patterns 308A Business Event Pattern
309
Context of Event Response 310Processing for Event Response
311Data for Event Response 312
Forming Patterns by Abstracting 313Pa tterns for Specific
Domains 314Patterns Across Domains 315
Domain Analysis 317Trends in Reuse 318
Reuse and Objects 318Reuse Is Now a Job? 318
Summary 319
14 Reviewing the Specification 321in which we decide whether our
specification is correctand complete, and set the priorities of the
requirementsAgility Guide 322Reviewing the Specification
323Inspections 323Find Missing Requirements 324Have All Business
Use Cases Been Discovered? 325
1. Define the Scope 3262. Identify Business Events and
Non-Events 3263. Model the Business Use Case 3284. Define the
Business Data 3285. CRUD Check 3306. Check for Custodial Processes
331Repeat Until Done 331
Customer Value 332Prioritizing the Requirements 333
Prioritization Factors 333When to Prioritize 334Requirement
Priority Grading 335Prioritization Spreadsheet 335
Conflicting Requirements 337Ambiguous Specifications 339Risk
Analysis 340
Project Drivers 340Project Constraints 341Functional
Requirements 341
-
Contents • xv
Measure the Required Effort 342Summary 342
15 Whither Requirements? 345[ in which we consider some other
issues for the requirements
Adapting the Process 345, What About Requirements Tools? 347
Mapping Tools to Purpose 348Publishing the Requirements 350
Contractual Document 351Management Summary 351Marketing Summary
352User Review 352Reviewing the Specification 353
Requirements Traceability 353Tracing a Business Event 353
Dealing with Change 357i Changes in the World 358
Requirements Feedback 358Requirements Retrospective 360
What to Look For 360Running the Retrospective 360Retrospective
Report 362
! Your Notebook 363The End 363
•Appendix A Volere Requirements Process Model 365in which we
present, for your reference, the completeVolere Requirements
Process
The Volere Requirements Process Model 365Making This Work for
You 366Finding More Information 367
Define Blastoff Objectives (Process Notes 1.1.1) 371Plan
Physical Arrangements (Process Notes 1.1.2) 371Communicate with
Participants (Process Notes 1.1.3) 372Determine Project Purpose
(Process Notes 1.2.1) 374Determine the Work Context (Process Notes
1.2.2) 374Do First-Cut Risk Analysis (Process Notes 1.2.3)
375Identify the Stakeholders (Process Notes 1.2.4) 376Partition the
Context (Process Notes 1.2.5) 377Consider Non-Events (Process Notes
1.2.6) 377Determine Business Terminology (Process Notes 1.2.7)
377Define Project Constraints (Process Notes 1.2.8) 378Identify
Domains of Interest (Process Notes 1.2.9) 378Write Blastoff Report
(Process Notes 1.3.1) 380Review Blastoff Results (Process Notes
1.3.2) 380Hold Follow-Up Blastoff (Process Notes 1.3.3) 381Make
Initial Estimate (Process Notes 1.3.4) 382Review Current Situation
(Process Notes 2.1.1) 385
-
xvi • Contents
Apprentice with the User (Process Notes 2.1.2) 385Determine
Essential Requirements (Process Notes 2.1.3) 386Brainstorm the
Requirements (Process Notes 2.1.4) 386Interview the Users (Process
Notes 2.1.5) 387Do Document Archaeology (Process Notes 2.1.6)
388Make Requirements Video (Process Notes 2.1.7) 389Run Use Case
Workshop (Process Notes 2.1.8) 389Build Event Models (Process Notes
2.1.9) 390Build Scenario Models (Process Notes 2.1.10) 391Run
Creativity Workshop (Process Notes 2.1.11) 391Study the Adjacent
Systems (Process Notes 2.2.1) 393Define Use Case Boundary (Process
Notes 2.2.2) 393Gather Business Event Knowledge (Process Notes
2.3.1) 395Choose Appropriate Trawling Techniques (Process Notes
2.3.2) 395Ask Clarification Questions (Process Notes 2.4)
396Identify Potential Requirements (Process Notes 3.1) 399Identify
Functional Requirements (Process Notes 3.2) 399Identify Composite
Requirements (Process Notes 3.3) 400Formalize Requirement (Process
Notes 3.4) 400Formalize System Constraints (Process Notes 3.5)
400Identify Nonfunctional Requirements (Process Notes 3.6) 401Write
Functional Fit Criteria (Process Notes 3.7) 401Write Nonfunctional
Fit Criteria (Process Notes 3.8) 402Define Customer Value (Process
Notes 3.9) 402Identify Dependencies and Conflicts (Process Notes
3.10) 403Review Requirement Fit Criteria (Process Notes 4.1)
405Review Requirement Relevance (Process Notes 4.2) 406Review
Requirement Viability (Process Notes 4.3) 406Identify Gold-Plated
Requirements (Process Notes 4.4) 406Review Requirement Completeness
(Process Notes 4.5) 406Plan the Prototype (Process Notes 5.1)
408Build Low-Fidelity Prototype (Process Notes 5.2.1) 410Build
High-Fidelity Prototype (Process Notes 5.2.2) 410Test High-Fidelity
Prototype with Users (Process Notes 5.3.1) 413Test Low-Fidelity
Prototype with Users (Process Notes 5.3.2) 413Identify New and
Changed Requirements (Process Notes 5.3.3) 414Evaluate Prototyping
Effort (Process Notes 5.3.4) 414Conduct Private Individual Reviews
(Process Notes 6.1.1) 417Conduct Separate Meetings with Groups
(Process Notes 6.1.2) 417Facilitator Reviews Facts (Process Notes
6.1.3) 417Hold Retrospective Review Meeting (Process Notes 6.2.1)
420Produce Retrospective Report (Process Notes 6.2.2) 420
Retrospective Report on Requirements Specification 420Identify
Filtration Criteria (Process Notes 6.3.1) 423Select Relevant
Requirement Types (Process Notes 6.3.2) 423Add New Filtration
Criteria (Process Notes 6.3.3) 423Identify Missing Requirements
(Process Notes 7.1.1) 427Identify Customer Value Ratings (Process
Notes 7.1.2) 427Identify Requirement Interaction (Process Notes
7.1.3) 428
-
Contents • xvii
' I
Identify Prototyping Opportunity (Process Notes 7.1.4)Find
Missing Custodial Requirements (Process Notes 7.1.5)Look for Likely
Risks (Process Notes 7.2.1)Quantify Each Risk (Process Notes
7.2.2)Identify Estimation Input (Process Notes 7.3.1)Estimate
Effort for Events (Process Notes 7.3.2)Estimate Requirements Effort
(Process Notes 7.3.3)Design Form of Specification (Process Notes
7.4.1)Assemble the Specification (Process Notes 7.4.2)Dictionary of
Terms Used in theRequirements Process Model
Appendix B Volere Requirements Specification Templatea guide for
writing a rigorous and completerequirements specification
ContentsProject DriversProject ConstraintsFunctional
RequirementsNonfunctional RequirementsProject Issues
PreambleVolereRequirements TypesTesting RequirementsRequirements
Shell1 The Purpose of the Project
la The User Business or Background of the Project Effortlb Goals
of the Project
2 The Client, the Customer, and Other Stakeholders2a The
Client2b The Customer2c Other Stakeholders
3 Users of the Product3a The Hands-On Users of the Product3b
Priorities Assigned to Users3c User Participation3d Maintenance
Users and Service Technicians
4 Mandated Constraints4a Solution Constraints4b Implementation
Environment of the Current System4c Partner or Collaborative
Applications4d Off-the-Shelf Software4e Anticipated Workplace
Environment4f Schedule Constraints4g Budget Constraints
5 Naming Conventions and Definitions5a Definitions of All Terms,
Including Acronyms, Used in the Project5b Data Dictionary for Any
Included Models
6 Relevant Facts and Assumptions
It*
428429431431434434435437437
437
451
451451451451451452452452453453454454454455456456456457457457458459459460460461462462463464465465465466467
-
xviii • Contents
6a Facts 4676b Assumptions 467
7 The Scope of the Work 4687a The Current Situation 4687b The
Context of the Work 4697c Work Partitioning 470
8 The Scope of the Product 4728a Product Boundary 4728b Product
Use Case List 4728c Individual Product Use Cases 473
9 Functional and Data Requirements 4739a Functional Requirements
4739b Data Requirements 475
10 Look and Feel Requirements 47610a Appearance Requirements
47610b Style Requirements 476
11 Usability and Humanity Requirements 477lla Ease of Use
Requirements 477lib Personalization and Internationalization
Requirements 479lie Learning Requirements 479lid Understandability
and Politeness Requirements 480lie Accessibility Requirements
481
12 Performance Requirements 48212a Speed and Latency
Requirements 48212b Safety-Critical Requirements 48312c Precision
or Accuracy Requirements 48412d Reliability and Availability
Requirements 48412e Robustness or Fault-Tolerance Requirements
48512f Capacity Requirements 48512g Scalability or Extensibility
Requirements 48612h Longevity Requirements 486
13 Operational and Environmental Requirements 48713a Expected
Physical Environment 48713b Requirements for Interfacing with
Adjacent Systems 48713c Productization Requirements 48813d Release
Requirements 489
14 Maintainability and Support Requirements 48914a Maintenance
Requirements 48914b Supportability Requirements 49014c Adaptability
Requirements 490
15 Security Requirements 49115a Access Requirements 49115b
Integrity Requirements 49215c Privacy Requirements 49215d Audit
Requirements 49315e Immunity Requirements 493
16 Cultural and Political Requirements 49416a Cultural
Requirements 49416b Political Requirements 494
-
Contents • xix
17 Legal Requirements 49517a Compliance Requirements 49517b
Standards Requirements 496
18 Open Issues 49619 Off-the-Shelf Solutions 497
19a Ready-Made Products 49719b Reusable Components 49719c
Products That Can Be Copied 498
20 New Problems 49820a Effects on the Current Environment 49820b
Effects on the Installed Systems 49920c Potential User Problems
49920d Limitations in the Anticipated Implementation
Environment
That May Inhibit the New Product 49920e Follow-Up Problems
500
21 Tasks 50021a Project Planning 50021b Planning of the
Development Phases 501
22 Migration to the New Product 50122a Requirements for
Migration to the New Product 50122b Data That Has to Be Modifted or
Translated for the New System 502
23 Risks 50224 Costs 50325 User Documentation and Training
504
25a User Documentation Requirements 50425b Training Requirements
505
26 Waiting Room 50527 Ideas for Solutions 506
appendix C Function Point Counting:A Simplified Introduction
507in which we look at a way to accurately measure the sizeor
functionality of the work area, with a view toward usingthe
measurement to estimate the requirements effortMeasuring the Work
507
i A Quick Primer on Counting Function Points 509Scope of the
Work 509Data Stored by the Work 510Business Use Cases 511
Counting Function Points for Business Use Cases 512Counting
Input Business Use Cases 512Counting Output Business Use Cases
514Counting Time-Triggered Business Use Cases 515
Counting the Stored Data 517Internal Stored Data 517Externally
Stored Data 518
Adjust for What You Don't Know 520What's Next After Counting
Function Points? 521
-
xx • Contents
Appendix D Project Sociology Analysis Templates 523in which we
provide some help with finding thestakeholders for your
projectStakeholder Map Template 523Stakeholder Analysis Template
523
Glossary 531
Bibliography 535
Index 539