Requirements Analysis and Design Definition
This knowledge area turns elicited information into structured, verified, validated requirements and recommends a design that delivers the most value. The exam tests the distinction between requirements and design, the difference between verification and validation, and whether you can justify a design recommendation rather than simply pick one.
The six tasks
- Specify and Model Requirements - express requirements as text, matrices or diagrams chosen for the audience and question at hand.
- Verify Requirements - check that the requirements themselves meet quality standards: atomic, unambiguous, complete, consistent, feasible, testable and traceable.
- Validate Requirements - check that the requirements would deliver the business need and value, and that stakeholders agree they are the right requirements.
- Define Requirements Architecture - organise requirements and their relationships into a coherent whole, using views so each audience sees a consistent picture.
- Define Design Options - describe alternative ways to satisfy the requirements, including allocation of requirements to components.
- Analyze Potential Value and Recommend Solution - compare options on benefits, costs, risks and constraints, and recommend one with the reasoning exposed.
Verification versus validation
Verification asks “did we write this correctly?” - internal quality of the requirement. Validation asks “did we write the right thing?” - external fitness for the business need. A requirement can be perfectly verified and still fail validation.
Worked example
Requirement: “The portal must display the customer’s current balance within two seconds of login.”
- Verification: it is singular, measurable, testable and unambiguously scoped. It passes.
- Validation: finance policy confirms balances only after the overnight batch, so a genuinely current balance at 09:00 cannot be guaranteed - the requirement as written would deliver a number the business does not treat as authoritative. The BA rewrites it as “display the last-confirmed balance with its as-of timestamp”, which satisfies the underlying need.
- Design options: read directly from the billing database (fast to build, couples the portal to a batch schema) or read from a purpose-built balance service (higher cost, decoupled). Value analysis weighs latency and future change cost against initial build effort.
Traps that cost marks
- Using verification and validation interchangeably; exams reward the internal/external split.
- Modelling for its own sake - every model should answer a question for a named audience.
- Skipping design options and defending the first idea.
- Writing requirements that embed a design decision (“must use a REST API”) without stating the need.
- Recommending a solution without showing value, cost and risk comparison.