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).

Select Guide Rating

• Preface to the Third Edition xxiForeword to the First Edition xxiiiAcknowledgments xxv  Chapter 1: Some Fundamental Truths 1in which we consider the essential contribution of requirementsTruth 1 1Truth 2 2Truth 3 3Truth 4 4Truth 5 5Truth 6 6Truth 7 7Truth 8 7Truth 9 8Truth 10 8Truth 11 9What Are These Requirements Anyway? 9The Volere Requirements Process 11  Chapter 2: The Requirements Process 13in which we present a process for discovering requirements and discuss how you might use itThe Requirements Process in Context 14A Case Study 15Project Blastoff 15Trawling for Requirements 17Quick and Dirty Modeling 19Scenarios 20Writing the Requirements 20Quality Gateway 22Reusing Requirements 23Reviewing the Requirements 23Iterative and Incremental Processes 24Requirements Retrospective 25Evolution of Requirements 26The Template 27The Snow Card 29Your Own Requirements Process 31Formality Guide 32The Rest of This Book 33  Chapter 3: Scoping the Business Problem 35in 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 achieveProject Blastoff 35Formality Guide 38Setting the Scope 38IceBreaker 41Scope, Stakeholders, and Goals 43Stakeholders 44Other Stakeholders 50Finding the Stakeholders 54Goals: What Do You Want to Achieve? 54Constraints 59Naming Conventions and Definitions 60How Much Is This Going to Cost? 61Risks 62To Go or Not to Go 63Blastoff Meetings 64Summary 65  Chapter 4: Business Use Cases 67in which we discuss a fail-safe way of partitioning the work and so smooth the way for your requirements investigationUnderstanding the Work 67Formality Guide 69Use Cases and Their Scope 69The Scope of the Work 70Business Events 73Why Business Events and Business Use Cases Are a Good Idea 75Finding the Business Events 78Business Use Cases 80Business Use Cases and Product Use Cases 82Summary 85  Chapter 5: Investigating the Work 87in which we come to an understanding of what the business is doing, and start to think about what it might like to doTrawling the Business 87Formality Guide 89Trawl for Knowledge 89The Business Analyst 91Trawling and Business Use Cases 92The Brown Cow Model 93The Current Way of Doing Things (How-Now) 94Apprenticing 98Business Use Case Workshops 99Interviewing the Stakeholders 102Looking for Reusable Requirements 106Quick and Dirty Process Modeling 107Prototypes and Sketches 109Mind Maps 116The Murder Book 119Video and Photographs 120Wikis, Blogs, Discussion Forums 122Document Archeology 123Family Therapy 125Choosing the Best Trawling Technique 125Finally . . . 127  Chapter 6: Scenarios 129in which we look at scenarios, and how the business analyst uses them to communicate with the stakeholdersFormality Guide 129Scenarios 130The Essence of the Business 135Diagramming the Scenario 138Alternatives 139Exceptions 140What if? Scenarios 142Misuse Cases and Negative Scenarios 142Scenario Template 143Summary 145  Chapter 7: Understanding the Real Problem 147in 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 problemFormality Guide 149The Brown Cow Model: Thinking Above the Line 149Solving the Right Problem 156Moving into the Future 157How to Be Innovative 160Systemic Thinking 162Value 165Personas 166Challenging Constraints 169Innovation Workshops 171Brainstorming 173Back to the Future 174  Chapter 8: Starting the Solution 177in which we bring the essence of the business into the technological world of the implementationIterative Development 179Essential Business 179Determine the Extent of the Product 180Consider the Users 181Designing the User Experience 183Innovation 184Sketching the Interface 188The Real Origin of the Business Event 189Adjacent Systems and External Technology 190Cost, Benefit, and Risks 194Document Your Design Decisions 195Product Use Case Scenarios 196Putting It All Together 199  Chapter 9: Strategies for Today’s Business Analyst 203in which we consider strategies for the business analyst to guide requirements discovery in today’s changing environmentsBalancing Knowledge, Activities, and People 204Common Project Requirements Profiles 204How Much Knowledge Is Needed Before Each Breakout? 205External Strategy 206Iterative Strategy 210Sequential Strategy 212Your Own Strategy 215Sharpening Your Requirements Skills 215Summary 222  Chapter 10: Functional Requirements 223in which we look at those requirements that cause the product to do somethingFormality Guide 224Functional Requirements 225Uncovering the Functional Requirements 225Level of Detail or Granularity 228Description and Rationale 229Data, Your Secret Weapon 231Exceptions and Alternatives 233Conditional Requirements 234Avoiding Ambiguity 234Technological Requirements 237Grouping Requirements 237Alternatives to Functional Requirements 238Requirements for COTS 241Summary 242  Chapter 11: Non-functional Requirements 245in which we look at the requirements that specify how well your product does what it doesAn Introduction to Non-functional Requirements 246Formality Guide 246Functional Versus Non-functional Requirements 247Use Cases and Non-functional Requirements 248The Non-functional Requirements Types 249Look and Feel Requirements: Type 10 250Usability and Humanity Requirements: Type 11 253Performance Requirements: Type 12 257Operational and Environmental Requirements: Type 13 259Maintainability and Support Requirements: Type 14 261Security Requirements: Type 15 262Cultural Requirements: Type 16 266Legal Requirements: Type 17 268Finding the Non-functional Requirements 271Blogging the Requirements 271Don’t Write a Solution 276Summary 277  Chapter 12: Fit Criteria and Rationale 279in which we show how measuring requirements makes them unambiguous, understandable, communicable, and testableFormality Guide 280Why Does Fit Need a Criterion? 280The Rationale for the Rationale 282Deriving Fit Criteria 284Scale of Measurement 285Fit Criteria for Non-functional Requirements 286Fit Criteria for Functional Requirements 295Forms of Fit Criteria 296Use Cases and Fit Criteria 299Fit Criterion for Project Purpose 299Fit Criteria for Solution Constraints 300Summary 301  Chapter 13: The Quality Gateway 303in which we prevent unsuitable requirements from becoming part of the specificationFormality Guide 304Requirements Quality 305Using the Quality Gateway 306Within Scope? 307Testing Completeness 311Testing the Fit Criterion 312Consistent Terminology 313Viable within Constraints? 314Requirement or Solution? 316Requirement Value 316Gold Plating 317Requirements Creep 317Implementing the Quality Gateway 319Summary 321  Chapter 14: Requirements and Iterative Development 323in which we look at how to discover and implement requirements in an iterative development environmentThe Need for Iterative Development 323An Iterative Requirements Process 324Business Value Analysis and Prioritization 327How to Write a Good User Story 329Iterative Requirements Roles 333Summary 335  Chapter 15: Reusing Requirements 337in which we look for requirements that have already been written and explore ways to make use of themWhat Is Reusing Requirements? 338Sources of Reusable Requirements 341Requirements Patterns 342A Business Event Pattern 344Forming Patterns by Abstracting 346Domain Analysis 351Summary 351  Chapter 16: Communicating the Requirements 353in which we turn the requirements into communicable formFormality Guide 353Turning Potential Requirements into Written Requirements 354Knowledge Versus Specification 354The Volere Requirements Specification Template 357Discovering Atomic Requirements 359Attributes of Atomic Requirements 361Assembling the Specification 365Automated Requirements Tools 366Functional Requirements 367Non-functional Requirements 368Project Issues 369Summary 369  Chapter 17: Requirements Completeness 371in which we decide whether our specification is complete, and set the priorities of the requirementsFormality Guide 372Reviewing the Specification 373Inspections 373Find Missing Requirements 374Have All Business Use Cases Been Discovered? 376Prioritizing the Requirements 382Conflicting Requirements 386Ambiguous Specifications 388Risk Assessment 388Measure the Required Cost 391Summary 391  Appendix A: Volere Requirements Specification Template 393a guide for writing a rigorous and complete requirements specificationContents 393Use of This Template 394Volere 394Requirements Types 395Testing Requirements 396Atomic Requirements Shell 3961. The Purpose of the Project 3972. The Stakeholders 4003. Mandated Constraints 4074. Naming Conventions and Terminology 4155. Relevant Facts and Assumptions 4166. The Scope of the Work 4207. Business Data Model and Data Dictionary 4258. The Scope of the Product 4299. Functional and Data Requirements 433Non-functional Requirements 43510. Look and Feel Requirements 43511. Usability and Humanity Requirements 43712. Performance Requirements 44113. Operational and Environmental Requirements 44714. Maintainability and Support Requirements 44915. Security Requirements 45116. Cultural Requirements 45417. Legal Requirements 455Project Issues 45718. Open Issues 45719. Off-the-Shelf Solutions 45820. New Problems 46021. Tasks 46222. Migration to the New Product 46323. Risks 46524. Costs 46725. User Documentation and Training 46826. Waiting Room 47027. Ideas for Solutions 471  Appendix B: Stakeholder Management Templates 473Stakeholder Map 473Stakeholder Template 475  Appendix C: Function Point Counting: A Simplified Introduction 479in 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 effortMeasuring the Work 479A Quick Primer on Counting Function Points 481Counting Function Points for Business Use Cases 484Counting the Stored Data 489Adjust for What You Don’t Know 492Now That I Have Counted Function Points, What’s Next? 492  Appendix D: Volere Requirements Knowledge Model 495Definitions of Requirements Knowledge Classes and Associations 495  Glossary 511Bibliography 517Index 523

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).

