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