Knowledge areas BABOK Guide v3, chapter 7
Requirements Analysis and Design Definition
In short This knowledge area (often shortened to RADD) covers how you turn what you have elicited into clear requirements and designs, check their quality and business value, organize them into a coherent whole, and compare solution options to recommend the best one.
Based on: IIBA, BABOK® Guide v3, chapter 7 “Requirements Analysis and Design Definition”; business analysis training materials (task reference cards and course slides).
On this page
Purpose#
Elicitation gives you raw material: notes, observations, documents, ideas. In the BABOK® Guide, this knowledge area is where you analyze, synthesize and refine that material into requirements (what is needed) and designs (how a need could be met), then use them to find and recommend a solution. For the difference between the two, see Requirements vs. Designs.
Through the lens of the Business Analysis Core Concept Model, you transform elicitation results into requirements and designs that define the change, analyze needs to recommend a solution, identify and recommend the options with the most value, tailor requirements for different stakeholder groups, estimate and quantify the value of options, and model the context in forms all stakeholders can understand.
Tasks#
The BABOK Guide defines six tasks.
7.1 Specify and Model Requirements. You describe requirements and designs in detail, using text, matrices and models suited to the audience. You produce: specified and modelled requirements.
7.2 Verify Requirements. You check that requirements and designs are well formed: detailed enough, internally consistent and of good quality. You produce: verified requirements.
7.3 Validate Requirements. You check that requirements and designs actually deliver business value and support the organization’s goals. You produce: validated requirements.
7.4 Define Requirements Architecture. You structure all requirements and designs so they fit together and jointly support the business goal, without gaps or contradictions. You produce: a requirements architecture.
7.5 Define Design Options. You identify and describe different possible ways of meeting the business need. You produce: design options.
7.6 Analyze Potential Value and Recommend Solution. You estimate the value of each option, compare trade-offs, and recommend the option with the greatest overall benefit. You produce: a solution recommendation.
A simple way to remember 7.2 and 7.3: verification asks “is this requirement written right?”; validation asks “is this the right requirement?”.
Key inputs and outputs#
| Task | What goes in (simplified) | What comes out |
|---|---|---|
| 7.1 Specify and model | Elicitation results, confirmed or not | Specified and modelled requirements |
| 7.2 Verify | Specified requirements | Verified requirements |
| 7.3 Validate | Specified requirements | Validated requirements |
| 7.4 Architecture | Requirements in any state; the solution scope from strategy analysis | Requirements architecture |
| 7.5 Design options | The change strategy; validated and prioritized requirements | Design options |
| 7.6 Recommend | Potential value from strategy analysis; design options | Solution recommendation |
Techniques you will use most#
- Modelling and specifying (7.1, 7.4): Use Cases and Scenarios, User Stories, Data Modelling, Data Dictionary, Functional Decomposition, Scope Modelling, Organizational Modelling, Prototyping.
- Checking quality and value (7.2, 7.3): Acceptance and Evaluation Criteria, Reviews, Item Tracking, Metrics and KPIs, Document Analysis, Financial Analysis.
- Generating and choosing options (7.5, 7.6): Brainstorming, Benchmarking and Market Analysis, Vendor Assessment, Workshops, Business Cases, Backlog Management, SWOT Analysis.
Practical tips#
Verify against a fixed list of quality characteristics#
The training materials, following the BABOK Guide, check requirements against nine characteristics. Turn them into a review checklist:
- Atomic: self-contained, one idea per requirement.
- Complete: nothing needed to understand it is missing.
- Consistent: does not contradict other requirements or stakeholder needs.
- Concise: no unnecessary detail.
- Feasible: achievable within known risk, schedule and budget.
- Unambiguous: only one reasonable reading.
- Testable: you can show whether it is met.
- Prioritized: its relative importance is known.
- Understandable: uses the agreed vocabulary of the audience.
Build the architecture from viewpoints#
A viewpoint pairs a stakeholder group with a type of information and sets how requirements are presented to them: process models for operations staff, data models for data owners, use cases or user stories for the delivery team, security and audit views for compliance. A view is a set of requirements seen through one viewpoint. Together, the views make up the requirements architecture, which is what lets you judge completeness and consistency across the whole set. Frameworks and templates (industry, sector or company standards) can give you ready-made viewpoints; you start from an empty template and fill it with domain content.
Make value explicit#
The training materials summarize value as benefits minus costs. Benefits include revenue, lower risk, compliance with policy and a better user experience. Costs include acquisition, negative effects on stakeholders, ongoing support, and the physical, information and human resources needed. Also count the opportunity cost: the value of the best option you did not choose. Consider build, buy and hybrid approaches, and always include integration effort in the comparison.
Example: options at The Workshop#
For online booking at The Workshop (a fictional chain of 12 bike-repair shops), the analyst models the booking flow as use cases, verifies them in a review with front-desk staff and developers, and validates them against the objective of reducing phone bookings. Three design options are described: an off-the-shelf booking service, a custom build by the outside development team, and a hybrid (off-the-shelf booking plus a small custom module for repair-status notifications). The recommendation compares benefits, costs, integration with parts ordering, and what each option rules out for later.
Sources and further reading#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Chapter 7 “Requirements Analysis and Design Definition”.
- Business analysis training materials (practice examples and templates): task reference cards for chapter 7; course slides on requirements analysis and design definition (quality characteristics, requirements architecture, value of solution options).