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