WIXLIB

Sample ChaptersCopyright 2013 by Karl Wiegers and SeilevelAll rights reserved.To learn more about this book visit:http://aka.ms/SoftwareReq3E/details

ContentsIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvAcknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiPART ISOFTWARE REQUIREMENTS: WHAT, WHY, AND WHOChapter 1The essential software requirement3Software requirements defined. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Some interpretations of ”requirement”. . . . . . . . . . . . . . . . . . . . . . . . . 6Levels and types of requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Working with the three levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Product vs. project requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Requirements development and management. . . . . . . . . . . . . . . . . . . . . . . 15Requirements development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Requirements management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Every project has requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18When bad requirements happen to good people. . . . . . . . . . . . . . . . . . . . 19Insufficient user involvement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Inaccurate planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Creeping user requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Ambiguous requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Gold plating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Overlooked stakeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Benefits from a high-quality requirements process. . . . . . . . . . . . . . . . . . . 22Chapter 2Requirements from the customer’s perspective25The expectation gap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Who is the customer?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27The customer-development partnership. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Requirements Bill of Rights for Software Customers. . . . . . . . . . . . . 31Requirements Bill of Responsibilities for Software Customers. . . . . 33ix

Creating a culture that respects requirements . . . . . . . . . . . . . . . . . . . . . . . 36Identifying decision makers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Reaching agreement on requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38The requirements baseline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39What if you don’t reach agreement?. . . . . . . . . . . . . . . . . . . . . . . . . . 40Agreeing on requirements on agile projects . . . . . . . . . . . . . . . . . . . 41Chapter 3Good practices for requirements engineering43A requirements development process framework. . . . . . . . . . . . . . . . . . . . 45Good practices: Requirements elicitation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Good practices: Requirements analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Good practices: Requirements specification. . . . . . . . . . . . . . . . . . . . . . . . . 51Good practices: Requirements validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Good practices: Requirements management . . . . . . . . . . . . . . . . . . . . . . . . 53Good practices: Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Good practices: Project management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Getting started with new practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Chapter 4The business analyst61The business analyst role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62The business analyst’s tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Essential analyst skills. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Essential analyst knowledge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68The making of a business analyst. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68The former user. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68The former developer or tester. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69The former (or concurrent) project manager. . . . . . . . . . . . . . . . . . . 70The subject matter expert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70The rookie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71The analyst role on agile projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Creating a collaborative team. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72xContents

PART IIREQUIREMENTS DEVELOPMENTChapter 5Establishing the business requirements77Defining business requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Identifying desired business benefits. . . . . . . . . . . . . . . . . . . . . . . . . . 78Product vision and project scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Conflicting business requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Vision and scope document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811. Business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832. Scope and limitations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883. Business context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Scope representation techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Context diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Ecosystem map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Feature tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Event list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Keeping the scope in focus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Using business objectives to make scoping decisions. . . . . . . . . . . . 97Assessing the impact of scope changes. . . . . . . . . . . . . . . . . . . . . . . . 98Vision and scope on agile projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Using business objectives to determine completion. . . . . . . . . . . . . . . . . . 99Chapter 6Finding the voice of the user101User classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Classifying users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Identifying your user classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105User personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Connecting with user representatives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108The product champion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109External product champions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Product champion expectations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Multiple product champions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Contentsxi

Selling the product champion idea. . . . . . . . . . . . . . . . . . . . . . . . . . . 113Product champion traps to avoid. . . . . . . . . . . . . . . . . . . . . . . . . . . . 114User representation on agile projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Resolving conflicting requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Chapter 7Requirements elicitation119Requirements elicitation techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Workshops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Focus groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Observations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Questionnaires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127System interface analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127User interface analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Document analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Planning elicitation on your project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Preparing for elicitation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Performing elicitation activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Following up after elicitation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Organizing and sharing the notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Documenting open issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Classifying customer input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135How do you know when you’re done?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Some cautions about elicitation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Assumed and implied requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Finding missing requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Chapter 8Understanding user requirements143Use cases and user stories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144The use case approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Use cases and usage scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Identifying use cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157xiiContents