Requirements Analysis and Design Definition: Modelling, Verifying, and Choosing
This domain turns raw information into structured requirements and evaluated design options. BABOK Guide v3 lists six tasks: Specify and Model Requirements, Verify Requirements, Validate Requirements, Define Requirements Architecture, Define Design Options, and Analyze Potential Value and Recommend Solution. Questions usually hinge on the requirement-versus-design split and on verification versus validation.
Core rules
- Requirements state what must be satisfied; design states how it will be satisfied. Both are requirements and design information, but they are not interchangeable.
- Models present different views: process, data, state, interface, roles and permissions, and business rules. Text alone rarely captures rules and states cleanly.
- Verification checks the quality of the requirement itself: complete, consistent, correct, feasible, unambiguous, and testable.
- Validation checks that the requirement addresses the business need and will deliver value; acceptance criteria and prototypes support it.
- Requirements architecture organises requirements and models into a coherent whole with defined viewpoints.
- Design options allocate requirements to solution components; evaluation uses value analysis - financial measures such as net present value, ROI, and payback, plus non-financial factors.
Worked example
A refund flow has two conflicting rules: treasury releases refunds after ten days, published policy promises five. Verification flags the inconsistency before build. A prototype then validates with customers that five days is what the business objective - reduced complaints - actually requires. Two design options follow: extend the existing billing module (cheaper now, more rework risk later) or build a dedicated module (higher cost, better value over five years once support costs are counted). The recommendation follows value, not the lowest sticker price.
Traps that cost marks
- Calling a prototype or a model the solution design and skipping requirement specification.
- Swapping verification and validation under time pressure.
- Choosing the cheapest design option without analysing value or lifecycle cost.
- Treating non-functional requirements as optional detail when they often determine design choice.
- Building an architecture of disconnected models that contradict each other.