Overview
Requirements Analysis and Design Definition covers six tasks that move from elicited information to a recommended solution. You specify and model requirements, verify that they meet quality standards, validate that they align with business objectives, define a requirements architecture so the set is coherent and complete, define design options including whether to build, buy or combine, and analyze potential value to recommend the solution that best meets the need.
The BABOK distinguishes requirements, usable representations of a need, from designs, usable representations of a solution, and this knowledge area handles both. It takes confirmed elicitation results from Domain 2 and the business objectives and solution scope from Domain 4, works under the information management approach from Domain 1, and hands specified requirements and designs to Domain 3 for tracing, prioritization and approval.
How it's tested
Expect many scenario and case-study questions: which model BEST represents a described concern, whether a flaw is a verification or validation issue, how to classify a requirement, which design option to recommend under stated constraints, or what the business analyst should do NEXT with a set of requirements. Answers depend on precise BABOK vocabulary combined with value-based judgment.
-
Verify or validate
A requirement has a flaw, such as ambiguity or no link to an objective. You decide whether it fails quality checks (verify) or business alignment (validate).
-
Choose the model
A stem describes what stakeholders need to understand, such as decision logic, data relationships or actor goals. You pick the model category and technique that shows it best.
-
Recommend the design
Several design options are compared with costs, benefits, constraints and dependencies. You recommend the option with the best value, which may be none or a phased one.
A requirement reads 'the portal shall load account summaries within two seconds for 95% of requests'. Reviewers confirm it is clear and testable, but no business objective relates to portal speed and customers rarely use the page. Options include rewriting it, verifying it, approving it, or flagging that it may not deliver value. The wording passes verification; the problem is alignment with objectives, so validation fails and the requirement should be questioned.
Tasks 6
Official tasks from the IIBA outline, in outline order.
5.1 Specify and Model RequirementsBABOK Guide task 7.1: analyze, represent and model requirements at the right level of abstraction.
- What it means
- The business analyst analyzes elicitation results and represents them as textual requirements, matrices and diagrams, using model categories such as people and roles, rationale, activity flow, capability, and data and information. Attributes are captured and the level of abstraction is chosen for the audience. The output is requirements (specified and modeled).
- What to understand
- No single model shows everything. Activity flow models show sequence, data models show entities and relationships, rationale models show why, and capability models show what the organization can do. Choosing the model depends on the question stakeholders need answered.
- How it shows up
- Stakeholders disagree about which conditions trigger a loan referral, and you choose a representation. A decision model or decision table expresses the rules precisely.
- Common confusion
- Thinking modeling is documentation for its own sake. Models are analysis tools that reveal gaps, conflicts and assumptions that text alone hides.
5.2 Verify RequirementsBABOK Guide task 7.2: ensure requirements and designs meet quality standards and are fit for use.
- What it means
- The business analyst checks requirements and designs against quality characteristics such as atomic, complete, consistent, concise, feasible, unambiguous, testable, prioritized and understandable, often with checklists and reviews. The output is requirements (verified).
- What to understand
- Verification is about the quality of the representation, not the worth of the requirement. Words like fast, user-friendly or flexible usually fail the unambiguous and testable characteristics.
- How it shows up
- A requirement says 'the screen shall be easy to use' and you are asked what is wrong. It cannot be tested, so it fails verification.
- Common confusion
- Calling this validation. Verification asks whether the requirement is built right; validation asks whether it is the right requirement.
5.3 Validate RequirementsBABOK Guide task 7.3: ensure requirements and designs align with business requirements and deliver value.
- What it means
- The business analyst identifies assumptions, defines measurable evaluation criteria and evaluates whether requirements and designs fall within solution scope and support the business goals and objectives. The output is requirements (validated).
- What to understand
- Validation is continuous and links every requirement back to value. A requirement outside the solution scope or unrelated to any objective should be questioned even if it is perfectly written.
- How it shows up
- A stakeholder adds a well-written feature that no business objective supports. The issue is validation, and the response is to evaluate alignment with the objectives.
- Common confusion
- Mixing this task with the validate traceability relationship in Domain 3, which links a requirement to its test evidence.
5.4 Define Requirements ArchitectureBABOK Guide task 7.4: structure all requirements and designs so they form a coherent, complete whole.
- What it means
- The business analyst uses viewpoints and views, template architectures and the relationships among requirements to ensure that the set supports the business objectives, is complete and is internally consistent. The output is the requirements architecture.
- What to understand
- A viewpoint defines how a type of requirement is represented; a view is the actual set of requirements for a particular solution from that viewpoint. The architecture shows how separate models fit together and exposes gaps between them.
- How it shows up
- Teams produce process models, data models and user stories that contradict each other. Defining the requirements architecture ensures they are consistent and complete.
- Common confusion
- Confusing requirements architecture with enterprise or solution architecture. It structures business analysis information, not technology components.
5.5 Define Design OptionsBABOK Guide task 7.5: identify solution approaches, improvement opportunities and requirement allocation.
- What it means
- The business analyst defines solution approaches, creating, purchasing or combining components, identifies improvement opportunities such as efficiencies, better access to information and additional capabilities, allocates requirements to solution components and describes design options. The output is design options.
- What to understand
- Several designs can satisfy the same requirements. Requirements allocation assigns requirements to components or releases and shapes cost and value of each option.
- How it shows up
- A firm must decide between customizing a package and building in-house. You choose the step that defines and describes the options before recommending.
- Common confusion
- Treating design options as technical designs. The business analyst describes options at the level needed to compare value, not detailed technical specifications.
5.6 Analyze Potential Value and Recommend SolutionBABOK Guide task 7.6: compare design options on value and recommend the best one.
- What it means
- The business analyst estimates expected benefits and costs, determines value, assesses design options against constraints, available resources and dependencies, and recommends the solution that delivers the most value. The output is the solution recommendation.
- What to understand
- Value includes tangible and intangible benefits and costs over time. The recommendation can be one option, a combination, or doing nothing if no option delivers enough value.
- How it shows up
- Two options deliver similar benefits, but one has a dependency on a system being retired. The better recommendation accounts for that constraint.
- Common confusion
- Picking the option with the most features or the lowest cost alone. The recommendation weighs benefit against cost, risk and constraints.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Requirements classification schema
The BABOK classifies requirements as business, stakeholder, solution (functional and non-functional) and transition requirements.
- Remember
- Transition requirements are temporary capabilities, such as data conversion or training, needed only to move from current to future state.
- Tested as
- Classification questions use statements that sit near the boundaries between types.
- Trap
- Labeling data migration as a functional requirement rather than a transition requirement.
-
Functional vs. non-functional requirements
Functional requirements describe behaviors and information the solution manages; non-functional requirements describe conditions or qualities, such as performance, security and usability.
- Remember
- Both are solution requirements; non-functional requirements constrain how well the solution behaves.
- Tested as
- Appears in classification and verification questions.
- Trap
- Classifying a response-time requirement as functional because it mentions a system action.
-
Requirement vs. design
A requirement is a usable representation of a need; a design is a usable representation of a solution.
- Remember
- The same artifact can be a requirement or a design depending on whether it focuses on the need or the solution.
- Tested as
- Questions test whether a screen mock-up or a rule is describing a need or a solution.
- Trap
- Assuming business analysts only produce requirements and never designs.
-
Verify vs. validate
Verification checks that requirements are well formed and meet quality characteristics; validation checks that they align with business objectives and deliver value.
- Remember
- Verify means built right; validate means right thing.
- Tested as
- Among the most frequently tested distinctions in this knowledge area.
- Trap
- Calling an untestable requirement a validation failure.
-
Characteristics of requirements quality
Atomic, complete, consistent, concise, feasible, unambiguous, testable, prioritized and understandable.
- Remember
- Vague adjectives fail unambiguous and testable; compound statements fail atomic.
- Tested as
- Verification questions ask which characteristic a given statement violates.
- Trap
- Choosing 'complete' when the real problem is ambiguity.
-
Model categories
BABOK model categories are people and roles, rationale, activity flow, capability, and data and information.
- Remember
- Choose the category based on what stakeholders need to understand.
- Tested as
- Model-selection questions describe a concern and expect the matching category.
- Trap
- Choosing a process model when the concern is the rules behind a decision.
-
Decision modeling
Representing business decisions and the rules behind them, often with decision tables or trees.
- Remember
- Separating decision logic from process flow keeps both models simpler.
- Tested as
- Complex conditional logic in a stem points to it.
- Trap
- Embedding many conditions as branches in a process model.
-
Viewpoints and views
A viewpoint sets conventions for representing a type of requirement; a view is the actual set of requirements from that viewpoint for a specific solution.
- Remember
- Requirements architecture uses multiple views to ensure the set is complete and consistent.
- Tested as
- Appears in Define Requirements Architecture questions about inconsistent models.
- Trap
- Treating a view and a viewpoint as synonyms.
-
Solution approaches
The BABOK identifies creating a solution, purchasing one, or combining both as approaches when defining design options.
- Remember
- Each approach changes cost, time, risk and fit; the choice follows value analysis.
- Tested as
- Build-versus-buy scenarios test this directly.
- Trap
- Assuming buying is always cheaper or faster without considering customization and fit.
-
Requirements allocation
Assigning requirements to solution components and releases.
- Remember
- Allocation determines what each component must do and affects the cost and value of each option.
- Tested as
- Release-planning and design-option questions use it.
- Trap
- Confusing allocation with prioritization in Domain 3.
-
Solution recommendation
The output of Analyze Potential Value and Recommend Solution, identifying the design option that best delivers value.
- Remember
- It may recommend no change if no option is worth its cost.
- Tested as
- Final-step questions in case studies often end here.
- Trap
- Recommending the option with the most features regardless of cost or constraints.
-
Measurable evaluation criteria
Criteria defined during validation to judge whether the solution, once implemented, has delivered the expected value.
- Remember
- They link validation to performance measurement in Solution Evaluation.
- Tested as
- Questions on how to confirm a requirement's value later point here.
- Trap
- Leaving evaluation criteria until after implementation.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Verify Requirements vs. Validate Requirements
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Verify Requirements | Check requirements and designs against quality characteristics | Focus on how well the requirement is expressed | Thinking a verified requirement is necessarily valuable |
| Validate Requirements | Check alignment with business requirements, solution scope and value | Focus on whether the requirement should exist | Calling ambiguous wording a validation problem |
Business vs. stakeholder vs. solution vs. transition requirements
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Business requirement | Goals, objectives and outcomes of the enterprise | Why the change is happening | Treating it as a feature request |
| Stakeholder requirement | Needs of stakeholders or groups that must be met | Bridges business requirements and solution requirements | Calling any requirement a stakeholder said a stakeholder requirement |
| Solution requirement | Capabilities and qualities of the solution, functional and non-functional | Describes what the solution does and how well | Mixing in temporary migration needs |
| Transition requirement | Temporary capabilities to move from current to future state | No longer needed once the transition is complete | Classifying data conversion or training as a solution requirement |
Process model vs. data model vs. decision model vs. use case
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Process model | Sequence of activities, roles and flows | Shows how work moves step by step | Overloading it with complex business rules |
| Data model | Entities, attributes and relationships | Shows information structure, not behavior | Using it to show workflow order |
| Decision model | Decisions and the rules or conditions that drive them | Makes complex logic explicit and testable | Embedding logic in process branches instead |
| Use cases and scenarios | Interactions between actors and a solution to achieve a goal | Shows actor goals, main and alternate flows | Using it to model data relationships |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Reversing verify and validate
- What candidates pick
- Validation when a requirement is ambiguous or untestable.
- Why it looks right
- In everyday speech, validate means checking something is correct.
- Why it's wrong
- Quality of expression is verification; alignment with objectives is validation.
Clue to watch for Vague words or compound statements signal verification; missing links to objectives or scope signal validation.
-
Misclassifying temporary needs
- What candidates pick
- Functional requirement for migrating legacy data.
- Why it looks right
- The migration involves system behavior.
- Why it's wrong
- Capabilities needed only during the move from current to future state are transition requirements.
Clue to watch for Words like conversion, cutover, temporary or training during rollout.
-
Process model for rules
- What candidates pick
- A detailed process map to capture complex eligibility conditions.
- Why it looks right
- Process models are familiar and stakeholders understand them.
- Why it's wrong
- Complex conditional logic is clearer and more testable in a decision model or decision table.
Clue to watch for Multiple conditions, thresholds or combinations driving one outcome.
-
Most features wins
- What candidates pick
- The design option that satisfies the most requirements.
- Why it looks right
- It appears to deliver the most to stakeholders.
- Why it's wrong
- Analyze Potential Value weighs benefits against costs, constraints, risk and dependencies; a leaner option may deliver more value.
Clue to watch for The stem gives costs or constraints alongside features.
-
Perfect wording equals done
- What candidates pick
- Approving a clear, testable requirement no objective supports.
- Why it looks right
- It passes every quality check.
- Why it's wrong
- Requirements outside solution scope or without value fail validation and should be questioned.
Clue to watch for A requirement added late by one stakeholder with no linked objective.
-
Ignoring do-nothing
- What candidates pick
- Always recommending one of the change options presented.
- Why it looks right
- The initiative exists, so a change feels expected.
- Why it's wrong
- If no option delivers enough value relative to cost and risk, the recommendation can be to make no change.
Clue to watch for All options show costs exceeding expected benefits.
-
Detailed technical design
- What candidates pick
- Producing database schemas and code-level designs as design options.
- Why it looks right
- More detail feels more rigorous.
- Why it's wrong
- The business analyst describes design options at the level needed to compare value and allocate requirements, working with implementation subject matter experts.
Clue to watch for Questions asking what the business analyst should produce for decision makers.
Answer framework
Use these steps when a scenario asks how to analyze, check, organize or recommend requirements and designs.
- Decide whether the stem is about representing information, checking its quality, checking its value, organizing the whole set or choosing among design options.
- For representation questions, name what stakeholders need to understand and pick the matching model category, such as decision, data, process or actor goals.
- For quality versus value questions, apply verification to wording and characteristics, and validation to alignment with objectives and solution scope.
- When models or requirements conflict, define or revisit the requirements architecture using views to restore completeness and consistency across the set.
- For recommendations, compare design options on benefits, costs, risks, constraints and dependencies, and remember that doing nothing is a valid option.
Practice question
Want more like this? The CBAP practice test has questions for every domain.
Checklist
0 of 14
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Give this domain the largest share of your study time, roughly double that of any other. Start with the vocabulary that underpins everything else: requirement versus design, the classification schema, and verify versus validate. Then study the six tasks in order, from specifying and modeling through to recommending a solution.
The high-priority concepts are verify versus validate, transition requirements, model selection and value-based recommendation. Candidates commonly underestimate Define Requirements Architecture, which sounds abstract but produces clear questions about inconsistent or incomplete models, and Define Design Options, where requirements allocation and improvement opportunities are easy to overlook. Model selection also deserves deliberate practice: build a table linking each common model to the question it answers best.
After reading, practice with many short classification and verification items to make the vocabulary automatic, then move to longer case studies that end with a solution recommendation. Revisit Domain 4 so that business objectives and solution scope are fresh, because validation and recommendation depend on them. Track your errors by type, such as classification, verification or modeling, and target the weakest type first.
FAQ
Why is Requirements Analysis and Design Definition weighted so heavily?
IIBA's blueprint gives it 30%, double any other knowledge area, which is about 36 of 120 questions as a planning estimate. It covers the core analytical work of specifying, checking and recommending solutions.
What is the simplest way to remember verify versus validate?
Verify checks that a requirement is well built: clear, testable, consistent. Validate checks that it is the right requirement: aligned to business objectives and within solution scope.
What are transition requirements?
Temporary capabilities needed to move from the current state to the future state, such as data conversion, parallel running or user training. They are no longer needed after the transition.
Do business analysts produce designs?
Yes. The BABOK treats designs as usable representations of a solution, such as screen mock-ups or process designs, and the business analyst defines design options at the level needed to compare value.
Which models should I know for the exam?
Know what each BABOK model category shows: people and roles, rationale, activity flow, capability, and data and information, plus common techniques such as process models, data models, decision models and use cases.
Can the recommended solution be to change nothing?
Yes. If no design option delivers enough value against its costs, risks and constraints, recommending no change is a legitimate outcome.
How much study time should I plan for this domain?
As a planning estimate, about 45 to 60 hours within a 180-hour plan, with a large share spent on practice questions and case studies.
Other Business Analysis certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 5 knowledge
You have covered modeling, verification, validation, requirements architecture, design options and value-based recommendation, the largest share of the CBAP blueprint. Practice questions will show whether you can apply verify versus validate and model selection quickly.