You are previewing Software Requirements, Second Edition.
O'Reilly logo
Software Requirements, Second Edition

Book Description

Learn effective, field-tested techniques to manage the requirements engineering process and get expert guidance from a leading requirements engineering authority. This updated edition features sample documents, a troubleshooting guide, and case examples.

Table of Contents

  1. Software Requirements, Second Edition
  2. Preface
    1. Benefits This Book Provides
    2. Who Should Read This Book
    3. Looking Ahead
    4. Case Studies
    5. From Principles to Practice
  3. Acknowledgments
  4. I. Software Requirements: What, Why, and Who
    1. 1. The Essential Software Requirement
      1. Software Requirements Defined
        1. Some Interpretations of Requirement
        2. Levels of Requirements
        3. What Requirements Are Not
      2. Requirements Development and Management
        1. Requirements Development
        2. Requirements Management
      3. Every Project Has Requirements
      4. When Bad Requirements Happen to Nice People
        1. Insufficient User Involvement
        2. Creeping User Requirements
        3. Ambiguous Requirements
        4. Gold Plating
        5. Minimal Specification
        6. Overlooked User Classes
        7. Inaccurate Planning
      5. Benefits from a High-Quality Requirements Process
      6. Characteristics of Excellent Requirements
        1. Requirement Statement Characteristics
          1. Complete
          2. Correct
          3. Feasible
          4. Necessary
          5. Prioritized
          6. Unambiguous
          7. Verifiable
        2. Requirements Specification Characteristics
          1. Complete
          2. Consistent
          3. Modifiable
          4. Traceable
    2. 2. Requirements from the Customer’s Perspective
      1. Who Is the Customer?
      2. The Customer-Development Partnership
        1. Requirements Bill of Rights for Software Customers
          1. Right #1: To Expect Analysts to Speak Your Language
          2. Right #2: To Have Analysts Learn About Your Business and Objectives
          3. Right #3: To Expect Analysts to Write a Software Requirements Specification
          4. Right #4: To Receive Explanations of Requirements Work Products
          5. Right #5: To Expect Analysts and Developers to Treat You with Respect
          6. Right #6: To Hear Ideas and Alternatives for Requirements and Their Implementation
          7. Right #7: To Describe Characteristics That Make the Product Easy to Use
          8. Right #8: To Be Given Opportunities to Adjust Requirements to Permit Reuse
          9. Right #9: To Receive Good-Faith Estimates of the Costs of Changes
          10. Right #10: To Receive a System That Meets Your Functional and Quality Needs
        2. Requirements Bill of Responsibilities for Software Customers
          1. Responsibility #1: To Educate Analysts and Developers About Your Business
          2. Responsibility #2: To Spend the Time to Provide and Clarify Requirements
          3. Responsibility #3: To Be Specific and Precise About Requirements
          4. Responsibility #4: To Make Timely Decisions
          5. Responsibility #5: To Respect a Developer’s Assessment of Cost and Feasibility
          6. Responsibility #6: To Set Requirement Priorities
          7. Responsibility #7: To Review Requirements Documents and Evaluate Prototypes
          8. Responsibility #8: To Promptly Communicate Changes to the Requirements
          9. Responsibility #9: To Follow the Development Organization’s Change Process
          10. Responsibility #10: To Respect the Requirements Engineering Processes the Analysts Use
      3. What About Sign-Off?
    3. 3. Good Practices for Requirements Engineering
      1. Knowledge
      2. Requirements Elicitation
      3. Requirements Analysis
      4. Requirements Specification
      5. Requirements Validation
      6. Requirements Management
      7. Project Management
      8. Getting Started with New Practices
      9. A Requirements Development Process
    4. 4. The Requirements Analyst
      1. The Requirements Analyst Role
        1. The Analyst’s Tasks
        2. Essential Analyst Skills
        3. Essential Analyst Knowledge
      2. The Making of an Analyst
        1. The Former User
        2. The Former Developer
        3. The Subject Matter Expert
      3. Creating a Collaborative Environment
  5. II. Software Requirements Development
    1. 5. Establishing the Product Vision and Project Scope
      1. Defining the Vision Through Business Requirements
        1. Conflicting Business Requirements
        2. Business Requirements and Use Cases
      2. Vision and Scope Document
        1. 1. Business Requirements
          1. 1.1. Background
          2. 1.2. Business Opportunity
          3. 1.3. Business Objectives and Success Criteria
          4. 1.4. Customer or Market Needs
          5. 1.5. Business Risks
        2. 2. Vision of the Solution
          1. 2.1. Vision Statement
          2. 2.2. Major Features
          3. 2.3. Assumptions and Dependencies
        3. 3. Scope and Limitations
          1. 3.1. Scope of Initial Release
          2. 3.2. Scope of Subsequent Releases
          3. 3.3. Limitations and Exclusions
        4. 4. Business Context
          1. 4.1. Stakeholder Profiles
          2. 4.2. Project Priorities
          3. 4.3. Operating Environment
      3. The Context Diagram
      4. Keeping the Scope in Focus
    2. 6. Finding the Voice of the Customer
      1. Sources of Requirements
      2. User Classes
      3. Finding User Representatives
      4. The Product Champion
        1. External Product Champions
        2. Product Champion Expectations
        3. Multiple Product Champions
        4. Selling the Product Champion Idea
        5. Product Champion Traps to Avoid
      5. Who Makes the Decisions?
    3. 7. Hearing the Voice of the Customer
      1. Requirements Elicitation
      2. Elicitation Workshops
      3. Classifying Customer Input
      4. Some Cautions About Elicitation
      5. Finding Missing Requirements
      6. How Do You Know When You’re Done?
    4. 8. Understanding User Requirements
      1. The Use-Case Approach
        1. Use Cases and Usage Scenarios
        2. Identifying Use Cases
        3. Documenting Use Cases
        4. Use Cases and Functional Requirements
          1. Use Cases Only
          2. Use Cases and SRS
          3. SRS Only
        5. Benefits of Use Cases
        6. Use-Case Traps to Avoid
      2. Event-Response Tables
    5. 9. Playing by the Rules
      1. The Rules of the Business
        1. Facts
        2. Constraints
        3. Action Enablers
        4. Inferences
        5. Computations
      2. Documenting Business Rules
      3. Business Rules and Requirements
    6. 10. Documenting the Requirements
      1. The Software Requirements Specification
        1. Labeling Requirements
          1. Sequence Number
          2. Hierarchical Numbering
          3. Hierarchical Textual Tags
        2. Dealing with Incompleteness
        3. User Interfaces and the SRS
      2. A Software Requirements Specification Template
        1. 1. Introduction
          1. 1.1. Purpose
          2. 1.2. Document Conventions
          3. 1.3. Intended Audience and Reading Suggestions
          4. 1.4. Project Scope
          5. 1.5. References
        2. 2. Overall Description
          1. 2.1. Product Perspective
          2. 2.2. Product Features
          3. 2.3. User Classes and Characteristics
          4. 2.4. Operating Environment
          5. 2.5. Design and Implementation Constraints
          6. 2.6. User Documentation
          7. 2.7. Assumptions and Dependencies
        3. 3. System Features
          1. 3.x. System Feature X
          2. 3.x.1. Description and Priority
          3. 3.x.2. Stimulus/Response Sequences
          4. 3.x.3. Functional Requirements
        4. 4. External Interface Requirements
          1. 4.1. User Interfaces
          2. 4.2. Hardware Interfaces
          3. 4.3. Software Interfaces
          4. 4.4. Communications Interfaces
        5. 5. Other Nonfunctional Requirements
          1. 5.1. Performance Requirements
          2. 5.2. Safety Requirements
          3. 5.3. Security Requirements
          4. 5.4. Software Quality Attributes
        6. 6. Other Requirements
        7. Appendix A: Glossary
        8. Appendix B: Analysis Models
        9. Appendix C: Issues List
      3. Guidelines for Writing Requirements
      4. Sample Requirements, Before and After
      5. The Data Dictionary
    7. 11. A Picture Is Worth 1024 Words
      1. Modeling the Requirements
      2. From Voice of the Customer to Analysis Models
      3. Data Flow Diagram
      4. Entity-Relationship Diagram
      5. State-Transition Diagram
      6. Dialog Map
      7. Class Diagrams
      8. Decision Tables and Decision Trees
      9. A Final Reminder
    8. 12. Beyond Functionality: Software Quality Attributes
      1. Quality Attributes
      2. Defining Quality Attributes
        1. Attributes Important to Users
        2. Attributes Important to Developers
      3. Performance Requirements
      4. Defining Nonfunctional Requirements By Using Planguage
      5. Attribute Trade-Offs
      6. Implementing Nonfunctional Requirements
    9. 13. Risk Reduction Through Prototyping
      1. Prototyping: What and Why
      2. Horizontal Prototypes
      3. Vertical Prototypes
      4. Throwaway Prototypes
      5. Evolutionary Prototypes
      6. Paper and Electronic Prototypes
      7. Prototype Evaluation
      8. The Risks of Prototyping
      9. Prototyping Success Factors
    10. 14. Setting Requirement Priorities
      1. Why Prioritize Requirements?
      2. Games People Play with Priorities
      3. A Prioritization Scale
      4. Prioritization Based on Value, Cost, and Risk
    11. 15. Validating the Requirements
      1. Reviewing Requirements
        1. The Inspection Process
          1. Participants
          2. Inspection Roles
          3. Entry Criteria
          4. Inspection Stages
          5. Exit Criteria
          6. Defect Checklists
        2. Requirements Review Challenges
      2. Testing the Requirements
      3. Defining Acceptance Criteria
    12. 16. Special Requirements Development Challenges
      1. Requirements for Maintenance Projects
        1. Begin Capturing Information
        2. Practice New Requirements Techniques
        3. Follow the Traceability Chain
        4. Update the Documentation
      2. Requirements for Package Solutions
        1. Develop Use Cases
        2. Consider Business Rules
        3. Define Quality Requirements
      3. Requirements for Outsourced Projects
      4. Requirements for Emergent Projects
        1. Casual User Requirements Specification
        2. On-Site Customer
        3. Early and Frequent Prioritization
        4. Simple Change Management
    13. 17. Beyond Requirements Development
      1. From Requirements to Project Plans
        1. Requirements and Estimation
        2. Requirements and Scheduling
      2. From Requirements to Designs and Code
      3. From Requirements to Tests
      4. From Requirements to Success
  6. III. Software Requirements Management
    1. 18. Requirements Management Principles and Practices
      1. The Requirements Baseline
      2. Requirements Management Procedures
      3. Requirements Version Control
      4. Requirement Attributes
      5. Tracking Requirements Status
      6. Measuring Requirements Management Effort
    2. 19. Change Happens
      1. Managing Scope Creep
      2. The Change-Control Process
        1. Change-Control Policy
        2. Change-Control Process Description
          1. 1. Introduction
          2. 2. Roles and Responsibilities
          3. 3. Change-Request Status
          4. 4. Entry Criteria
          5. 5. Tasks
          6. 6. Verification
          7. 7. Exit Criteria
          8. 8. Change-Control Status Reporting
          9. Appendix: Data Items Stored for Each Request
      3. The Change Control Board
        1. CCB Composition
        2. CCB Charter
          1. Making Decisions
          2. Communicating Status
          3. Renegotiating Commitments
      4. Change-Control Tools
      5. Measuring Change Activity
      6. Change Isn’t Free: Impact Analysis
        1. Impact Analysis Procedure
        2. Impact Analysis Report Template
    3. 20. Links in the Requirements Chain
      1. Tracing Requirements
      2. Motivations for Tracing Requirements
      3. The Requirements Traceability Matrix
      4. Tools for Requirements Tracing
      5. Requirements Traceability Procedure
      6. Is Requirements Traceability Feasible? Is It Necessary?
    4. 21. Tools for Requirements Management
      1. Benefits of Using a Requirements Management Tool
      2. Requirements Management Tool Capabilities
      3. Implementing Requirements Management Automation
        1. Selecting a Tool
        2. Changing the Culture
        3. Making Requirements Management Tools Work for You
  7. IV. Implementing Requirements Engineering
    1. 22. Improving Your Requirements Processes
      1. How Requirements Relate to Other Project Processes
      2. Requirements and Various Stakeholder Groups
      3. Fundamentals of Software Process Improvement
      4. The Process Improvement Cycle
        1. Assess Current Practices
        2. Plan Improvement Actions
        3. Create, Pilot, and Implement New Processes
        4. Evaluate Results
      5. Requirements Engineering Process Assets
        1. Requirements Development Process Assets
        2. Requirements Management Process Assets
      6. Requirements Process Improvement Road Map
    2. 23. Software Requirements and Risk Management
      1. Fundamentals of Software Risk Management
        1. Elements of Risk Management
        2. Documenting Project Risks
        3. Planning for Risk Management
      2. Requirements-Related Risks
        1. Requirements Elicitation
        2. Requirements Analysis
        3. Requirements Specification
        4. Requirements Validation
        5. Requirements Management
      3. Risk Management Is Your Friend
    3. Epilogue
    4. A. Current Requirements Practice Self-Assessment
    5. B. Requirements and Process Improvement Models
      1. The Capability Maturity Model for Software
      2. CMMI-SE/SW
        1. Requirements Management Process Area
        2. Requirements Development Process Area
    6. C. Requirements Troubleshooting Guide
      1. Root Cause Analysis
      2. Common Symptoms of Requirements Problems
      3. Common Barriers to Implementing Solutions
    7. D. Sample Requirements Documents
      1. Vision and Scope Document
        1. 1. Business Requirements
          1. 1.1. Background, Business Opportunity, and Customer Needs
          2. 1.2. Business Objectives and Success Criteria
          3. 1.3. Business Risks
        2. 2. Vision of the Solution
          1. 2.1. Vision Statement
          2. 2.2. Major Features
          3. 2.3. Assumptions and Dependencies
        3. 3. Scope and Limitations
          1. 3.1. Scope of Initial and Subsequent Releases
          2. 3.2. Limitations and Exclusions
        4. 4. Business Context
          1. 4.1. Stakeholder Profiles
          2. 4.2. Project Priorities
      2. Use Cases
      3. Software Requirements Specification
        1. 1. Introduction
          1. 1.1. Purpose
          2. 1.2. Project Scope and Product Features
          3. 1.3. References
        2. 2. Overall Description
          1. 2.1. Product Perspective
          2. 2.2. User Classes and Characteristics
          3. 2.3. Operating Environment
          4. 2.4. Design and Implementation Constraints
          5. 2.5. User Documentation
          6. 2.6. Assumptions and Dependencies
        3. 3. System Features
          1. 3.1. Order Meals
            1. 3.1.1. Description and Priority
            2. 3.1.2. Stimulus/Response Sequences
            3. 3.1.3. Functional Requirements
          2. 3.2. Create, View, Modify, and Delete Meal Subscriptions
          3. 3.3. Register for Meal Payment Options
          4. 3.4. Request Meal Delivery
          5. 3.5. Create, View, Modify, and Delete Cafeteria Menus
        4. 4. External Interface Requirements
          1. 4.1. User Interfaces
          2. 4.2. Hardware Interfaces
          3. 4.3. Software Interfaces
          4. 4.4. Communications Interfaces
        5. 5. Other Nonfunctional Requirements
          1. 5.1. Performance Requirements
          2. 5.2. Safety Requirements
          3. 5.3. Security Requirements
          4. 5.4. Software Quality Attributes
        6. Appendix A: Data Dictionary and Data Model
        7. Appendix B: Analysis Models
      4. Business Rules
    8. Glossary
    9. References
    10. Karl E. Wiegers
  8. Index
  9. Copyright