More About Software Requirements: Thorny Issues and Practical Advice

More About Software Requirements: Thorny Issues and Practical Advice

by Karl E Wiegers
Released November 2010
Publisher(s): Microsoft Press
ISBN: 9780735622678

Read it now on the O’Reilly learning platform with a 10-day free trial.

O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

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

  1. More About Software Requirements: Thorny Issues and Practical Advice
  2. Praise for More About Software Requirements: Thorny Issues and Practical Advice
  3. Preface
  4. Acknowledgments
  5. I. On Essential Requirements Concepts
    1. 1. Requirements Engineering Overview
      1. "Requirement" Defined
      2. Different Types of Requirements
        1. Business Requirements
        2. User Requirements
        3. Functional Requirements
        4. System Requirements
        5. Business Rules
        6. Quality Attributes
        7. External Interfaces
        8. Constraints
      3. Requirements Engineering Activities
      4. Looking Ahead
    2. 2. Cosmic Truths About Software Requirements
      1. Requirements Realities
        1. Cosmic Truth #1: If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project
        2. Cosmic Truth #2: Requirements development is a discovery and invention process, not just a collection process
        3. Cosmic Truth #3: Change happens
      2. Requirements Stakeholders
        1. Cosmic Truth #4: The interests of all the project stakeholders intersect in the requirements process
        2. Cosmic Truth #5: Customer involvement is the most critical contributor to software quality
        3. Cosmic Truth #6: The customer is not always right, but the customer always has a point
      3. Requirements Specifications
        1. Cosmic Truth #7: The first question an analyst should ask about a proposed new requirement is, "Is this requirement in scope?"
        2. Cosmic Truth #8: Even the best requirements document cannot—and should not—replace human dialogue
        3. Cosmic Truth #9: The requirements might be vague, but the product will be specific
        4. Cosmic Truth #10: You’re never going to have perfect requirements
  6. II. On the Management View of Requirements
    1. 3. The Business Value of Better Requirements
      1. Tell Me Where It Hurts
      2. What Can Better Requirements Do for You?
        1. Selecting projects to fund
        2. Facilitating estimation
        3. Enabling prioritization
        4. Developing designs
        5. Testing effectively
      3. The Investment
      4. The Return
      5. An Economic Argument
    2. 4. How Long Do Requirements Take?
      1. Industry Benchmarks
      2. Your Own Experience
      3. Incremental Approaches
      4. Planning Elicitation
    3. 5. Estimating Based on Requirements
      1. Some Estimation Fundamentals
      2. Estimation Approaches
        1. Bottom-up
        2. Top-down
        3. Cost models
        4. Expert opinion
        5. Analogy
        6. Wideband Delphi
      3. Goals Aren’t Estimates
      4. Estimating from Requirements
      5. Measuring Software Size
        1. Lines of code
        2. Function points
        3. 3D function points
        4. Story points
        5. Use case points
        6. Counts of testable requirements
      6. Story Points
      7. Use Case Points
        1. Actor Weights
        2. Use Case Weights
        3. Technical and Environmental Factors
        4. Determining Your Productivity
        5. Problems with Use Case Points
      8. Testable Requirements
      9. The Reality of Estimation
  7. III. On Customer Interactions
    1. 6. The Myth of the On-Site Customer
      1. User Classes and Product Champions
      2. Surrogate Users
      3. Now Hear This
    2. 7. An Inquiry, Not an Inquisition
      1. But First, Some Questions to Avoid
      2. Questions for Eliciting Business Requirements
        1. What business problem are you trying to solve?
        2. What’s the motivation for solving this problem?
        3. What would a highly successful solution do for you?
        4. How can we judge the success of the solution?
        5. What’s a successful solution worth?
        6. Who are the individuals or groups that could influence this project or be influenced by it?
        7. Are there any related projects or systems that could influence this one or that this project could affect?
        8. Which business activities and events should be included in the solution? Which should not?
        9. Can you think of any unexpected or adverse consequences that the new system could cause?
      3. User Requirements and Use Cases
      4. Questions for Eliciting User Requirements
        1. What are some reasons why you or your colleagues would use the new product?
        2. What goals might you have in mind that this product could help you accomplish?
        3. What problems do you expect this product to solve for you?
        4. What external events are associated with the product?
        5. What words would you use to describe the product?
        6. Are specific portions of the product more critical than others for performance, reliability, security, safety, availability, or other characteristics?
        7. Are there any constraints or rules to which the product must conform?
        8. How is the product you envision similar to the way you do business now? How should it be different?
        9. What aspects of the current product or business process do you want to retain? To replace?
        10. Which aspects of the product are most critical to creating business value?
        11. What aspect of the product most excites you?
        12. What aspect of the product will be most valuable to you? Least valuable?
        13. What is most important to you about the product?
        14. How would you judge whether the product is a success?
        15. Can you describe the environment in which the product will be used?
      5. Open-Ended Questions
      6. Why Ask Why?
    3. 8. Two Eyes Aren’t Enough
      1. Improving Your Requirements Reviews
        1. Educate the reviewers
        2. Don’t overwhelm the reviewers
        3. Build a collaborative partnership with the user representatives and other project participants
        4. Invite the right reviewers
        5. Have reviewers examine appropriate deliverables
        6. Design for reviewability
        7. Inspect all requirements deliverables
        8. Emphasize finding major errors
  8. IV. On Use Cases
    1. 9. Use Cases and Scenarios and Stories, Oh My!
      1. Use Cases
      2. Scenarios
      3. User Stories
    2. 10. Actors and Users
    3. 11. When Use Cases Aren’t Enough
      1. The Power of Use Cases
      2. Project Type Limitations
      3. Event-Response Tables
      4. Use Cases Don’t Replace Functional Requirements
      5. Use Cases Reveal Functional Requirements
        1. Preconditions
        2. Postconditions
        3. Normal and Alternative Flows
        4. Exceptions
        5. Business Rules
        6. Special Requirements and Assumptions
  9. V. On Writing Requirements
    1. 12. Bridging Documents
    2. 13. How Much Detail Do You Need?
      1. Who Makes the Call?
      2. When More Detail Is Needed
        1. Development will be outsourced
        2. Project team members are geographically dispersed
        3. Testing will be based on requirements
        4. Accurate estimates are needed
        5. Requirements traceability is needed
      3. When Less Detail Is Appropriate
        1. Customers are extensively involved
        2. Developers have considerable domain experience
        3. Precedents are available
        4. A package solution will be used
      4. Implied Requirements
      5. Sample Levels of Requirements Detail
    3. 14. To Duplicate or Not to Duplicate
      1. Cross-Referencing
      2. Hyperlinks
      3. Traceability Links
      4. Recommendation
    4. 15. Elements of Requirements Style
      1. I Shall Call This a Requirement
      2. System Perspective or User Perspective?
      3. Parent and Child Requirements
      4. What Was That Again?
        1. Complex Logic
        2. Negative Requirements
        3. Omissions
        4. Boundaries
        5. Avoiding Ambiguous Wording
        6. Synonyms
        7. Near-synonyms
        8. Pronouns
        9. The abbreviations i.e. and e.g
        10. A/B
        11. Similar-sounding words
        12. Adverbs
    5. 16. The Fuzzy Line Between Requirements and Design
      1. Solution Ideas and Design Constraints
      2. Solution Clues
  10. VI. On the Requirements Process
    1. 17. Defining Project Scope
      1. Vision and Scope
      2. Context Diagram
      3. Use Case Diagram
      4. Feature Levels
      5. Managing Scope Creep
    2. 18. The Line in the Sand
      1. The Requirements Baseline
      2. When to Baseline
    3. 19. The Six Blind Men and the Requirements
      1. Limitations of Natural Language
      2. Some Alternative Requirements Views
        1. Graphical Analysis Models
        2. Decision Tables and Decision Trees
        3. Test Cases
        4. Prototypes and Screen Designs
        5. Tables and Structured Lists
        6. Mathematical Expressions
      3. Why Create Multiple Views?
      4. Selecting Appropriate Views
      5. Reconciling Multiple Views
  11. VII. On Managing Requirements
    1. 20. Handling Requirements for Multiple Releases
      1. Single Requirements Specification
      2. Multiple Requirements Specifications
      3. Requirements Management Tools
    2. 21. Business Requirements and Business Rules
      1. Business Requirements
      2. Business Rules
      3. Business Rules and Software Requirements
    3. 22. Measuring Requirements
      1. Product Size
      2. Requirements Quality
      3. Requirements Status
      4. Requests for Changes
      5. Effort
    4. 23. Exploiting Requirements Management Tools
      1. Write Good Requirements First
      2. Expect a Culture Change
      3. Choose a Database-Centric or Document-Centric Tool
      4. Don’t Create Too Many Requirement Types or Attributes
      5. Train the Tool Users
      6. Assign Responsibilities
      7. Take Advantage of Tool Features
  12. References
  13. About the Author
  14. Index
  15. About the Author
  16. Copyright

Product information

  • Title: More About Software Requirements: Thorny Issues and Practical Advice
  • Author(s): Karl E Wiegers
  • Release date: November 2010
  • Publisher(s): Microsoft Press
  • ISBN: 9780735622678