Book description
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
- Preface
- Acknowledgments
-
I. On Essential Requirements Concepts
- 1. Requirements Engineering Overview
-
2. Cosmic Truths About Software Requirements
- Requirements Realities
- Requirements Stakeholders
-
Requirements Specifications
- 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
-
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
-
V. On Writing Requirements
- 12. Bridging Documents
- 13. How Much Detail Do You Need?
- 14. To Duplicate or Not to Duplicate
- 15. Elements of Requirements Style
- 16. The Fuzzy Line Between Requirements and Design
- VI. On the Requirements Process
- VII. On Managing Requirements
- References
- About the Author
- Index
- About the Author
- Copyright
Product information
- Title: More About Software Requirements: Thorny Issues and Practical Advice
- Author(s):
- Release date: November 2010
- Publisher(s): Microsoft Press
- ISBN: 9780735622678
You might also like
book
Just Enough Requirements Management: Where Software Development Meets Marketing
This is the digital version of the printed book (Copyright © 2005). If you develop software …
book
The Incremental Commitment Spiral Model: Principles and Practices for Successful Systems and Software
“The title makes a huge promise: a way to divide commitment into increments that are both …
book
Lean Software Systems Engineering for Developers: Managing Requirements, Complexity, Teams, and Change Like a Champ
Graduate to the next level of your software development career, learning the tools you need to …
book
Software Requirements Using the Unified Process: A Practical Approach
Effective requirements development: An end-to-end process that works. How to build requirements that can easily be …