Synopses & Reviews
No matter how much instruction you’ve had on managing software requirements, there’s no substitute for experience. Too often, lessons about requirements engineering processes lack the no-nonsense guidance that supports real-world solutions. Complementing the best practices presented in his book, Software Requirements, Second Edition, requirements engineering authority Karl Wiegers tackles even more of the real issues head-on in this book. With straightforward, professional advice and practical solutions based on actual project experiences, this book answers many of the tough questions raised by industry professionals. From strategies for estimating and working with customers to the nuts and bolts of documenting requirements, this essential companion gives developers, analysts, and managers the cosmic truths that apply to virtually every software development project. Discover how to: • Make the business case for investing in better requirements practices • Generate estimates using three specific techniques • Conduct inquiries to elicit meaningful business and user requirements • Clearly document project scope • Implement use cases, scenarios, and user stories effectively • Improve inspections and peer reviews • Write requirements that avoid ambiguity
About the Author
Karl E. Wiegers is a leading speaker, author, and consultant on requirements engineering, project management, and process improvement. As Principal Consultant with Process Impact, he conducts training seminars for corporate and government clients worldwide. Karl has twice won the Software Development Productivity Award, which honors excellence in productivity-enhancing products and books.
Table of Contents
Praise for More About Software Requirements: Thorny Issues and Practical AdvicePrefaceAcknowledgmentsPart I: On Essential Requirements ConceptsChapter 1: Requirements Engineering OverviewChapter 2: Cosmic Truths About Software RequirementsPart II: On the Management View of RequirementsChapter 3: The Business Value of Better RequirementsChapter 4: How Long Do Requirements Take?Chapter 5: Estimating Based on RequirementsPart III: On Customer InteractionsChapter 6: The Myth of the On-Site CustomerChapter 7: An Inquiry, Not an InquisitionChapter 8: Two Eyes Arent EnoughPart IV: On Use CasesChapter 9: Use Cases and Scenarios and Stories, Oh My!Chapter 10: Actors and UsersChapter 11: When Use Cases Arent EnoughPart V: On Writing RequirementsChapter 12: Bridging DocumentsChapter 13: How Much Detail Do You Need?Chapter 14: To Duplicate or Not to DuplicateChapter 15: Elements of Requirements StyleChapter 16: The Fuzzy Line Between Requirements and DesignPart VI: On the Requirements ProcessChapter 17: Defining Project ScopeChapter 18: The Line in the SandChapter 19: The Six Blind Men and the RequirementsPart VII: On Managing RequirementsChapter 20: Handling Requirements for Multiple ReleasesChapter 21: Business Requirements and Business RulesChapter 22: Measuring RequirementsChapter 23: Exploiting Requirements Management ToolsReferencesAppendix : About the Author