Requirements Elicitation, Analysis and Specification
Domain 4 tests requirements elicitation, analysis, and specification: producing statements that are necessary, unambiguous, complete, and verifiable, and tracing them to sources and evidence.
Core rules and concepts
- A requirement is a statement that translates or expresses a need and its associated constraints and conditions. It must be verifiable and traceable.
- Good characteristics: necessary, unambiguous, complete, singular, feasible, verifiable, and bounded by conditions.
- Analysis includes decomposition, allocation to architecture, prioritization, and conflict resolution among stakeholders.
- Specifications are layered: stakeholder, system, and component requirements. Each level adds design detail without losing traceability to the level above.
Worked example
Stakeholder statement: "The pump must respond quickly." Analysis asks: respond to what, under what conditions, measured how? The specified requirement becomes: "When an occlusion is detected, the pump shall stop infusion and annunciate an alarm within 1.0 s, for occlusion volumes of 0.1 mL or greater, at flow rates from 1 to 500 mL/h." Reasoning: each qualifier makes the statement testable and bounded. The source need remains traceable; the acceptance method is a test.
Traps that cost marks
- Writing a solution as a requirement, such as "use a 32-bit processor."
- Missing conditions, thresholds, and acceptance criteria.
- Ambiguous adjectives: fast, user-friendly, robust, secure.
- Losing traceability when decomposing or allocating.
- Specifying a requirement that cannot be verified within the program's methods.
Key points
- Requirements express needs plus conditions.
- Verifiability is mandatory.
- Analysis resolves conflicts and allocates.
- Layered specs preserve traceability.
- Ambiguity is a defect.