Now in its third edition, this classic guide to software requirements engineering has been fully updated with new topics, examples, and guidance. Two leaders in the requirements community have teamed up to deliver a contemporary set of practices covering the full range of requirements development and management activities on software projects.
Introduction
Acknowledgments
Software requirements: What, why, and who Chapter 1: The essential software requirement
Chapter 2: Requirements from the customer's perspective
Chapter 3: Good practices for requirements engineering
Chapter 4: The business analyst
Requirements development Chapter 5: Establishing the business requirements
Chapter 6: Finding the voice of the user
Chapter 7: Requirements elicitation
Chapter 8: Understanding user requirements
Chapter 9: Playing by the rules
Chapter 10: Documenting the requirements
Chapter 11: Writing excellent requirements
Chapter 12: A picture is worth 1024 words
Chapter 13: Specifying data requirements
Chapter 14: Beyond functionality
Chapter 15: Risk reduction through prototyping
Chapter 16: First things first: Setting requirement priorities
Chapter 17: Validating the requirements
Chapter 18: Requirements reuse
Chapter 19: Beyond requirements development
Requirements for specific project classes Chapter 20: Agile projects
Chapter 21: Enhancement and replacement projects
Chapter 22: Packaged solution projects
Chapter 23: Outsourced projects
Chapter 24: Business process automation projects
Chapter 25: Business analytics projects
Chapter 26: Embedded and other real-time systems projects
Requirements management Chapter 27: Requirements management practices
Chapter 28: Change happens
Chapter 29: Links in the requirements chain
Chapter 30: Tools for requirements engineering
Implementing requirements engineering Chapter 31: Improving your requirements processes
Chapter 32: Software requirements and risk management
Epilogue
Current requirements practice self-assessment
Requirements troubleshooting guide
Sample requirements documents
Glossary
About the authors
Software Requirements 3 Karl Wiegers Pdf
2. Simply put, this book is both a must-read and a greatreference for anyone working to define and manage softwaredevelopment projects. In todays modern software development world,too often sound requirements practices are set aside for the lureof unencumbered agile. Karl and Joy have detailed a progressiveapproach to managing requirements, and detailed how to accommodatethe ever-changing approaches to delivering software. Mark Kulak,Software Development Director, Borland, a Micro Focus company I amso pleased to see the updated book on software requirements fromKarl Wiegers and Joy Beatty. I especially like the latest topic onhow to apply effective requirements practices to agile projects,because it is a service that our consultants are engaged in moreand more these days. The practical guide and real examples of themany different requirement practices are invaluable. Doreen Evans,Managing Director of the Requirements and Business AnalysisPractice for Robbins Gioia Inc. As an early adopter of Karlsclassic book, Software Requirements, I have been eagerly awaitinghis new editionand it doesnt disappoint. Over the years, ITdevelopment has undergone a change of focus from large, new,green-field projects towards adoption of ready-made off-the-shelfsolutions and quick-release agile practices. In this latestedition, Karl and Joy explore the implications of these newdevelopments on the requirements process, with invaluablerecommendations based not on dogma but on what works, honed fromtheir broad and deep experience in the field. Howard Podeswa, CEO,Noble Inc., and author of The Business Analysts Handbook If you arelooking for a practical guide into what software requirements are,how to craft them, and what to do with them, then look no furtherthan Software Requirements, Third Edition. This usable and readabletext walks you through exactly how to approach commonrequirements-related scenarios. The incorporation of multiplestories, case studies, anecdotes, and examples keeps it engaging toread. Laura Brandenburg, CBAP, Host at Bridging the Gap How do youmake a good requirements read better? You add content like Karl andJoy did to address incorporating product vision, tackling agilityissues, covering requirements reuse, tackling packaged andoutsourced software, and addressing specific user classes. Youcould take an outside look inside of requirements to addressprocess and risk issues and go beyond just capturing functionality.Donald J. Reifer, President, Reifer Consultants LLC This newedition keeps pace with the speed of business, both in deepeningthe foundation of the second edition and in bringing analystsdown-to-earth how-tos for addressing the surge in agiledevelopment, using features to control scope, improving elicitationtechniques, and expanding modeling. Wiegers and Beatty have puttogether a must-read for anyone in the profession. Keith Ellis,President and CEO, Enfocus Solutions Inc., and author of BusinessAnalysis Benchmark 3. Software Requirements, Third Edition KarlWiegers and Joy Beatty 4. PUBLISHED BY Microsoft Press A Divisionof Microsoft Corporation One Microsoft Way Redmond, Washington98052-6399 Copyright 2013 Karl Wiegers and Seilevel All rightsreserved. No part of the contents of this book may be reproduced ortransmitted in any form or by any means without the writtenpermission of the publisher. Library of Congress Control Number:2013942928 ISBN: 978-0-7356-7966-5MicrosoftPressbooksareavailablethroughbooksellersanddistributorsworldwide.Ifyouneedsupportrelatedtothisbook, email Microsoft Press Book Support at [email protected]Please tell us what you think of this book at Microsoft and thetrademarks listed at -US.aspx are trademarks of the Microsoft group ofcompanies. All other marks are property of their respective owners.The example companies, organizations, products, domain names, emailaddresses, logos, people, places, and events depicted herein arefictitious. No association with any real company, organization,product, domain name, email address, logo, person, place, or eventis intended or should be inferred. This book expresses the authorsviews and opinions. The information contained in this book isprovided without any express, statutory, or implied warranties.Neither the authors, Microsoft Corporation, nor its resellers, ordistributors will be held liable for any damages caused or allegedto be caused either directly or indirectly by this book.Acquisitions Editor: Devon Musgrave Developmental Editors: DevonMusgrave and Carol Dillingham Project Editor: Carol DillinghamEditorial Production: Christian Holdener, S4Carlisle PublishingServices Copyeditor: Kathy Krause Indexer: Maureen Johnson Cover:Twist Creative Seattle [LSI] [2013-09-06] 5. For Chris, yet again.Eighth times the charm. K.W. For my parents, Bob and Joanne, for alifetime of encouragement. J.B. 6. Contents at a glanceIntroductionxxv Acknowledgmentsxxxi PART I SOFTWARE REQUIREMENTS:WHAT, WHY, AND WHO CHAPTER 1 The essential software requirement 3CHAPTER 2 Requirements from the customers perspective 25 CHAPTER 3Good practices for requirements engineering 43 CHAPTER 4 Thebusiness analyst 61 PART II REQUIREMENTS DEVELOPMENT CHAPTER 5Establishing the business requirements 77 CHAPTER 6 Finding thevoice of the user 101 CHAPTER 7 Requirements elicitation 119CHAPTER 8 Understanding user requirements 143 CHAPTER 9 Playing bythe rules 167 CHAPTER 10 Documenting the requirements 181 CHAPTER11 Writing excellent requirements 203 CHAPTER 12 A picture is worth1024 words 221 CHAPTER 13 Specifying data requirements 245 CHAPTER14 Beyond functionality 261 CHAPTER 15 Risk reduction throughprototyping 295 CHAPTER 16 First things first: Setting requirementpriorities 313 CHAPTER 17 Validating the requirements 329 CHAPTER18 Requirements reuse 351 CHAPTER 19 Beyond requirementsdevelopment 365 PART III REQUIREMENTS FOR SPECIFIC PROJECT CLASSESCHAPTER 20 Agile projects 383 CHAPTER 21 Enhancement andreplacement projects 393 CHAPTER 22 Packaged solution projects 405CHAPTER 23 Outsourced projects 415 7. viii Contents at a glanceCHAPTER 24 Business process automation projects 421 CHAPTER 25Business analytics projects 427 CHAPTER 26 Embedded and otherreal-time systems projects 439 PART IV REQUIREMENTS MANAGEMENTCHAPTER 27 Requirements management practices 457 CHAPTER 28 Changehappens 471 CHAPTER 29 Links in the requirements chain 491 CHAPTER30 Tools for requirements engineering 503 PART V IMPLEMENTINGREQUIREMENTS ENGINEERING CHAPTER 31 Improving your requirementsprocesses 517 CHAPTER 32 Software requirements and risk management537 Epilogue549 Appendix A 551 Appendix B 559 Appendix C 575Glossary597 References605 Index619 8. ix Contents Introduction. . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . xxv Acknowledgments. . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . xxxi PART I SOFTWARE REQUIREMENTS: WHAT, WHY, AND WHOChapter 1 The essential software requirement 3 Softwarerequirements defined. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 5 Some interpretations of requirement. .. . . . . . . . . . . . . . . . . . . . . . . 6 Levels and types ofrequirements. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 7 Working with the three levels. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 12 Product vs. projectrequirements. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 14 Requirements development and management. . . . . . . . . . . .. . . . . . . . . . . 15 Requirements development. . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . 15 Requirementsmanagement. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 17 Every project has requirements. . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . 18 When badrequirements happen to good people. . . . . . . . . . . . . . . . .. . . 19 Insufficient user involvement. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . 20 Inaccurate planning. . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 20 Creeping user requirements. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . 20 Ambiguous requirements. . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Gold plating . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 21 Overlooked stakeholders.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 22 Benefits from a high-quality requirements process. . . . . . .. . . . . . . . . . . . 22 Chapter 2 Requirements from thecustomers perspective 25 The expectation gap. . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 Who is the customer?. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 27 Thecustomer-development partnership. . . . . . . . . . . . . . . . . .. . . . . . . . . . 29 Requirements Bill of Rights for SoftwareCustomers. . . . . . . . . . . . . 31 Requirements Bill ofResponsibilities for Software Customers. . . . . 33 9. x ContentsCreating a culture that respects requirements. . . . . . . . . . .. . . . . . . . . . . . 36 Identifying decision makers. . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Reaching agreement on requirements. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 38 The requirements baseline. . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 What ifyou dont reach agreement?. . . . . . . . . . . . . . . . . . . . .. . . . . 40 Agreeing on requirements on agile projects. . . . . .. . . . . . . . . . . . . 41 Chapter 3 Good practices forrequirements engineering 43 A requirements development processframework. . . . . . . . . . . . . . . . . . . . 45 Good practices:Requirements elicitation. . . . . . . . . . . . . . . . . . . . . .. . . . . . 48 Good practices: Requirements analysis. . . . . . . .. . . . . . . . . . . . . . . . . . . . . . 50 Good practices:Requirements specification. . . . . . . . . . . . . . . . . . . . .. . . . 51 Good practices: Requirements validation. . . . . . . . .. . . . . . . . . . . . . . . . . . . 52 Good practices:Requirements management . . . . . . . . . . . . . . . . . . . . . .. . 53 Good practices: Knowledge. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . 54 Good practices:Project management. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . 56 Getting started with new practices. . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . 57 Chapter 4 Thebusiness analyst 61 The business analyst role. . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62The business analysts tasks . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 63 Essential analyst skills.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . 65 Essential analyst knowledge. . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Themaking of a business analyst. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . 68 The former user. . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 The former developer or tester. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 69 The former (or concurrent) projectmanager. . . . . . . . . . . . . . . . . . . 70 The subject matterexpert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 70 The rookie. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . 71 The analystrole on agile projects. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . 71 Creating a collaborative team. . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7210. Contents xi PART II REQUIREMENTS DEVELOPMENT Chapter 5Establishing the business requirements 77 Defining businessrequirements. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . 78 Identifying desired business benefits. . . . . .. . . . . . . . . . . . . . . . . . . . 78 Product vision andproject scope. . . . . . . . . . . . . . . . . . . . . . . . . . .. . 78 Conflicting business requirements. . . . . . . . . . . . . .. . . . . . . . . . . . . . 80 Vision and scope document. . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 1. Business requirements . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 83 2. Scope and limitations. . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88 3. Business context. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 90 Scope representationtechniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . 92 Context diagram. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . 92 Ecosystem map.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . 94 Feature tree. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Event list. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . 96 Keeping the scope infocus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 97 Using business objectives to make scopingdecisions. . . . . . . . . . . . 97 Assessing the impact of scopechanges. . . . . . . . . . . . . . . . . . . . . . . . 98 Visionand scope on agile projects. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 98 Using business objectives to determinecompletion. . . . . . . . . . . . . . . . . . 99 Chapter 6 Findingthe voice of the user 101 User classes . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 102 Classifying users. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . 102 Identifyingyour user classes. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 105 User personas . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Connecting with user representatives. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 108 The product champion . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 109 External product champions. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 110 Product champion expectations. . .. . . . . . . . . . . . . . . . . . . . . . . . . . 111 Multipleproduct champions. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 112 11. xii Contents Selling the product championidea. . . . . . . . . . . . . . . . . . . . . . . . . . . 113Product champion traps to avoid. . . . . . . . . . . . . . . . . .. . . . . . . . . . 114 User representation on agile projects. . .. . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Resolvingconflicting requirements. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . 116 Chapter 7 Requirements elicitation 119Requirements elicitation techniques. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . 121 Interviews . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 121 Workshops. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . 122 Focus groups. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . 124 Observations. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Questionnaires. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . 127 System interface analysis. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 User interface analysis. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . 128 Document analysis. . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 128 Planning elicitation on your project. . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 129 Preparing forelicitation. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 130 Performing elicitation activities.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132 Following up after elicitation. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 134 Organizing and sharingthe notes. . . . . . . . . . . . . . . . . . . . . . . . . . . .134 Documenting open issues. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 135 Classifying customer input. . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135 How do you know when youre done?. . . . . . . . . . . . . . . .. . . . . . . . . . . . . 138 Some cautions about elicitation. . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Assumed and implied requirements. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 140 Finding missing requirements . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Chapter 8 Understanding user requirements 143 Use cases and userstories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . 144 The use case approach. . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Use cases and usage scenarios . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . 149 Identifying use cases. . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 12.Contents xiii Exploring use cases. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 158 Validating usecases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 160 Use cases and functional requirements. . . .. . . . . . . . . . . . . . . . . . . 161 Use case traps to avoid.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 163 Benefits of usage-centric requirements. . . . . . . . . . .. . . . . . . . . . . . . . . . . 164 Chapter 9 Playing by therules 167 A business rules taxonomy. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 169 Facts. . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 170 Constraints. . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..170 Action enablers. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 171 Inferences . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . 173 Computations. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Atomicbusiness rules. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . 174 Documenting business rules. . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Discovering business rules. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 177 Business rules andrequirements. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . 178 Tying everything together. . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Chapter10 Documenting the requirements 181 The software requirementsspecification. . . . . . . . . . . . . . . . . . . . . . . . . . .183 Labeling requirements. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 186 Dealing with incompleteness. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188User interfaces and the SRS. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 189 A software requirements specificationtemplate . . . . . . . . . . . . . . . . . . . . 190 1.Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 192 2. Overall description. . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193 3. System features. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . 194 4. Data requirements. . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 195 5. External interface requirements. . . . . . . . . . . . . .. . . . . . . . . . . . . 196 6. Quality attributes. . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1977. Internationalization and localization requirements. . . . . . .. . . . 198 8. [Other requirements]. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . 199 13. xiv ContentsAppendix A: Glossary . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . 199 Appendix B: Analysis models. . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Requirements specification on agile projects. . . . . . . . . . . .. . . . . . . . . . . 199 Chapter 11 Writing excellent requirements203 Characteristics of excellent requirements. . . . . . . . . . .. . . . . . . . . . . . . . . . 203 Characteristics of requirementstatements. . . . . . . . . . . . . . . . . . . . 204Characteristics of requirements collections. . . . . . . . . . . .. . . . . . . . 205 Guidelines for writing requirements. . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . 207 System oruser perspective. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . 207 Writing style. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Levelof detail. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 211 Representation techniques. . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212Avoiding ambiguity. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . 213 Avoiding incompleteness. . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216Sample requirements, before and after. . . . . . . . . . . . . . .. . . . . . . . . . . . . 217 Chapter 12 A picture is worth 1024words 221 Modeling the requirements. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . 222 From voice of thecustomer to analysis models . . . . . . . . . . . . . . . . . . . .. 223 Selecting the right representations. . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 225 Data flow diagram . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . 226 Swimlane diagram. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230State-transition diagram and state table. . . . . . . . . . . . . .. . . . . . . . . . . . . 232 Dialog map. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 235 Decision tables and decision trees. . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 239 Event-responsetables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 240 A few words about UML diagrams. . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243Modeling on agile projects. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . 243 A final reminder. . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 244 14. Contents xv Chapter 13 Specifying datarequirements 245 Modeling data relationships. . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . 245 The datadictionary. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . 248 Data analysis. . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 251 Specifying reports. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252 Eliciting reporting requirements. . . . . . . . . . . . . . . .. . . . . . . . . . . . . 253 Report specification considerations.. . . . . . . . . . . . . . . . . . . . . . . . . 254 A reportspecification template. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 255 Dashboard reporting. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257Chapter 14 Beyond functionality 261 Software quality attributes. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 262 Exploring quality attributes. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . 263 Definingquality requirements. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 267 External quality attributes . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Internal quality attributes. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . 281 Specifying quality requirementswith Planguage. . . . . . . . . . . . . . . . . . . . 287 Qualityattribute trade-offs. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . 288 Implementing quality attributerequirements. . . . . . . . . . . . . . . . . . . . . . . 290Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . 291 Handlingquality attributes on agile projects. . . . . . . . . . . . . . . .. . . . . . . 293 Chapter 15 Risk reduction through prototyping 295Prototyping: What and why. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . 296 Mock-ups and proofs ofconcept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 297 Throwaway and evolutionary prototypes. . . . . . . . .. . . . . . . . . . . . . . . . . . 298 Paper and electronicprototypes. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 301 Working with prototypes. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .303 Prototypeevaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . 306 15. xvi Contents Risks ofprototyping. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . 307 Pressure to release theprototype. . . . . . . . . . . . . . . . . . . . . . . . . . . .308 Distraction by details. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . 308 Unrealistic performanceexpectations. . . . . . . . . . . . . . . . . . . . . . . . 309Investing excessive effort in prototypes . . . . . . . . . . . . .. . . . . . . . . 309 Prototyping success factors . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310Chapter 16 First things first: Setting requirement priorities 313Why prioritize requirements?. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . 314 Some prioritizationpragmatics. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . 315 Games people play with priorities. . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . 316 Someprioritization techniques . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 317 In or out. . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 318 Pairwise comparison and rank ordering. . . . . . . . . .. . . . . . . . . . . . 318 Three-level scale. . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319MoSCoW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . 320 $100. . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 321 Prioritization based on value, cost, and risk. .. . . . . . . . . . . . . . . . . . . . . . . 322 Chapter 17Validating the requirements 329 Validation and verification. . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 331 Reviewing requirements. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . 332 The inspectionprocess. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 333 Defect checklist . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . 338Requirements review tips. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 339 Requirements review challenges. . . .. . . . . . . . . . . . . . . . . . . . . . . . . 340 Prototypingrequirements. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 342 Testing the requirements. . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .342 Validating requirements with acceptance criteria. . . . . . . .. . . . . . . . . . . . 347 Acceptance criteria . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347Acceptance tests. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . 348 16. Contents xvii Chapter 18Requirements reuse 351 Why reuse requirements?. . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352Dimensions of requirements reuse. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 352 Extent of reuse. . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .353 Extent of modification. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . 354 Reuse mechanism. . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 354 Types of requirements information to reuse. . . . . . . . . .. . . . . . . . . . . . . . 355 Common reuse scenarios . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .356 Software product lines. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 356 Reengineered and replacementsystems. . . . . . . . . . . . . . . . . . . . . . 357 Other likelyreuse opportunities. . . . . . . . . . . . . . . . . . . . . . . .. . . . . 357 Requirement patterns . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . 358 Tools tofacilitate reuse. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 359 Making requirements reusable. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .360 Requirements reuse barriers and success factors. . . . . . . .. . . . . . . . . . . . 362 Reuse barriers. . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362Reuse success factors. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 363 Chapter 19 Beyond requirementsdevelopment 365 Estimating requirements effort . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . 366 Fromrequirements to project plans. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 369 Estimating project size and effort fromrequirements. . . . . . . . . . 370 Requirements and scheduling. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 Fromrequirements to designs and code. . . . . . . . . . . . . . . . . .. . . . . . . . . 373 Architecture and allocation. . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . 373 Softwaredesign. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 374 User interface design. . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375From requirements to tests. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . 377 From requirements tosuccess. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . 379 17. xviii Contents PART III REQUIREMENTS FORSPECIFIC PROJECT CLASSES Chapter 20 Agile projects 383 Limitationsof the waterfall. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 384 The agile development approach. . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385Essential aspects of an agile approach to requirements. . . . . . .. . . . . . . 385 Customer involvement. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . 386 Documentationdetail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 386 The backlog and prioritization . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . 387 Timing . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . 387 Epics, user stories, and features, oh my! .. . . . . . . . . . . . . . . . . . . . . 388 Expect change . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . 389 Adapting requirements practices to agile projects.. . . . . . . . . . . . . . . . . . 390 Transitioning to agile: Nowwhat?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 390 Chapter 21 Enhancement and replacement projects 393Expected challenges. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . 394 Requirementstechniques when there is an existing system. . . . . . . . . . .394 Prioritizing by using business objectives . . . . . . . . . . .. . . . . . . . . . . . . . . . 396 Mind the gap . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 396 Maintaining performance levels. . . . . . . . . . . . . . .. . . . . . . . . . . . . . 397 When old requirements dont exist. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398Which requirements should you specify?. . . . . . . . . . . . . . .. . . . . . 398 How to discover the requirements of an existingsystem. . . . . . . . 400 Encouraging new system adoption. . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Can weiterate?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 402 Chapter 22 Packagedsolution projects 405 Requirements for selecting packagedsolutions. . . . . . . . . . . . . . . . . . . . . 406 Developinguser requirements . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 406 Considering business rules. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 407 Identifying data needs.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 407 18. Contents xix Defining quality requirements. . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . 408 Evaluatingsolutions. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . 408 Requirements for implementing packagedsolutions . . . . . . . . . . . . . . . . 411 Configurationrequirements. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 411 Integration requirements. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 412 Extension requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 412 Data requirements. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 412 Business process changes.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .413 Common challenges with packaged solutions . . . . . . . . . . .. . . . . . . . . . . 413 Chapter 23 Outsourced projects 415Appropriate levels of requirements detail. . . . . . . . . . . . .. . . . . . . . . . . . . 416 Acquirer-supplier interactions. . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418Change management. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 419 Acceptance criteria. . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 420 Chapter 24 Business process automationprojects 421 Modeling business processes. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 422 Using currentprocesses to derive requirements. . . . . . . . . . . . . . . 423Designing future processes first. . . . . . . . . . . . . . . . . .. . . . . . . . . . . 424 Modeling business performance metrics. .. . . . . . . . . . . . . . . . . . . . . . . . . 424 Goodpractices for business process automation projects. . . . . . . . .. . . 426 Chapter 25 Business analytics projects 427 Overview ofbusiness analytics projects. . . . . . . . . . . . . . . . . . . .. . . . . . . . 427 Requirements development for business analyticsprojects. . . . . . . . . . . 429 Prioritizing work by usingdecisions. . . . . . . . . . . . . . . . . . . . . . . . . . 430Defining how information will be used. . . . . . . . . . . . . . .. . . . . . . . 431 Specifying data needs. . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . 432 Defininganalyses that transform the data . . . . . . . . . . . . . . . . .. . . 435 The evolutionary nature of analytics. . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 436 19. xx Contents Chapter26 Embedded and other real-time systems projects 439 Systemrequirements, architecture, and allocation. . . . . . . . . . . . .. . . . . . 440 Modeling real-time systems. . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . 441 Contextdiagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 442 State-transition diagram. . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442Event-response table. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . 443 Architecture diagram. . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445Prototyping. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 446 Interfaces. . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 446 Timing requirements. . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .447 Quality attributes for embedded systems. . . . . . . . . . . .. . . . . . . . . . . . . . 449 The challenges of embedded systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 PARTIV REQUIREMENTS MANAGEMENT Chapter 27 Requirements managementpractices 457 Requirements management process. . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 458 The requirementsbaseline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 459 Requirements version control. . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 460Requirement attributes. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 462 Tracking requirementsstatus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . 464 Resolving requirements issues. . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . 466 Measuringrequirements effort. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . 467 Managing requirements on agile projects.. . . . . . . . . . . . . . . . . . . . . . . . . 468 Why managerequirements?. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . 470 Chapter 28 Change happens 471 Why managechanges?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 471 Managing scope creep. . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .472 Change control policy. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . 474 Basic concepts ofthe change control process. . . . . . . . . . . . . . . . . . . . .. . 474 20. Contents xxi A change control process description. . .. . . . . . . . . . . . . . . . . . . . . . . . . . . 475 1.Purpose and scope . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 476 2. Roles and responsibilities. . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 3.Change request status . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 477 4. Entry criteria. . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .478 5. Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 478 6. Exit criteria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . 479 7. Change control status reporting. . . .. . . . . . . . . . . . . . . . . . . . . . . 479 Appendix:Attributes stored for each request. . . . . . . . . . . . . . . . .. 479 The change control board. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . 480 CCB composition. . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 480 CCB charter. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . 481Renegotiating commitments. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . 482 Change control tools. . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .482 Measuring change activity. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 483 Change impact analysis.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 484 Impact analysis procedure. . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . 484 Impact analysistemplate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 488 Change management on agile projects. . . . . . . . .. . . . . . . . . . . . . . . . . . . 488 Chapter 29 Links in therequirements chain 491 Tracing requirements. . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491Motivations for tracing requirements. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 494 The requirements traceabilitymatrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .495 Tools for requirements tracing. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 498 A requirements tracingprocedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . .499 Is requirements tracing feasible? Is it necessary?. . .. . . . . . . . . . . . . . . . . 501 Chapter 30 Tools forrequirements engineering 503 Requirements development tools. . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505Elicitation tools. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 505 Prototyping tools. . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 505 Modeling tools. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 506 21. xxii ContentsRequirements management tools. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 506 Benefits of using an RM tool. . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 506 RM toolcapabilities. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 508 Selecting and implementing arequirements tool . . . . . . . . . . . . . . . . . . . 510Selecting a tool. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . 511 Setting up the tool andprocesses . . . . . . . . . . . . . . . . . . . . . . . . . . . 511Facilitating user adoption. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 513 PART V IMPLEMENTING REQUIREMENTSENGINEERING Chapter 31 Improving your requirements processes 517How requirements relate to other project processes. . . . . . . . .. . . . . . . . 518 Requirements and various stakeholder groups. .. . . . . . . . . . . . . . . . . . . . 520 Gaining commitment tochange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 521 Fundamentals of software process improvement. . . . . .. . . . . . . . . . . . . . 522 Root cause analysis. . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 524 The process improvement cycle. . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . 526 Assess currentpractices. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 526 Plan improvement actions. . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . 527 Create, pilot, androll out processes. . . . . . . . . . . . . . . . . . . . . . . . .. 528 Evaluate results. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . 529 Requirementsengineering process assets. . . . . . . . . . . . . . . . . . . . .. . . . . 530 Requirements development process assets. . . . . . .. . . . . . . . . . . . . 531 Requirements management processassets . . . . . . . . . . . . . . . . . . . 532 Are we there yet?.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 533 Creating a requirements processimprovement road map. . . . . . . . . . . . 535 Chapter 32 Softwarerequirements and risk management 537 Fundamentals of software riskmanagement. . . . . . . . . . . . . . . . . . . . . . . . 538Elements of risk management. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . 538 Documenting project risks. . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . 539 Planningfor risk management . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . 542 22. Contents xxiii Requirements-related risks. . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 542 Requirements elicitation. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . 543 Requirements analysis. . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 544 Requirements specification . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 545 Requirements validation. . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545Requirements management. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . 546 Risk management is your friend. . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546Epilogue549 Appendix A 551 Appendix B 559 Appendix C 575Glossary597 References605 Index619 23. xxv Introduction Despitedecades of industry experience, many software organizationsstruggle to understand, document, and manage their productrequirements. Inadequate user input, incomplete requirements,changing requirements, and misunderstood business objectives aremajor reasons why so many information technology projects are lessthan fully successful. Some software teams arent proficient ateliciting requirements from customers and other sources. Customersoften dont have the time or patience to participate in requirementsactivities. In many cases, project participants dont even agree onwhat a requirement is. As one writer observed, Engineers wouldrather decipher the words to the Kingsmens 1963 classic party songLouie Louie than decipher customer requirements (Peterson 2002).The second edition of Software Requirements was published 10 yearsprior to this one. Ten years is a long time in the technologyworld. Many things have changed in that time, but others have not.Major requirements trends in the past decade include: Therecognition of business analysis as a professional discipline andthe rise of professional certifications and organizations, such asthe International Institute of Business Analysis and theInternational Requirements Engineering Board. The maturing of toolsboth for managing requirements in a database and for assisting withrequirements development activities such as prototyping, modeling,and simulation. The increased use of agile development methods andthe evolution of techniques for handling requirements on agileprojects. The increased use of visual models to representrequirements knowledge. So, what hasnt changed? Two factorscontribute to keeping this topic important and relevant. First,many undergraduate curricula in software engineering and computerscience continue to underemphasize the importance of requirementsengineering (which encompasses both requirements development andrequirements management). And second, those of us in the softwaredomain tend to be enamored with technical and process solutions toour challenges. We sometimes fail to appreciate that requirementselicitationand much of software and systems project work in generalis primarily a human interaction challenge. No magical newtechniques have come along to automate that, although various toolsare available to help geographically separated people collaborateeffectively. 24. xxvi Introduction We believe that the practicespresented in the second edition for developing and managingrequirements are still valid and applicable to a wide range ofsoftware projects. The creative business analyst, product manager,or product owner will thoughtfully adapt and scale the practices tobest meet the needs of a particular situation. Newly added to thisthird edition are a chapter on handling requirements for agileprojects and sections in numerous other chapters that describe howto apply and adapt the practices in those chapters to the agiledevelopment environment. Software development involves at least asmuch communication as it does computing, yet both educationalcurricula and project activities often emphasize the computing overthe communication aspect. This book offers dozens of tools tofacilitate that communication and to help software practitioners,managers, marketers, and customers apply effective requirementsengineering methods. The techniques presented here constitute atool kit of mainstream good practices, not exotic new techniques oran elaborate methodology that purports to solve all of yourrequirements problems. Numerous anecdotes and sidebars presentstoriesall truethat illustrate typical requirements-relatedexperiences; you have likely had similar experiences. Look for thetrue stories icon, like the one to the left, next to real examplesdrawn from many project experiences. Since the first edition ofthis book appeared in 1999, we have each worked on numerousprojects and taught hundreds of classes on software requirements topeople from companies and government agencies of all sizes andtypes. Weve learned that these practices are useful on virtuallyany project: small projects and large, new development andenhancements, with local and distributed teams, and usingtraditional and agile development methods. The techniques apply tohardware and systems engineering projects, too, not just softwareprojects. As with any other technical practice, youll need to usegood judgment and experience to learn how to make the methods workbest for you. Think of these practices as tools to help ensure thatyou have effective conversations with the right people on yourprojects. Benefits this book provides Of all the software processimprovements you could undertake, improved requirements practicesare among the most beneficial. We describe practical, proventechniques that can help you to: Write high-quality requirementsfrom the outset of a project, thereby minimizing rework andmaximizing productivity. 25. Introduction xxvii Deliverhigh-quality information systems and commercial products thatachieve their business objectives. Manage scope creep andrequirements changes to stay both on target and under control.Achieve higher customer satisfaction. Reduce maintenance,enhancement, and support costs. Our objective is to help youimprove the processes you use for eliciting and analyzingrequirements, writing and validating requirements specifications,and managing the requirements throughout the software productdevelopment cycle. The techniques we describe are pragmatic andrealistic. Both of us have used these very techniques many times,and we always get good results when we do. Who should read thisbook Anyone involved with defining or understanding therequirements for any system that contains software will find usefulinformation here. The primary audience consists of individuals whoserve as business analysts or requirements engineers on adevelopment project, be they full-time specialists or other teammembers who sometimes fill the analyst role. A second audienceincludes the architects, designers, developers, testers, and othertechnical team members who must understand and satisfy userexpectations and participate in the creation and review ofeffective requirements. Marketers and product managers who arecharged with specifying the features and attributes that will makea product a commercial success will find these practices valuable.Project managers will learn how to plan and track the projectsrequirements activities and deal with requirements changes. Yetanother audience is made up of stakeholders who participate indefining a product that meets their business, functional, andquality needs. This book will help end users, customers who procureor contract for software products, and numerous other stakeholdersunderstand the importance of the requirements process and theirroles in it. Looking ahead This book is organized into five parts.Part I, Software requirements: What, why, and who, begins with somedefinitions. If youre on the technical side of the house, pleaseshare Chapter 2, on the customer-development partnership, with yourkey customers. Chapter 3 summarizes several dozen good practicesfor requirements development 26. xxviii Introduction andmanagement, as well as an overall process framework forrequirements development. The role of the business analyst (a rolethat also goes by many other names) is the subject of Chapter 4.Part II, Requirements development, begins with techniques fordefining the projects business requirements. Other chapters in PartII address how to find appropriate customer representatives, elicitrequirements from them, and document user requirements, businessrules, functional requirements, data requirements, andnonfunctional requirements. Chapter 12 describes numerous visualmodels that represent the requirements from various perspectives tosupplement natural-language text, and Chapter 15 addresses the useof prototypes to reduce risk. Other chapters in Part II presentways to prioritize, validate, and reuse requirements. Part IIconcludes by describing how requirements affect other aspects ofproject work. New to this edition, Part III contains chapters thatrecommend the most effective requirements approaches for variousspecific classes of projects: agile projects developing products ofany type, enhancement and replacement projects, projects thatincorporate packaged solutions, outsourced projects, businessprocess automation projects, business analytics projects, andembedded and other real-time systems. The principles and practicesof requirements management are the subject of Part IV, withemphasis on techniques for dealing with changing requirements.Chapter 29 describes how requirements tracing connects individualrequirements both to their origins and to downstream developmentdeliverables. Part IV concludes with a description of commercialtools that can enhance the way your teams conduct both requirementsdevelopment and requirements management. The final section of thisbook, Part V, Implementing requirements engineering, helps you movefrom concepts to practice. Chapter 31 will help you incorporate newrequirements techniques into your groups development process.Common requirements-related project risks are described in Chapter32. The self-assessment in Appendix A can help you select areasthat are ripe for improvement. Two other appendices present arequirements troubleshooting guide and several sample requirementsdocuments so you can see how the pieces all fit together. Casestudies To illustrate the methods described in this book, we haveprovided examples from several case studies based on actualprojects, particularly a medium-sized information system called theChemical Tracking System. Dont worryyou dont need to know anythingabout chemistry to understand this project. Sample discussionsamong 27. Introduction xxix participants from the case studies aresprinkled throughout the book. No matter what kind of software yourorganization builds, youll be able to relate to these dialogs. Fromprinciples to practice Its difficult to muster the energy neededfor overcoming obstacles to change and putting new knowledge intoaction. As an aid for your journey to improved requirements, mostchapters end with several next steps, actions you can take to beginapplying the contents of that chapter immediately. Various chaptersoffer suggested templates for requirements documents, a reviewchecklist, a requirements prioritization spreadsheet, a changecontrol process, and many other process assets. These items areavailable for downloading at the companion content website for thisbook: Use them to jump-start yourapplication of these techniques. Start with small improvements, butstart today. Some people will be reluctant to try new requirementstechniques. Use this book to educate your peers, your customers,and your managers. Remind them of requirements-related problemsencountered on previous projects, and discuss the potentialbenefits of trying some new approaches. You dont need to launch anew development project to begin applying better requirementspractices. Chapter 21 discusses ways to apply many of thetechniques to enhancement and replacement projects. Implementingrequirements practices incrementally is a low-risk processimprovement approach that will prepare you for the next majorproject. The goal of requirements development is to accumulate aset of requirements that are good enough to allow your team toproceed with design and construction of the next portion of theproduct at an acceptable level of risk. You need to devote enoughattention to requirements to minimize the risks of rework,unacceptable products, and blown schedules. This book gives you thetools to get the right people to collaborate on developing theright requirements for the right product. 28. xxx IntroductionErrata & book support Weve made every effort to ensure theaccuracy of this book and its companion content. Any errors thathave been reported since this book was published are listed on ourMicrosoft Press site at oreilly.com: If you find an error that is notalready listed, you can report it to us through the same page. Ifyou need additional support, email Microsoft Press Book Support at[email protected] Please note that product support forMicrosoft software is not offered through the addresses above. Wewant to hear from you At Microsoft Press, your satisfaction is ourtop priority, and your feedback our most valuable asset. Pleasetell us what you think of this book at: Thesurvey is short, and we read every one of your comments and ideas.Thanks in advance for your input! Stay in touch Lets keep theconversation going! Were on Twitter: 29. xxxi Acknowledgments Writinga book like this is a team effort that goes far beyond thecontributions from the two authors. A number of people took thetime to review the full manuscript and offer countless suggestionsfor improvement; they have our deep gratitude. We especiallyappreciate the invaluable comments from Jim Brosseau, Joan Davis,Gary K. Evans, Joyce Grapes, Tina Heidenreich, Kelly MorrisonSmith, and Dr. Joyce Statz. Additional review input was receivedfrom Kevin Brennan, Steven Davis, Anne Hartley, Emily Iem, MattLeach, Jeannine McConnell, Yaaqub Mohamed, and John Parker. Certainindividuals reviewed specific chapters or sections in their areasof expertise, often providing highly detailed comments. We thankTanya Charbury, Mike Cohn, Dr. Alex Dean, Ellen Gottesdiener, ShaneHastie, James Hulgan, Dr. Phil Koopman, Mark Kulak, Shirley Sartin,Rob Siciliano, and Betsy Stockdale. We especially thank RoxanneMiller and Stephen Withall for their deep insights and generousparticipation. We discussed aspects of the books topics with manypeople, learning from their personal experiences and from resourcematerials they passed along to us. We appreciate such contributionsfrom Jim Brosseau, Nanette Brown, Nigel Budd, Katherine Busey,Tanya Charbury, Jennifer Doyle, Gary Evans, Scott Francis, SarahGates, Dr. David Gelperin, Mark Kerin, Norm Kerth, Dr. ScottMeyers, John Parker, Kathy Reynolds, Bill Trosky, Dr. RicardoValerdi, and Dr. Ian Watson. We also thank the many people who letus share their anecdotes in our true stories. Numerous staffmembers at Seilevel contributed to the book. They reviewed specificsections, participated in quick opinion and experience surveys,shared blog material they had written, edited final chapters, drewfigures, and helped us with operational issues of various sorts. Wethank Ajay Badri, Jason Benfield, Anthony Chen, Kell Condon, AmberDavis, Jeremy Gorr, Joyce Grapes, John Jertson, Melanie Norrell,David Reinhardt, Betsy Stockdale, and Christine Wollmuth. Theirwork made ours easier. The editorial input from Candase Hokanson isgreatly appreciated. Thanks go to many people at Microsoft Press,including acquisitions editor Devon Musgrave, project editor CarolDillingham, project editor Christian Holdener of S4CarlislePublishing Services, copy editor Kathy Krause, proofreader NicoleSchlutt, indexer Maureen Johnson, compositor Sambasivam Sangaran,and production artists Balaganesan M., Srinivasan R., andGaneshbabu G. Karl especially values his long-term relationship,and friendship, with Devon Musgrave and Ben Ryan. The comments andquestions from thousands of students in our requirements trainingclasses over the years have been most helpful in stimulating ourthinking about 30. xxxii Acknowledgments requirements issues. Ourconsulting experiences and the thought-provoking questions wereceive from readers have kept us in touch with what practitionersstruggle with on a daily basis and helped us think through some ofthese difficult topics. Please share your own experiences with usat [email protected] or [email protected] As always,Karl would like to thank his wife, Chris Zambito. And as always,she was patient and good-humored throughout the process. Karl alsothanks Joy for prompting him into working on this project and forher terrific contributions. Working with her was a lot of fun, andshe added a great deal of value to the book. It was great to havesomeone to bounce ideas off, to help make difficult decisions, andto chew hard on draft chapters before we inflicted them on thereviewers. Joy is particularly grateful to her husband, TonyHamilton, for supporting her writing dreams so soon again; to herdaughter, Skye, for making it easy to keep her daily prioritiesbalanced; and to Sean and Estelle for being the center of herfamily fun times. Joy wants to extend a special thanks to all ofthe Seilevel employees who collaborate to push the softwarerequirements field forward. She particularly wants to thank twocolleagues and friends: Anthony Chen, whose support for her writingthis book was paramount; and Rob Sparks, for his continuedencouragement in such endeavors. Finally, Joy owes a great deal ofgratitude to Karl for allowing her to join him in thisco-authorship, teaching her something new every day, and being anabsolute joy to work with! 31. 1 PART I Software requirements:What, why, and who CHAPTER 1 The essential software requirement. .. . . . . . . . . . .3 CHAPTER 2 Requirements from the customer'sperspective . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . 25 CHAPTER 3 Good practices for requirementsengineering . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 43 CHAPTER 4 The business analyst . . . . . . . . . . . .. . . . . . . . . . . . . . 61 32. 3 C H A P T E R 1 The essentialsoftware requirement Hello, Phil? This is Maria in Human Resources.Were having a problem with the personnel system you programmed forus. An employee just changed her name to Sparkle Starlight, and wecant get the system to accept the name change. Can you help? Shemarried some guy named Starlight? No, she didnt get married, justchanged her name, Maria replied. Thats the problem. It looks likewe can change a name only if someones marital status changes. Well,yeah, I never thought someone might just change her name. I dontremember you telling me about this possibility when we talked aboutthe system, Phil said. I assumed you knew that people could legallychange their name anytime they like, responded Maria. We have tostraighten this out by Friday or Sparkle wont be able to cash herpaycheck. Can you fix the bug by then? Its not a bug! Philretorted. I never knew you needed this capability. Im busy on thenew performance evaluation system. I can probably fix it by the endof the month, but not by Friday. Sorry about that. Next time, tellme these things earlier and please write them down. What am Isupposed to tell Sparkle? demanded Maria. Shell be upset if shecant cash her check. Hey, Maria, its not my fault, Phil protested.If youd told me in the first place that you had to be able tochange someones name at any time, this wouldnt have happened. Youcant blame me for not reading your mind. Angry and resigned, Mariasnapped, Yeah, well, this is the kind of thing that makes me hatecomputers. Call me as soon as you get it fixed, will you? If youveever been on the customer side of a conversation like this, youknow how frustrating it is when a software system doesnt let youperform an essential task. You hate to be at the mercy of adeveloper who might get to your critical change request eventually.On the other hand, developers are frustrated to learn aboutfunctionality that a user expected only after theyve implementedthe system. Its also annoying for a developer to have his currentproject interrupted by a request to modify a system that doesprecisely what he was told it should do in the first place. 33. 4PART I Software requirements: What, why, and who Many problems inthe software world arise from shortcomings in the ways that peoplelearn about, document, agree upon and modify the productsrequirements. As with Phil and Maria, common problem areas areinformal information gathering, implied functionality,miscommunicated assumptions, poorly specified requirements, and acasual change process. Various studies suggest that errorsintroduced during requirements activities account for 40 to 50percent of all defects found in a software product (Davis 2005).Inadequate user input and shortcomings in specifying and managingcustomer requirements are major contributors to unsuccessfulprojects. Despite this evidence, many organizations still practiceineffective requirements methods. Nowhere more than in therequirements do the interests of all the stakeholders in a projectintersect. (See Chapter 2, Requirements from the customersperspective, for more about stakeholders.) These stakeholdersinclude customers, users, business analysts, developers, and manyothers. Handled well, this intersection can lead to delightedcustomers and fulfilled developers. Handled poorly, its the sourceof misunderstanding and friction that undermine the productsquality and business value. Because requirements are the foundationfor both the software development and the project managementactivities, all stakeholders should commit to applying requirementspractices that are known to yield superior-quality products. Butdeveloping and managing requirements is hard! There are no simpleshortcuts or magic solutions. On the plus side, so manyorganizations struggle with the same problems that you can look fortechniques in common that apply to many different situations. Thisbook describes dozens of such practices. The practices arepresented as though you were building a brand-new system. However,most of them also apply to enhancement, replacement, andreengineering projects (see Chapter 21, Enhancement and replacementprojects) and to projects that incorporate commercial off-the-shelf(COTS) packaged solutions (see Chapter 22, Packaged solutionprojects). Project teams that build products incrementally byfollowing an agile development process also need to understand therequirements that go into each increment (see Chapter 20, Agileprojects). This chapter will help you to: Understand some key termsused in the software requirements domain. Distinguish productrequirements from project requirements. Distinguish requirementsdevelopment from requirements management. Be alert to severalrequirements-related problems that can arise. Important We use theterms system, product, application, and solution interchangeably inthis book to refer to any kind of software or software-containingitem that you build, whether for internal corporate use, forcommercial sale, or on a contract basis. 34. CHAPTER 1 Theessential software requirement 5 Taking your requirements pulse Fora quick check of the current requirements practices in yourorganization, consider how many of the following conditions applyto your most recent project. If more than three or four of theseitems describe your experience, this book is for you: The projectsbusiness objectives, vision, and scope were never clearly defined.Customers were too busy to spend time working with analysts ordevelopers on the requirements. Your team could not interactdirectly with representative users to understand their needs.Customers claimed that all requirements were critical, so theydidnt prioritize them. Developers encountered ambiguities andmissing information when coding, so they had to guess.Communications between developers and stakeholders focused on userinterface displays or features, not on what users needed toaccomplish with the software. Your customers never approved therequirements. Your customers approved the requirements for arelease or iteration and then changed them continually. The projectscope increased as requirements changes were accepted, but theschedule slipped because no additional resources were provided andno functionality was removed. Requested requirements changes gotlost; no one knew the status of a particular change request.Customers requested certain functionality and developers built it,but no one ever uses it. At the end of the project, thespecification was satisfied but the customer or the businessobjectives were not. Software requirements defined When a group ofpeople begin discussing requirements, they often start with aterminology problem. Different observers might describe a singlestatement as being a user requirement, software requirement,business requirement, functional requirement, system requirement,product requirement, project requirement, user story, feature, orconstraint. The names they use for various requirementsdeliverables also vary. A customers definition of requirementsmight sound like a high-level product concept to the developer. Thedevelopers notion of requirements might sound like a detailed userinterface design to the user. This diversity of understanding leadsto confusion and frustration. 35. 6 PART I Software requirements:What, why, and who Some interpretations of requirement Many decadesafter the invention of computer programming, software practitionersstill have raging debates about exactly what a requirement is.Rather than prolong those debates, in this book we simply presentsome definitions that we have found useful. Consultant BrianLawrence suggests that a requirement is anything that drives designchoices (Lawrence 1997). This is not a bad colloquial definition,because many kinds of information fit in this category. And, afterall, the whole point of developing requirements is to makeappropriate design choices that will meet the customers needs inthe end. Another definition is that a requirement is a propertythat a product must have to provide value to a stakeholder. Alsonot bad, but not very precise. Our favorite definition, though,comes from Ian Sommerville and Pete Sawyer (1997): Requirements area specification of what should be implemented. They aredescriptions of how the system should behave, or of a systemproperty or attribute. They may be a constraint on the developmentprocess of the system. This definition acknowledges the diversetypes of information that collectively are referred to as therequirements. Requirements encompass both the users view of theexternal system behavior and the developers view of some internalcharacteristics. They include both the behavior of the system underspecific conditions and those properties that make the systemsuitableand maybe even enjoyablefor use by its intended operators.Trap Dont assume that all your project stakeholders share a commonnotion of what requirements are. Establish definitions up front sothat youre all talking about the same things. The pure dictionaryrequirement Software people do not use requirement in the samesense as a dictionary definition of the word: something demanded orobligatory, a need or necessity. People sometimes question whetherthey even need to prioritize requirements, because maybe alow-priority requirement wont ever be implemented. If it isnt trulyneeded, then it isnt a requirement, they claim. Perhaps, but thenwhat would you call that piece of information? If you defer arequirement from todays project to an unspecified future release,is it still considered a requirement? Sure it is. Softwarerequirements include a time dimension. They could be present tense,describing the current systems capabilities. Or they could be forthe near-term (high priority), mid-term (medium priority), orhypothetical (low priority) future. They could even be past tense,referring to needs that were once specified and then discarded.Dont waste time debating whether or not something is a requirement,even if you know you might never implement it for some goodbusiness reason. It is. 36. CHAPTER 1 The essential softwarerequirement 7 Levels and types of requirements Because there are somany different types of requirements information, we need aconsistent set of adjectives to modify the overloaded termrequirement. This section presents definitions we will use for someterms commonly encountered in the requirements domain (see Table1-1). TABLE 1-1 Some types of requirements information TermDefinition Business requirement A high-level business objective ofthe organization that builds a product or of a customer whoprocures it. Business rule A policy, guideline, standard, orregulation that defines or constrains some aspect of the business.Not a software requirement in itself, but the origin of severaltypes of software requirements. Constraint A restriction that isimposed on the choices available to the developer for the designand construction of a product. External interface requirement Adescription of a connection between a software system and a user,another software system, or a hardware device. Feature One or morelogically related system capabilities that provide value to a userand are described by a set of functional requirements. Functionalrequirement A description of a behavior that a system will exhibitunder specific conditions. Nonfunctional requirement A descriptionof a property or characteristic that a system must exhibit or aconstraint that it must respect. Quality attribute A kind ofnonfunctional requirement that describes a service or performancecharacteristic of a product. System requirement A top-levelrequirement for a product that contains multiple subsystems, whichcould be all software or software and hardware. User requirement Agoal or task that specific classes of users must be able to performwith a system, or a desired product attribute. Softwarerequirements include three distinct levels: business requirements,user requirements, and functional requirements. In addition, everysystem has an assortment of nonfunctional requirements. The modelin Figure 1-1 illustrates a way to think about these diverse typesof requirements. As statistician George E. P. Box famously said,Essentially, all models are wrong, but some are useful (Box andDraper 1987). Thats certainly true of Figure 1-1. This model is notall-inclusive, but it does provide a helpful scheme for organizingthe requirements knowledge youll encounter. The ovals in Figure 1-1represent types of requirements information, and the rectanglesindicate documents in which to store that information. The solidarrows indicate that a certain type of information typically isstored in the indicated document. (Business rules and systemrequirements are stored separately from software requirements, suchas in a business rules catalog or a system requirementsspecification, respectively.) The dotted arrows indicate that onetype of information is the origin of or influences another type ofrequirement. Data requirements are not shown explicitly in thisdiagram. Functions manipulate data, so data requirements can appearthroughout the three levels. Chapter 7, Requirements elicitation,contains many examples of these different types of requirementsinformation. 37. 8 PART I Software requirements: What, why, and whoFIGURE 1-1 Relationships among several types of requirementsinformation. Solid arrows mean are stored in; dotted arrows meanare the origin of or influence. Important Although we will refer torequirements documents throughout this book, as in Figure 1-1,those do not have to be traditional paper or electronic documents.Instead, think of them simply as containers in which to storerequirements knowledge. Such a container could indeed be atraditional document, or it could be a spreadsheet, a set ofdiagrams, a database, a requirements management tool, or somecombination of these. For convenience, we will use the termdocument to refer to any such container. We will provide templatesthat identify the types of information to consider storing in eachsuch grouping, regardless of what form you store it in. What youcall each deliverable is less important than having yourorganization agree on their names, what kinds of information gointo each, and how that information is organized. Businessrequirements describe why the organization is implementing thesystemthe business benefits the organization hopes to achieve. Thefocus is on the business objectives of the organization or thecustomer who requests the system. Suppose an airline wants toreduce airport counter staff costs by 25 percent. This goal mightlead to the idea of building a kiosk that passengers can use tocheck in for their flights at the airport. Business requirementstypically come from the funding sponsor for a project, theacquiring customer, the manager of the actual users, the marketingdepartment, or a product visionary. We like to record the businessrequirements in a vision and scope document. Other strategicguiding documents sometimes used for this purpose include a projectcharter, business case, and market (or marketing) requirementsdocument. Specifying business requirements is the subject ofChapter 5, Establishing the business requirements. For the purposesof this book, we are assuming that the business need or marketopportunity has already been identified. 38. CHAPTER 1 Theessential software requirement 9 User requirements describe goalsor tasks the users must be able to perform with the product thatwill provide value to someone. The domain of user requirements alsoincludes descriptions of product attributes or characteristics thatare important to user satisfaction. Ways to represent userrequirements include use cases (Kulak and Guiney 2004), userstories (Cohn 2004), and event-response tables. Ideally, actualuser representatives will provide this information. Userrequirements describe what the user will be able to do with thesystem. An example of a use case is Check in for a flight using anairlines website or a kiosk at the airport. Written as a userstory, the same user requirement might read: As a passenger, I wantto check in for a flight so I can board my airplane. Its importantto remember that most projects have multiple user classes, as wellas other stakeholders whose needs also must be elicited. Chapter 8,Understanding user requirements, addresses this level of the model.Some people use the broader term stakeholder requirements, toacknowledge the reality that various stakeholders other than directusers will provide requirements. That is certainly true, but wefocus the attention at this level on understanding what actualusers need to achieve with the help of the product. Functionalrequirements specify the behaviors the product will exhibit underspecific conditions. They describe what the developers mustimplement to enable users to accomplish their tasks (userrequirements), thereby satisfying the business requirements. Thisalignment among the three levels of requirements is essential forproject success. Functional requirements often are written in theform of the traditional shall statements: The Passenger shall beable to print boarding passes for all flight segments for which hehas checked in or If the Passengers profile does not indicate aseating preference, the reservation system shall assign a seat. Thebusiness analyst (BA)1 documents functional requirements in asoftware requirements specification (SRS), which describes as fullyas necessary the expected behavior of the software system. The SRSis used in development, testing, quality assurance, projectmanagement, and related project functions. People call thisdeliverable by many different names, including businessrequirements document, functional spec, requirements document, andothers. An SRS could be a report generated from information storedin a requirements management tool. Because it is anindustry-standard term, we will use SRS consistently throughoutthis book (ISO/IEC/IEEE 2011). See Chapter 10, Documenting therequirements, for more information about the SRS. Systemrequirements describe the requirements for a product that iscomposed of multiple components or subsystems (ISO/IEC/IEEE 2011).A system in this sense is not just any information system. A systemcan be all software or it can include both software and hardwaresubsystems. People and processes are part of a system, too, socertain system functions might be allocated to human beings. Somepeople use the term system requirements to mean the detailedrequirements for a software system, but thats not how we use theterm in this book. A good example of a system is the cashiersworkstation in a supermarket. Theres a bar code scanner integratedwith a scale, as well as a hand-held bar code scanner. The cashierhas a keyboard, a display, and a cash drawer. Youll see a cardreader and PIN pad for your loyalty card and credit or debit card,and perhaps a change dispenser. You might see up to three printersfor your purchase 1 Business analyst refers to the project rolethat has primary responsibility for leading requirements-relatedactivities on a project. The BA role also goes by many other names.See Chapter 4, The business analyst, for more about the businessanalyst role. 39. 10 PART I Software requirements: What, why, andwho receipt, credit card receipt, and coupons you dont care about.These hardware devices are all interacting under software control.The requirements for the system or product as a whole, then, leadthe business analyst to derive specific functionality that must beallocated to one or another of those component subsystems, as wellas demanding an understanding of the interfaces between them.Business rules include corporate policies, government regulations,industry standards, and computational algorithms. As youll see inChapter 9, Playing by the rules, business rules are not themselvessoftware requirements because they have an existence beyond theboundaries of any specific software application. However, theyoften dictate that the system must contain functionality to complywith the pertinent rules. Sometimes, as with corporate securitypolicies, business rules are the origin of specific qualityattributes that are then implemented in functionality. Therefore,you can trace the genesis of certain functional requirements backto a particular business rule. In addition to functionalrequirements, the SRS contains an assortment of nonfunctionalrequirements. Quality attributes are also known as quality factors,quality of service requirements, constraints, and the ilities. Theydescribe the products characteristics in various dimensions thatare important either to users or to developers and maintainers,such as performance, safety, availability, and portability. Otherclasses of nonfunctional requirements describe external interfacesbetween the system and the outside world. These include connectionsto other software systems, hardware components, and users, as wellas communication interfaces. Design and implementation constraintsimpose restrictions on the options available to the developerduring construction of the product. If theyre nonfunctional, thenwhat are they? For many years, the requirements for a softwareproduct have been classified broadly as either functional ornonfunctional. The functional requirements are evident: theydescribe the observable behavior of the system under variousconditions. However, many people dislike the term nonfunctional.That adjective says what the requirements are not, but it doesntsay what they are. We are sympathetic to the problem, but we lack aperfect solution. Other-than-functional requirements might specifynot what the system does, but rather how well it does those things.They could describe important characteristics or properties of thesystem. These include the systems availability, usability,security, performance, and many other characteristics, as addressedin Chapter 14, Beyond functionality. Some people considernonfunctional requirements to be synonymous with qualityattributes, but that is overly restrictive. For example, design andimplementation constraints are also nonfunctional requirements, asare external interface requirements. Still other nonfunctionalrequirements address the environment in which the system operates,such as platform, portability, compatibility, and constraints. Manyproducts are also affected by compliance, 2ff7e9595c
Comments