Software Requirements 3 Karl Wiegers Pdf
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.
Software Requirements 3 Karl Wiegers Pdf
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
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. . . . . . . . . .