Select Guide Rating

• Preface to the Third Edition xxiForeword to the First Edition xxiiiAcknowledgments xxv  Chapter 1: Some Fundamental Truths 1in which we consider the essential contribution of requirementsTruth 1 1Truth 2 2Truth 3 3Truth 4 4Truth 5 5Truth 6 6Truth 7 7Truth 8 7Truth 9 8Truth 10 8Truth 11 9What Are These Requirements Anyway? 9The Volere Requirements Process 11  Chapter 2: The Requirements Process 13in which we present a process for discovering requirements and discuss how you might use itThe Requirements Process in Context 14A Case Study 15Project Blastoff 15Trawling for Requirements 17Quick and Dirty Modeling 19Scenarios 20Writing the Requirements 20Quality Gateway 22Reusing Requirements 23Reviewing the Requirements 23Iterative and Incremental Processes 24Requirements Retrospective 25Evolution of Requirements 26The Template 27The Snow Card 29Your Own Requirements Process 31Formality Guide 32The Rest of This Book 33  Chapter 3: Scoping the Business Problem 35in 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 achieveProject Blastoff 35Formality Guide 38Setting the Scope 38IceBreaker 41Scope, Stakeholders, and Goals 43Stakeholders 44Other Stakeholders 50Finding the Stakeholders 54Goals: What Do You Want to Achieve? 54Constraints 59Naming Conventions and Definitions 60How Much Is This Going to Cost? 61Risks 62To Go or Not to Go 63Blastoff Meetings 64Summary 65  Chapter 4: Business Use Cases 67in which we discuss a fail-safe way of partitioning the work and so smooth the way for your requirements investigationUnderstanding the Work 67Formality Guide 69Use Cases and Their Scope 69The Scope of the Work 70Business Events 73Why Business Events and Business Use Cases Are a Good Idea 75Finding the Business Events 78Business Use Cases 80Business Use Cases and Product Use Cases 82Summary 85  Chapter 5: Investigating the Work 87in which we come to an understanding of what the business is doing, and start to think about what it might like to doTrawling the Business 87Formality Guide 89Trawl for Knowledge 89The Business Analyst 91Trawling and Business Use Cases 92The Brown Cow Model 93The Current Way of Doing Things (How-Now) 94Apprenticing 98Business Use Case Workshops 99Interviewing the Stakeholders 102Looking for Reusable Requirements 106Quick and Dirty Process Modeling 107Prototypes and Sketches 109Mind Maps 116The Murder Book 119Video and Photographs 120Wikis, Blogs, Discussion Forums 122Document Archeology 123Family Therapy 125Choosing the Best Trawling Technique 125Finally . . . 127  Chapter 6: Scenarios 129in which we look at scenarios, and how the business analyst uses them to communicate with the stakeholdersFormality Guide 129Scenarios 130The Essence of the Business 135Diagramming the Scenario 138Alternatives 139Exceptions 140What if? Scenarios 142Misuse Cases and Negative Scenarios 142Scenario Template 143Summary 145  Chapter 7: Understanding the Real Problem 147in 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 problemFormality Guide 149The Brown Cow Model: Thinking Above the Line 149Solving the Right Problem 156Moving into the Future 157How to Be Innovative 160Systemic Thinking 162Value 165Personas 166Challenging Constraints 169Innovation Workshops 171Brainstorming 173Back to the Future 174  Chapter 8: Starting the Solution 177in which we bring the essence of the business into the technological world of the implementationIterative Development 179Essential Business 179Determine the Extent of the Product 180Consider the Users 181Designing the User Experience 183Innovation 184Sketching the Interface 188The Real Origin of the Business Event 189Adjacent Systems and External Technology 190Cost, Benefit, and Risks 194Document Your Design Decisions 195Product Use Case Scenarios 196Putting It All Together 199  Chapter 9: Strategies for Today’s Business Analyst 203in which we consider strategies for the business analyst to guide requirements discovery in today’s changing environmentsBalancing Knowledge, Activities, and People 204Common Project Requirements Profiles 204How Much Knowledge Is Needed Before Each Breakout? 205External Strategy 206Iterative Strategy 210Sequential Strategy 212Your Own Strategy 215Sharpening Your Requirements Skills 215Summary 222  Chapter 10: Functional Requirements 223in which we look at those requirements that cause the product to do somethingFormality Guide 224Functional Requirements 225Uncovering the Functional Requirements 225Level of Detail or Granularity 228Description and Rationale 229Data, Your Secret Weapon 231Exceptions and Alternatives 233Conditional Requirements 234Avoiding Ambiguity 234Technological Requirements 237Grouping Requirements 237Alternatives to Functional Requirements 238Requirements for COTS 241Summary 242  Chapter 11: Non-functional Requirements 245in which we look at the requirements that specify how well your product does what it doesAn Introduction to Non-functional Requirements 246Formality Guide 246Functional Versus Non-functional Requirements 247Use Cases and Non-functional Requirements 248The Non-functional Requirements Types 249Look and Feel Requirements: Type 10 250Usability and Humanity Requirements: Type 11 253Performance Requirements: Type 12 257Operational and Environmental Requirements: Type 13 259Maintainability and Support Requirements: Type 14 261Security Requirements: Type 15 262Cultural Requirements: Type 16 266Legal Requirements: Type 17 268Finding the Non-functional Requirements 271Blogging the Requirements 271Don’t Write a Solution 276Summary 277  Chapter 12: Fit Criteria and Rationale 279in which we show how measuring requirements makes them unambiguous, understandable, communicable, and testableFormality Guide 280Why Does Fit Need a Criterion? 280The Rationale for the Rationale 282Deriving Fit Criteria 284Scale of Measurement 285Fit Criteria for Non-functional Requirements 286Fit Criteria for Functional Requirements 295Forms of Fit Criteria 296Use Cases and Fit Criteria 299Fit Criterion for Project Purpose 299Fit Criteria for Solution Constraints 300Summary 301  Chapter 13: The Quality Gateway 303in which we prevent unsuitable requirements from becoming part of the specificationFormality Guide 304Requirements Quality 305Using the Quality Gateway 306Within Scope? 307Testing Completeness 311Testing the Fit Criterion 312Consistent Terminology 313Viable within Constraints? 314Requirement or Solution? 316Requirement Value 316Gold Plating 317Requirements Creep 317Implementing the Quality Gateway 319Summary 321  Chapter 14: Requirements and Iterative Development 323in which we look at how to discover and implement requirements in an iterative development environmentThe Need for Iterative Development 323An Iterative Requirements Process 324Business Value Analysis and Prioritization 327How to Write a Good User Story 329Iterative Requirements Roles 333Summary 335  Chapter 15: Reusing Requirements 337in which we look for requirements that have already been written and explore ways to make use of themWhat Is Reusing Requirements? 338Sources of Reusable Requirements 341Requirements Patterns 342A Business Event Pattern 344Forming Patterns by Abstracting 346Domain Analysis 351Summary 351  Chapter 16: Communicating the Requirements 353in which we turn the requirements into communicable formFormality Guide 353Turning Potential Requirements into Written Requirements 354Knowledge Versus Specification 354The Volere Requirements Specification Template 357Discovering Atomic Requirements 359Attributes of Atomic Requirements 361Assembling the Specification 365Automated Requirements Tools 366Functional Requirements 367Non-functional Requirements 368Project Issues 369Summary 369  Chapter 17: Requirements Completeness 371in which we decide whether our specification is complete, and set the priorities of the requirementsFormality Guide 372Reviewing the Specification 373Inspections 373Find Missing Requirements 374Have All Business Use Cases Been Discovered? 376Prioritizing the Requirements 382Conflicting Requirements 386Ambiguous Specifications 388Risk Assessment 388Measure the Required Cost 391Summary 391  Appendix A: Volere Requirements Specification Template 393a guide for writing a rigorous and complete requirements specificationContents 393Use of This Template 394Volere 394Requirements Types 395Testing Requirements 396Atomic Requirements Shell 3961. The Purpose of the Project 3972. The Stakeholders 4003. Mandated Constraints 4074. Naming Conventions and Terminology 4155. Relevant Facts and Assumptions 4166. The Scope of the Work 4207. Business Data Model and Data Dictionary 4258. The Scope of the Product 4299. Functional and Data Requirements 433Non-functional Requirements 43510. Look and Feel Requirements 43511. Usability and Humanity Requirements 43712. Performance Requirements 44113. Operational and Environmental Requirements 44714. Maintainability and Support Requirements 44915. Security Requirements 45116. Cultural Requirements 45417. Legal Requirements 455Project Issues 45718. Open Issues 45719. Off-the-Shelf Solutions 45820. New Problems 46021. Tasks 46222. Migration to the New Product 46323. Risks 46524. Costs 46725. User Documentation and Training 46826. Waiting Room 47027. Ideas for Solutions 471  Appendix B: Stakeholder Management Templates 473Stakeholder Map 473Stakeholder Template 475  Appendix C: Function Point Counting: A Simplified Introduction 479in 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 effortMeasuring the Work 479A Quick Primer on Counting Function Points 481Counting Function Points for Business Use Cases 484Counting the Stored Data 489Adjust for What You Don’t Know 492Now That I Have Counted Function Points, What’s Next? 492  Appendix D: Volere Requirements Knowledge Model 495Definitions of Requirements Knowledge Classes and Associations 495  Glossary 511Bibliography 517Index 523