Have you ever delivered software that satisfied all of the project specifications, but failed to meet any of the customers' expectations? Without formal, verifiable requirements--and a system for managing them--the result is often a gap between what developers think they're supposed to build and what customers think they're going to get. Too often, lessons about software requirements engineering processes are formal or academic, and not of value to real-world, professional development teams. In MORE ABOUT SOFTWARE REQUIREMENTS: THORNY ISSUES AND PRACTICAL ADVICE, the author of Software Requirements, Second Edition, describes even more practical techniques for gathering and managing the software requirements that help you meet project specifications and customer expectations. A leading speaker and consultant in the field of requirements engineering, Karl Wiegers takes questions raised by other professional software developers and analysts as a basis for the practical solutions and best practices offered in this guide. Succinct and immediately useful, this book is a must-have for developers and analysts.
Table of Contents
- More About Software Requirements: Thorny Issues and Practical Advice
- Praise for More About Software Requirements: Thorny Issues and Practical Advice
I. On Essential Requirements Concepts
- 1. Requirements Engineering Overview
2. Cosmic Truths About Software Requirements
- Requirements Realities
- Requirements Stakeholders
- Cosmic Truth #7: The first question an analyst should ask about a proposed new requirement is, "Is this requirement in scope?"
- Cosmic Truth #8: Even the best requirements document cannot—and should not—replace human dialogue
- Cosmic Truth #9: The requirements might be vague, but the product will be specific
- Cosmic Truth #10: You’re never going to have perfect requirements
II. On the Management View of Requirements
- 3. The Business Value of Better Requirements
- 4. How Long Do Requirements Take?
5. Estimating Based on Requirements
- Some Estimation Fundamentals
- Estimation Approaches
- Goals Aren’t Estimates
- Estimating from Requirements
- Measuring Software Size
- Story Points
- Use Case Points
- Testable Requirements
- The Reality of Estimation
III. On Customer Interactions
- 6. The Myth of the On-Site Customer
7. An Inquiry, Not an Inquisition
- But First, Some Questions to Avoid
Questions for Eliciting Business Requirements
- What business problem are you trying to solve?
- What’s the motivation for solving this problem?
- What would a highly successful solution do for you?
- How can we judge the success of the solution?
- What’s a successful solution worth?
- Who are the individuals or groups that could influence this project or be influenced by it?
- Are there any related projects or systems that could influence this one or that this project could affect?
- Which business activities and events should be included in the solution? Which should not?
- Can you think of any unexpected or adverse consequences that the new system could cause?
- User Requirements and Use Cases
Questions for Eliciting User Requirements
- What are some reasons why you or your colleagues would use the new product?
- What goals might you have in mind that this product could help you accomplish?
- What problems do you expect this product to solve for you?
- What external events are associated with the product?
- What words would you use to describe the product?
- Are specific portions of the product more critical than others for performance, reliability, security, safety, availability, or other characteristics?
- Are there any constraints or rules to which the product must conform?
- How is the product you envision similar to the way you do business now? How should it be different?
- What aspects of the current product or business process do you want to retain? To replace?
- Which aspects of the product are most critical to creating business value?
- What aspect of the product most excites you?
- What aspect of the product will be most valuable to you? Least valuable?
- What is most important to you about the product?
- How would you judge whether the product is a success?
- Can you describe the environment in which the product will be used?
- Open-Ended Questions
- Why Ask Why?
8. Two Eyes Aren’t Enough
Improving Your Requirements Reviews
- Educate the reviewers
- Don’t overwhelm the reviewers
- Build a collaborative partnership with the user representatives and other project participants
- Invite the right reviewers
- Have reviewers examine appropriate deliverables
- Design for reviewability
- Inspect all requirements deliverables
- Emphasize finding major errors
- Improving Your Requirements Reviews
IV. On Use Cases
- 9. Use Cases and Scenarios and Stories, Oh My!
- 10. Actors and Users
- 11. When Use Cases Aren’t Enough
V. On Writing Requirements
- 12. Bridging Documents
13. How Much Detail Do You Need?
- Who Makes the Call?
- When More Detail Is Needed
- When Less Detail Is Appropriate
- Implied Requirements
- Sample Levels of Requirements Detail
- 14. To Duplicate or Not to Duplicate
15. Elements of Requirements Style
- I Shall Call This a Requirement
- System Perspective or User Perspective?
- Parent and Child Requirements
- What Was That Again?
- 16. The Fuzzy Line Between Requirements and Design
VI. On the Requirements Process
- 17. Defining Project Scope
- 18. The Line in the Sand
19. The Six Blind Men and the Requirements
- Limitations of Natural Language
- Some Alternative Requirements Views
- Why Create Multiple Views?
- Selecting Appropriate Views
- Reconciling Multiple Views
VII. On Managing Requirements
- 20. Handling Requirements for Multiple Releases
- 21. Business Requirements and Business Rules
- 22. Measuring Requirements
- 23. Exploiting Requirements Management Tools
- About the Author
- About the Author
- Title: More About Software Requirements: Thorny Issues and Practical Advice
- Release date: November 2010
- Publisher(s): Microsoft Press
- ISBN: 0735622671