The process of identifying, analyzing, documenting, validating and managing system requirements.
Requirement
A description of system services and operational constraints.
Requirements define WHAT the system should do; not HOW.
Types
User
High-level descriptions. Written in natural language, often with diagrams. From user’s (or customer’s) perspectives. Mostly ambiguous.
System
Detailed. Structured. Technical. Basis for contract. Must be precise. Intended to be used by engineers.
Functional
Describes system services and behavior. Must be precise, testable and non-conflicting. Ambiguity leads to misinterpretation.
Non-Functional
Constraints on system properties. Often more critical than functional ones. Affect system architecture. Should be measurable.
Types:
- Product requirements (speed, availability)
- Organizational requirements (standards, tools)
- External requirements (laws, interoperability)
Domain
Come from application domain. Implicit. Hard to understand.
Volatile
Requirements expected to change during development or after deployment.
Arise from the evolving business and technical environment:
- New hardware is introduced
- Business priorities shift
- New legislation is enacted
- User needs emerge through system use
Processes and architectures must accommodate change without excessive rework. Iterative and agile approaches address this. Rigid plan-driven models do not.
Stable
Core requirements unlikely to change.
Software Requirements Specification
Aka. SRS. Official statement of what the system must do. Includes both user and system specifications. Not a design document.
Intended to be used by:
- Customers
- Managers
- Engineers
- Test engineers
- Maintenance engineers
Typically a SRS document includes:
- Preface
- Introduction
- Glossary
- User requirements
- System architecture
- System requirements specification
- System models
- System evolution
- Appendices
- Index
Requirements can be documented in various ways:
- Natural language
Lacks clarity. Ambiguous. Difficult to analyze. - Structured natural language
- Graphical models (UML)
- Mathematical specification
- Tabular specification
Structured Specification
Form-based structure includes:
- Function
- Inputs
- Outputs
- Source
- Action
- Pre-condition
- Post-condition
- Side effects
Used heavily in embedded systems.
Engineering Process
An iterative process of 4 main activities.
Elicitation
Discover requirements from stakeholders. And filter out irrelevant information.
Techniques:
- Interviews (open/closed)
- Scenarios
- Use cases
- Ethnography
Study of how humans (or users) work - Prototyping
Analysis
The activity of examining elicited inputs to produce a clear, complete, consistent and feasible set of specifications. Transforms high-level, ambiguous stakeholder statements into precise, structured specifications and models.
Key tasks:
- Organize and classify requirements
- Refine and decompose high-level specifications into detailed, implementable items and sub-items.
- Resolve ambiguities and conflicts between stakeholder requests through negotiation and prioritization.
- Check feasibility and realism against technical, budgetary and schedule constraints.
- Define interfaces, data and control flows, and interactions (use cases, scenarios, sequence diagrams).
- Identify and specify acceptance criteria and measurable quality attributes (performance, reliability, security).
- Produce models and representations (UML, state machines, data models, formal specs) to reduce misunderstanding.
- Establish traceability links to stakeholders, design artifacts and test cases to support change management.
Validation
Ensure system matches customer needs. Fixing errors after delivery is extremely expensive.
Checks:
- Validity
- Consistency
- Completeness
- Realism
- Verifiability
Done through reviews, prototyping and test case generation.
Management
Managing changes to specifications during development.
Changes arise due to:
- Business changes
- Technical changes
- Legal changes
- User feedback
Changes must be traceable (maybe using unique IDs and version control tools).
Change Process
Steps:
- Problem analysis
- Change analysis and costing
- Change implementation
Must assess impact before accepting change.