Software Requirements, 3rd Edition

Book description

Now in its third edition, this classic guide to software requirements engineering has been fully updated with new topics, examples, and guidance. Two leaders in the requirements community have teamed up to deliver a contemporary set of practices covering the full range of requirements development and management activities on software projects.

  • Describes practical, effective, field-tested techniques for managing the requirements engineering process from end to end.

  • Provides examples demonstrating how requirements "good practices" can lead to fewer change requests, higher customer satisfaction, and lower development costs.

  • Fully updated with contemporary examples and many new practices and techniques.

  • Describes how to apply effective requirements practices to agile projects and numerous other special project situations.

  • Targeted to business analysts, developers, project managers, and other software project stakeholders who have a general understanding of the software development process.

  • Shares the insights gleaned from the authors’ extensive experience delivering hundreds of software-requirements training courses, presentations, and webinars.

New chapters are included on specifying data requirements, writing high-quality functional requirements, and requirements reuse. Considerable depth has been added on business requirements, elicitation techniques, and nonfunctional requirements. In addition, new chapters recommend effective requirements practices for various special project situations, including enhancement and replacement, packaged solutions, outsourced, business process automation, analytics and reporting, and embedded and other real-time systems projects.

Table of contents

  1. Dedication
  2. Introduction
    1. Benefits this book provides
    2. Who should read this book
    3. Looking ahead
    4. Case studies
    5. From principles to practice
    6. Errata & book support
    7. We want to hear from you
    8. Stay in touch
  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”
          1. The pure dictionary “requirement”
        2. Levels and types of requirements
        3. Working with the three levels
        4. Product vs. project requirements
      2. Requirements development and management
        1. Requirements development
          1. Elicitation
          2. Analysis
          3. Specification
          4. Validation
        2. Requirements management
      3. Every project has requirements
      4. When bad requirements happen to good people
        1. Insufficient user involvement
        2. Inaccurate planning
        3. Creeping user requirements
        4. Ambiguous requirements
        5. Gold plating
        6. Overlooked stakeholders
      5. Benefits from a high-quality requirements process
    2. 2. Requirements from the customer’s perspective
      1. The expectation gap
      2. Who is the customer?
      3. The customer-development partnership
        1. Requirements Bill of Rights for Software Customers
          1. Right #1: To expect BAs to speak your language
          2. Right #2: To expect BAs to learn about your business and your objectives
          3. Right #3: To expect BAs to record requirements in an appropriate form
          4. Right #4: To receive explanations of requirements practices and deliverables
          5. Right #5: To change your requirements
          6. Right #6: To expect an environment of mutual respect
          7. Right #7: To hear ideas and alternatives for your requirements and for their solution
          8. Right #8: To describe characteristics that will make the product easy to use
          9. Right #9: To hear about ways to adjust requirements to accelerate development through reuse
          10. Right #10: To receive a system that meets your functional needs and quality expectations
        2. Requirements Bill of Responsibilities for Software Customers
          1. Responsibility #1: To educate BAs and developers about your business
          2. Responsibility #2: To dedicate the time that it takes to provide and clarify requirements
          3. Responsibility #3: To be specific and precise when providing input about requirements
          4. Responsibility #4: To make timely decisions about requirements when asked
          5. Responsibility #5: To respect a developer’s assessment of the cost and feasibility of requirements
          6. Responsibility #6: To set realistic requirement priorities in collaboration with developers
          7. Responsibility #7: To review requirements and evaluate prototypes
          8. Responsibility #8: To establish acceptance criteria
          9. Responsibility #9: To promptly communicate changes to the requirements
          10. Responsibility #10: To respect the requirements development process
      4. Creating a culture that respects requirements
      5. Identifying decision makers
      6. Reaching agreement on requirements
        1. The requirements baseline
        2. What if you don’t reach agreement?
        3. Agreeing on requirements on agile projects
    3. 3. Good practices for requirements engineering
      1. A requirements development process framework
      2. Good practices: Requirements elicitation
      3. Good practices: Requirements analysis
      4. Good practices: Requirements specification
      5. Good practices: Requirements validation
      6. Good practices: Requirements management
      7. Good practices: Knowledge
      8. Good practices: Project management
      9. Getting started with new practices
    4. 4. The business analyst
      1. The business analyst role
      2. The business analyst’s tasks
      3. Essential analyst skills
      4. Essential analyst knowledge
      5. The making of a business analyst
        1. The former user
        2. The former developer or tester
        3. The former (or concurrent) project manager
        4. The subject matter expert
        5. The rookie
      6. The analyst role on agile projects
      7. Creating a collaborative team
  5. II. Requirements development
    1. 5. Establishing the business requirements
      1. Defining business requirements
        1. Identifying desired business benefits
        2. Product vision and project scope
        3. Conflicting business requirements
      2. Vision and scope document
        1. 1. Business requirements
          1. 1.1 Background
          2. 1.2 Business opportunity
          3. 1.3 Business objectives
          4. 1.4 Success metrics
          5. 1.5 Vision statement
          6. 1.6 Business risks
          7. 1.7 Business assumptions and dependencies
        2. 2. Scope and limitations
          1. 2.1 Major features
          2. 2.2 Scope of initial release
          3. 2.3 Scope of subsequent releases
          4. 2.4 Limitations and exclusions
        3. 3. Business context
          1. 3.1 Stakeholder profiles
          2. 3.2 Project priorities
          3. 3.3 Deployment considerations
      3. Scope representation techniques
        1. Context diagram
        2. Ecosystem map
        3. Feature tree
        4. Event list
      4. Keeping the scope in focus
        1. Using business objectives to make scoping decisions
        2. Assessing the impact of scope changes
      5. Vision and scope on agile projects
      6. Using business objectives to determine completion
    2. 6. Finding the voice of the user
      1. User classes
        1. Classifying users
        2. Identifying your user classes
      2. User personas
      3. Connecting with 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. User representation on agile projects
      6. Resolving conflicting requirements
    3. 7. Requirements elicitation
      1. Requirements elicitation techniques
        1. Interviews
        2. Workshops
        3. Focus groups
        4. Observations
        5. Questionnaires
        6. System interface analysis
        7. User interface analysis
        8. Document analysis
      2. Planning elicitation on your project
      3. Preparing for elicitation
      4. Performing elicitation activities
      5. Following up after elicitation
        1. Organizing and sharing the notes
        2. Documenting open issues
      6. Classifying customer input
      7. How do you know when you’re done?
      8. Some cautions about elicitation
      9. Assumed and implied requirements
      10. Finding missing requirements
    4. 8. Understanding user requirements
      1. Use cases and user stories
      2. The use case approach
        1. Use cases and usage scenarios
          1. Preconditions and postconditions
          2. Normal flows, alternative flows, and exceptions
          3. Extend and include
          4. Aligning preconditions and postconditions
          5. Use cases and business rules
        2. Identifying use cases
        3. Exploring use cases
        4. Validating use cases
        5. Use cases and functional requirements
          1. Use cases only
          2. Use cases and functional requirements
          3. Functional requirements only
          4. Use cases and tests
        6. Use case traps to avoid
      3. Benefits of usage-centric requirements
    5. 9. Playing by the rules
      1. A business rules taxonomy
        1. Facts
        2. Constraints
        3. Action enablers
        4. Inferences
        5. Computations
        6. Atomic business rules
      2. Documenting business rules
      3. Discovering business rules
      4. Business rules and requirements
      5. Tying everything together
    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 Project scope
          4. 1.4 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 Assumptions and dependencies
        3. 3. System features
          1. 3.x System feature X
          2. 3.x.1 Description
          3. 3.x.2 Functional requirements
        4. 4. Data requirements
          1. 4.1 Logical data model
          2. 4.2 Data dictionary
          3. 4.3 Reports
          4. 4.4 Data acquisition, integrity, retention, and disposal
        5. 5. External interface requirements
          1. 5.1 User interfaces
          2. 5.2 Software interfaces
          3. 5.3 Hardware interfaces
          4. 5.4 Communications interfaces
        6. 6. Quality attributes
          1. 6.1 Usability
          2. 6.2 Performance
          3. 6.3 Security
          4. 6.4 Safety
          5. 6.x [Others]
        7. 7. Internationalization and localization requirements
        8. 8. [Other requirements]
        9. Appendix A: Glossary
        10. Appendix B: Analysis models
      3. Requirements specification on agile projects
    7. 11. Writing excellent requirements
      1. Characteristics of excellent requirements
        1. Characteristics of requirement statements
          1. Complete
          2. Correct
          3. Feasible
          4. Necessary
          5. Prioritized
          6. Unambiguous
          7. Verifiable
        2. Characteristics of requirements collections
          1. Complete
          2. Consistent
          3. Modifiable
          4. Traceable
      2. Guidelines for writing requirements
        1. System or user perspective
        2. Writing style
        3. Level of detail
        4. Representation techniques
        5. Avoiding ambiguity
        6. Avoiding incompleteness
      3. Sample requirements, before and after
    8. 12. A picture is worth 1024 words
      1. Modeling the requirements
      2. From voice of the customer to analysis models
      3. Selecting the right representations
      4. Data flow diagram
      5. Swimlane diagram
      6. State-transition diagram and state table
      7. Dialog map
      8. Decision tables and decision trees
      9. Event-response tables
      10. A few words about UML diagrams
      11. Modeling on agile projects
      12. A final reminder
    9. 13. Specifying data requirements
      1. Modeling data relationships
      2. The data dictionary
      3. Data analysis
      4. Specifying reports
        1. Eliciting reporting requirements
        2. Report specification considerations
        3. A report specification template
      5. Dashboard reporting
    10. 14. Beyond functionality
      1. Software quality attributes
      2. Exploring quality attributes
      3. Defining quality requirements
        1. External quality attributes
          1. Availability
          2. Installability
          3. Integrity
          4. Interoperability
          5. Performance
          6. Reliability
          7. Robustness
          8. Safety
          9. Security
          10. Usability
        2. Internal quality attributes
          1. Efficiency
          2. Modifiability
          3. Portability
          4. Reusability
          5. Scalability
          6. Verifiability
      4. Specifying quality requirements with Planguage
      5. Quality attribute trade-offs
      6. Implementing quality attribute requirements
      7. Constraints
      8. Handling quality attributes on agile projects
    11. 15. Risk reduction through prototyping
      1. Prototyping: What and why
      2. Mock-ups and proofs of concept
      3. Throwaway and evolutionary prototypes
      4. Paper and electronic prototypes
      5. Working with prototypes
      6. Prototype evaluation
      7. Risks of prototyping
        1. Pressure to release the prototype
        2. Distraction by details
        3. Unrealistic performance expectations
        4. Investing excessive effort in prototypes
      8. Prototyping success factors
    12. 16. First things first: Setting requirement priorities
      1. Why prioritize requirements?
      2. Some prioritization pragmatics
      3. Games people play with priorities
      4. Some prioritization techniques
        1. In or out
        2. Pairwise comparison and rank ordering
        3. Three-level scale
        4. MoSCoW
        5. $100
      5. Prioritization based on value, cost, and risk
    13. 17. Validating the requirements
      1. Validation and verification
      2. Reviewing requirements
        1. The inspection process
          1. Participants
          2. Inspection roles
          3. Entry criteria
          4. Inspection stages
          5. Exit criteria
        2. Defect checklist
        3. Requirements review tips
        4. Requirements review challenges
      3. Prototyping requirements
      4. Testing the requirements
      5. Validating requirements with acceptance criteria
        1. Acceptance criteria
        2. Acceptance tests
    14. 18. Requirements reuse
      1. Why reuse requirements?
      2. Dimensions of requirements reuse
        1. Extent of reuse
        2. Extent of modification
        3. Reuse mechanism
      3. Types of requirements information to reuse
      4. Common reuse scenarios
        1. Software product lines
        2. Reengineered and replacement systems
        3. Other likely reuse opportunities
      5. Requirement patterns
      6. Tools to facilitate reuse
      7. Making requirements reusable
      8. Requirements reuse barriers and success factors
        1. Reuse barriers
        2. Reuse success factors
    15. 19. Beyond requirements development
      1. Estimating requirements effort
      2. From requirements to project plans
        1. Estimating project size and effort from requirements
        2. Requirements and scheduling
      3. From requirements to designs and code
        1. Architecture and allocation
        2. Software design
        3. User interface design
      4. From requirements to tests
      5. From requirements to success
  6. III. Requirements for specific project classes
    1. 20. Agile projects
      1. Limitations of the waterfall
      2. The agile development approach
      3. Essential aspects of an agile approach to requirements
        1. Customer involvement
        2. Documentation detail
        3. The backlog and prioritization
        4. Timing
        5. Epics, user stories, and features, oh my!
        6. Expect change
      4. Adapting requirements practices to agile projects
      5. Transitioning to agile: Now what?
    2. 21. Enhancement and replacement projects
      1. Expected challenges
      2. Requirements techniques when there is an existing system
      3. Prioritizing by using business objectives
        1. Mind the gap
        2. Maintaining performance levels
      4. When old requirements don’t exist
        1. Which requirements should you specify?
          1. Level of detail
          2. Trace Data
        2. How to discover the requirements of an existing system
      5. Encouraging new system adoption
      6. Can we iterate?
    3. 22. Packaged solution projects
      1. Requirements for selecting packaged solutions
        1. Developing user requirements
        2. Considering business rules
        3. Identifying data needs
        4. Defining quality requirements
        5. Evaluating solutions
      2. Requirements for implementing packaged solutions
        1. Configuration requirements
        2. Integration requirements
        3. Extension requirements
        4. Data requirements
        5. Business process changes
      3. Common challenges with packaged solutions
    4. 23. Outsourced projects
      1. Appropriate levels of requirements detail
      2. Acquirer-supplier interactions
      3. Change management
      4. Acceptance criteria
    5. 24. Business process automation projects
      1. Modeling business processes
        1. Using current processes to derive requirements
        2. Designing future processes first
      2. Modeling business performance metrics
      3. Good practices for business process automation projects
    6. 25. Business analytics projects
      1. Overview of business analytics projects
      2. Requirements development for business analytics projects
        1. Prioritizing work by using decisions
        2. Defining how information will be used
          1. Information usage by people
          2. Information usage in systems
        3. Specifying data needs
          1. Big data
          2. Data-based (not “database”) requirements
        4. Defining analyses that transform the data
      3. The evolutionary nature of analytics
    7. 26. Embedded and other real-time systems projects
      1. System requirements, architecture, and allocation
      2. Modeling real-time systems
        1. Context diagram
        2. State-transition diagram
        3. Event-response table
        4. Architecture diagram
        5. Prototyping
      3. Interfaces
      4. Timing requirements
      5. Quality attributes for embedded systems
      6. The challenges of embedded systems
  7. IV. Requirements management
    1. 27. Requirements management practices
      1. Requirements management process
      2. The requirements baseline
      3. Requirements version control
      4. Requirement attributes
      5. Tracking requirements status
      6. Resolving requirements issues
      7. Measuring requirements effort
      8. Managing requirements on agile projects
      9. Why manage requirements?
    2. 28. Change happens
      1. Why manage changes?
      2. Managing scope creep
      3. Change control policy
      4. Basic concepts of the change control process
      5. A change control process description
        1. 1. Purpose and scope
        2. 2. Roles and responsibilities
        3. 3. Change request status
        4. 4. Entry criteria
        5. 5. Tasks
          1. 5.1 Evaluate change request
          2. 5.2 Make change decision
          3. 5.3 Implement the change
          4. 5.4 Verify the change
        6. 6. Exit criteria
        7. 7. Change control status reporting
        8. Appendix: Attributes stored for each request
      6. The change control board
        1. CCB composition
        2. CCB charter
          1. Making decisions
          2. Communicating status
        3. Renegotiating commitments
      7. Change control tools
      8. Measuring change activity
      9. Change impact analysis
        1. Impact analysis procedure
        2. Impact analysis template
      10. Change management on agile projects
    3. 29. Links in the requirements chain
      1. Tracing requirements
      2. Motivations for tracing requirements
      3. The requirements traceability matrix
      4. Tools for requirements tracing
      5. A requirements tracing procedure
      6. Is requirements tracing feasible? Is it necessary?
    4. 30. Tools for requirements engineering
      1. Requirements development tools
        1. Elicitation tools
        2. Prototyping tools
        3. Modeling tools
      2. Requirements management tools
        1. Benefits of using an RM tool
        2. RM tool capabilities
      3. Selecting and implementing a requirements tool
        1. Selecting a tool
        2. Setting up the tool and processes
        3. Facilitating user adoption
  8. V. Implementing requirements engineering
    1. 31. Improving your requirements processes
      1. How requirements relate to other project processes
      2. Requirements and various stakeholder groups
      3. Gaining commitment to change
      4. Fundamentals of software process improvement
      5. Root cause analysis
      6. The process improvement cycle
        1. Assess current practices
        2. Plan improvement actions
        3. Create, pilot, and roll out processes
        4. Evaluate results
      7. Requirements engineering process assets
        1. Requirements development process assets
        2. Requirements management process assets
      8. Are we there yet?
      9. Creating a requirements process improvement road map
    2. 32. 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
  9. A. Epilogue
  10. B. Current requirements practice self-assessment
  11. C. Requirements troubleshooting guide
    1. Common signs of requirements problems
    2. Common barriers to implementing solutions
    3. Requirements troubleshooting guide
      1. Process issues
      2. Product issues
      3. Planning issues
      4. Communication issues
      5. Elicitation issues
      6. Analysis issues
      7. Specification issues
      8. Validation issues
      9. Requirements management issues
      10. Change management issues
  12. D. Sample requirements documents
    1. Vision and Scope Document
      1. 1. Business Requirements
        1. 1.1 Background
        2. 1.2 Business Opportunity
        3. 1.3 Business Objectives
        4. 1.4 Success Metrics
        5. 1.5 Vision Statement
        6. 1.6 Business Risks
        7. 1.7 Business Assumptions and Dependencies
      2. 2. Scope and Limitations
        1. 2.1 Major Features
        2. 2.2 Scope of Initial and Subsequent Releases
        3. 2.3 Limitations and Exclusions
      3. 3. Business Context
        1. 3.1 Stakeholder Profiles
        2. 3.2 Project Priorities
        3. 3.3 Deployment Considerations
    2. Use Cases
    3. Software Requirements Specification
      1. 1. Introduction
        1. 1.1 Purpose
        2. 1.2 Document Conventions
        3. 1.3 Project Scope
        4. 1.4 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 Assumptions and Dependencies
      3. 3. System Features
        1. 3.1 Order Meals from Cafeteria
          1. 3.1.1 Description
          2. 3.1.2 Functional Requirements
        2. 3.2 Order Meals from Restaurants
        3. 3.3 Create, View, Modify, and Delete Meal Subscriptions
        4. 3.4 Create, View, Modify, and Delete Cafeteria Menus
      4. 4. Data Requirements
        1. 4.1 Logical Data Model
        2. 4.2 Data Dictionary
        3. 4.3 Reports
          1. 4.3.1 Ordered Meal History Report
        4. 4.4 Data Integrity, Retention, and Disposal
      5. 5. External Interface Requirements
        1. 5.1 User Interfaces
        2. 5.2 Software Interfaces
        3. 5.3 Hardware Interfaces
        4. 5.4 Communications Interfaces
      6. 6. Quality Attributes
        1. 6.1 Usability Requirements
        2. 6.2 Performance Requirements
        3. 6.3 Security Requirements
        4. 6.4 Safety Requirements
        5. 6.5 Availability Requirements
        6. 6.6 Robustness Requirements
      7. Appendix A: Analysis Models
    4. Business Rules
  13. E. Glossary
  14. F.  
    1. References
  15. G. About the authors
  16. Index
  17. About the Authors
  18. Copyright

Product information

  • Title: Software Requirements, 3rd Edition
  • Author(s): Karl Wiegers, Joy Beatty
  • Release date: August 2013
  • Publisher(s): Microsoft Press
  • ISBN: 9780735679658