Requirements Analysis and Design Definition
Structures and organizes elicited requirements, specifies and models them, validates and verifies their quality, defines requirements architecture, identifies design options, and recommends the option that delivers the greatest value.
Specifies, models, and validates requirements and designs so the right solution gets built.
RADD is the largest single area of the ECBA exam — 30% — because it is where ambiguous business intent becomes specifications a team can build, test, and accept. Most rework downstream is traceable to weak work here.
In practice
The BA structures requirements into models (process, data, rule, behaviour), verifies that each requirement is well-formed (clear, testable, feasible), validates that the set of requirements actually delivers value, evaluates solution options against the criteria from Strategy Analysis, and recommends a solution.
Relationships with other knowledge areas
- →Consumes prioritised, approved requirements from RLCM.
- →Operates within the change strategy from Strategy Analysis.
- →Hands designs to delivery, then receives change requests back through RLCM.
- →Provides Solution Evaluation with the specifications that delivered behaviour will be measured against.
Where this lands on the exam
BACCM touchpoints
- Solution. Solutions are designed and recommended here.
- Value. Validation tests that the design actually delivers the intended value.
- Need. Verification keeps every model and spec tied back to the underlying need.
Language to listen for in scenario stems
When a stem mentions specifying, modelling, verifying, validating, evaluating options, or 'which design would best…' — it is RADD.
Key concepts
The ideas that anchor everything else in this knowledge area.
Requirements describe what is needed; designs describe how that need is met. The same artifact can shift role depending on its audience.
Verification confirms requirements are well-formed (built right). Validation confirms they deliver value (built the right thing).
The structure that organizes requirements so they are coherent, consistent, complete, and traceable.
Multiple credible ways to meet the need — evaluated on value, risk, feasibility, and constraints.
Common pitfalls
Patterns that frequently cost initiatives — and exam points.
- ⚠Specifying solutions disguised as requirements ('the user must click a button…').
- ⚠No model — only prose. Models surface ambiguity prose hides.
- ⚠Validating requirements against the BA's intent instead of business value.
- ⚠Recommending one option without honestly evaluating alternatives.
Tasks
The 6 tasks that make up this knowledge area. Click any task to expand its inputs, outputs, techniques, and guidelines. Technique tags are clickable.