CBAP Study Guide — 2026 Edition

This knowledge area turns elicited information into usable requirements and designs, then proves they are good enough and chooses the best solution. Its six tasks follow a logical flow — though IIBA notes that tasks can be performed sequentially, iteratively, or simultaneously: specify and model (shape the raw material), verify (check quality), validate (check value alignment), define the requirements architecture (check the whole hangs together), define design options (sketch possible solutions), and analyze potential value to recommend one. The distinction candidates most often blur is verify versus validate — master it cold.

Specify and Model Requirements

The purpose of Specify and Model Requirements is to analyze, synthesize, and refine elicitation results into requirements and designs. Its output is requirements (specified and modelled): any combination of requirements and designs in the form of text, matrices, and diagrams.

Why it matters: raw elicitation results are not requirements yet — they must be analyzed and expressed precisely. How it is tested: scenarios of turning interview notes into models and specifications. The trap is confusing specification with verification: specifying creates the requirements; verifying checks them.

Verify Requirements

The purpose of Verify Requirements is to ensure that requirements and designs specifications and models meet quality standards and are usable for the purpose they serve. Its output is requirements (verified): a set of requirements or designs of sufficient quality to be used as a basis for further work.

Why it matters: poor-quality requirements corrupt everything downstream. How it is tested: ambiguous, untestable, or contradictory requirements that must be caught. The trap — the one candidates fall into most — is confusing verify with validate: verification checks quality (correct, unambiguous, testable); validation checks alignment to business requirements and value.

Validate Requirements

The purpose of Validate Requirements is to ensure that all requirements and designs align to the business requirements and support the delivery of needed value. Its output is requirements (validated): requirements and designs demonstrated to deliver benefit to stakeholders and align with the business goals and objectives of the change.

Why it matters: perfectly written requirements for the wrong thing are worthless. How it is tested: scenarios where requirements are high quality but disconnected from business goals. The trap is the mirror of the previous one: validation asks "are these the right requirements"; verification asks "are these requirements right."

Define Requirements Architecture

The purpose of Define Requirements Architecture is to ensure that the requirements collectively support one another to fully achieve the objectives. Its output, the requirements architecture, is the requirements and the interrelationships among them, plus recorded contextual information.

Why it matters: individually perfect requirements can conflict as a set. How it is tested: scenarios where two requirements contradict, or a gap leaves an objective uncovered. The trap is confusing it with tracing (Chapter 3): tracing maps relationships for change impact; the architecture ensures the set collectively achieves the objectives.

Define Design Options

The purpose of Define Design Options is to define the solution approach, identify opportunities to improve the business, allocate requirements across solution components, and represent design options that achieve the desired future state. Its output, design options, describes various ways to satisfy one or more needs in a context.

Why it matters: you cannot choose the best solution if you have only defined one. How it is tested: scenarios allocating requirements to components or comparing solution approaches. The trap is confusing design options with the solution recommendation: options are the candidates; the recommendation (next task) is the choice.

Analyze Potential Value and Recommend Solution

The purpose of Analyze Potential Value and Recommend Solution is to estimate the potential value for each design option and to establish which one is most appropriate to meet the enterprise's requirements. Its output, the solution recommendation, identifies the most appropriate solution based on evaluating all defined design options — the recommended solution should maximize the value provided to the enterprise.

Why it matters: it is the decision this whole knowledge area builds toward. How it is tested: scenarios comparing options on value and selecting one. The trap is recommending before estimating: the task requires estimating potential value for each option first, then choosing.

Key numbers & deadlines

Figure	Value	Source
Exam weight of this knowledge area	30% (about 36 of 120 questions)	[hb-blueprint]

Key takeaways

• Logical flow (not a strict sequence): specify and model → verify → validate → requirements architecture → design options → recommend solution.
• Verify = quality of the requirements; validate = alignment to business requirements and value.
• The requirements architecture ensures the set collectively achieves the objectives.
• Design options are candidates; the solution recommendation is the value-maximizing choice.

Chapter 5 quiz — 25 questions

Answer each question, then check the key that follows.

1. An analyst turns workshop notes into process models and written specifications. Which task is this?

• A. Verifying requirements and designs against quality standards.
• B. Specifying and modeling elicitation results into requirements.
• C. Validating requirements against business goals.
• D. Defining the requirements architecture.

2. Requirements are checked for ambiguity, testability, and conformance to standards. Which task is this?

• A. Specifying and modeling requirements.
• B. Validating requirements for business alignment.
• C. Verifying quality standards and usability.
• D. Defining design options for the solution.

3. Stakeholders confirm that a set of requirements will actually deliver the expected business benefits. Which task is this?

• A. Verifying requirements for quality.
• B. Specifying and modeling requirements.
• C. Validating alignment to business value.
• D. Tracing requirements across levels.

4. Which statement best distinguishes verification from validation?

• A. Verification aligns to goals; validation checks quality.
• B. Both check conformance to modeling standards.
• C. Verification approves requirements; validation confirms elicitation.
• D. Verification checks quality; validation checks alignment and value.

5. A specification is precise, complete, and testable — but it automates a process the business plans to eliminate. Which task catches this?

• A. Verify Requirements, because the wording is precise.
• B. Specify and Model Requirements, because models are missing.
• C. Trace Requirements, because relationships are unmapped.
• D. Validate Requirements, because business alignment is missing.

6. A requirement reads: "The system should be fast enough for most users." Which task flags this?

• A. Validate Requirements: speed is a business goal.
• B. Define Requirements Architecture: performance is systemic.
• C. Verify Requirements: the requirement is not testable.
• D. Approve Requirements: stakeholders must agree.

7. Two requirements are each well-formed, but together they demand both manual approval and full automation of the same step. Which task addresses the set as a whole?

• A. Verify Requirements: checking each requirement's quality.
• B. Define Requirements Architecture: collective support of objectives.
• C. Validate Requirements: aligning each to business goals.
• D. Specify and Model Requirements: rewriting the pair.

8. What is the requirements architecture?

• A. Requirements, interrelationships, and recorded context.
• B. The ranking of requirements by implementation order.
• C. The approved requirements ready for construction.
• D. The traceability matrix for change impact analysis.

9. An analyst allocates requirements to software, hardware, and process components and sketches three ways to satisfy the needs. Which task is this?

• A. Specifying and modeling requirements.
• B. Analyzing the potential value of design options.
• C. Defining design options.
• D. Defining the requirements architecture.

10. What are design options?

• A. The approved requirements for construction.
• B. The prioritized backlog for the next iteration.
• C. The confirmed elicitation results from workshop sessions.
• D. Various ways to satisfy needs in a context.

11. Three design options exist, and the analyst estimates each one's potential value to choose the most appropriate. Which task is this?

• A. Analyzing potential value and recommending a solution.
• B. Defining design options for the future state.
• C. Validating requirements against business goals.
• D. Defining the requirements architecture.

12. What does the solution recommendation identify?

• A. The most appropriate solution, maximizing enterprise value.
• B. The cheapest solution regardless of value delivered.
• C. The first design option defined by the team.
• D. The requirements that failed validation.

13. The team debates a custom build versus a commercial package. What must happen before a recommendation?

• A. Stakeholder approval of both design options.
• B. Tracing requirements to each design option.
• C. Estimating potential value of each option.
• D. Verifying the quality of each option.

14. What does "verified requirements" mean?

• A. Of sufficient quality for further work.
• B. Aligned to business goals and objectives.
• C. Agreed by stakeholders for construction.
• D. Captured in elicitation sessions.

15. What does "validated requirements" mean?

• A. Checked against the defined quality standards.
• B. Confirmed with session participants.
• C. Delivering benefit and aligning with goals.
• D. Ranked by relative importance.

16. Specified and modelled requirements take which forms?

• A. Approvals and signatures from stakeholders.
• B. Text, matrices, and diagrams.
• C. Change assessments and recommendations.
• D. Test plans and verification results.

17. Individually clear requirements conflict when combined: one requires real-time sync, another mandates nightly batches. Which task resolves the set-level view?

• A. Verify Requirements: checking each requirement.
• B. Define Requirements Architecture: collective achievement of objectives.
• C. Confirm Elicitation Results: rechecking with stakeholders.
• D. Prioritize Requirements: ranking the conflicting requirements pair.

18. Requirements for reporting are assigned partly to the data warehouse and partly to manual procedures. Which task covers this allocation?

• A. Specifying and modeling the reporting requirements.
• B. Verifying the quality of the reporting requirements.
• C. Validating the value of the reporting requirements.
• D. Defining options and allocating requirements to components.

19. Which task checks that requirements support the delivery of needed value?

• A. Verify Requirements: ensuring quality standards.
• B. Specify and Model Requirements: refining results.
• C. Trace Requirements: aligning across levels.
• D. Validate Requirements: aligning to business requirements.

20. Which task checks that specifications are usable for their purpose?

• A. Validate Requirements: confirming business alignment.
• B. Approve Requirements: obtaining agreement.
• C. Verify Requirements: meeting quality standards.
• D. Maintain Requirements: retaining accuracy.

21. Elicitation results exist as raw notes. What turns them into requirements and designs?

• A. Specifying and modeling the results.
• B. Verifying the notes against defined quality standards.
• C. Validating the notes with stakeholders.
• D. Tracing the notes to business objectives.

22. What is the purpose of defining the requirements architecture?

• A. Ensuring requirements collectively achieve the objectives.
• B. Ranking requirements in order of relative importance.
• C. Obtaining stakeholder agreement for construction.
• D. Estimating the value of each design option.

23. While sketching design options, the analyst spots a chance to eliminate an entire manual handoff. Which task's purpose includes this?

• A. Specify and Model Requirements.
• B. Define Design Options.
• C. Assess Risks during the transition period.
• D. Maintain Requirements for reuse.

24. Two options both meet the requirements; one delivers far more value for slightly higher cost. Which principle guides the recommendation?

• A. The cheapest option is always recommended.
• B. The recommended solution maximizes enterprise value.
• C. The first-defined option takes precedence.
• D. Both options must be built and compared.

25. A team lead says validation cannot begin until every requirement in the set has been verified. Which statement about the two tasks is correct?

• A. Validation must wait until verification of the set is complete.
• B. Verification must wait until validation of the set is complete.
• C. The two are independent and may finish in either order.
• D. Validation may begin early but cannot be completed first.

Answer key & explanations

1. B. Specify and Model Requirements means analyzing, synthesizing, and refining elicitation results into requirements and designs — turning notes into models and specifications is exactly this.^[1]

2. C. Verify Requirements ensures that requirements and designs specifications and models meet quality standards and are usable for the purpose they serve. Ambiguity and testability are quality checks.^[2]

3. C. Validate Requirements ensures all requirements and designs align to the business requirements and support the delivery of needed value — confirming expected benefits is validation.^[3]

4. D. Verification checks quality (meet standards, usable for purpose); validation checks alignment to business requirements and value. The other options swap the two.^{[2, 3]}

5. D. The specification is high quality but automates a doomed process — a value-alignment failure, which Validate Requirements catches. Verification would pass it; only validation asks whether it serves the business need.^[3]

6. C. "Fast enough for most users" is untestable — Verify Requirements flags quality defects like ambiguity and untestability. Validation would ask whether speed serves a business goal, a different question.^[2]

7. B. Define Requirements Architecture ensures the requirements collectively support one another to fully achieve the objectives — set-level coherence is its job, not verification of individual requirements.^[4]

8. A. The requirements architecture is the requirements and the interrelationships among them, plus recorded contextual information. Rankings are prioritization; approvals are a different task.^[4]

9. C. Define Design Options covers defining the solution approach, allocating requirements across solution components, and representing alternative design options — allocation plus three candidate approaches is this task. Defining the requirements architecture is the tempting wrong answer, but it ensures the requirements collectively support one another; it does not allocate them to components or sketch alternatives.^{[4, 5]}

10. D. Design options describe various ways to satisfy one or more needs in a context — they are candidates, not approvals or backlogs.^[5]

11. A. Analyze Potential Value and Recommend Solution estimates the potential value for each design option and establishes which is most appropriate to meet the enterprise's requirements.^[6]

12. A. The solution recommendation identifies the most appropriate solution based on evaluating all defined design options, and it should maximize the value provided to the enterprise.^[6]

13. C. Before recommending, the task requires estimating the potential value for each design option — the recommendation follows the value analysis, not the reverse.^[6]

14. A. Requirements (verified) are a set of requirements or designs of sufficient quality to be used as a basis for further work. Alignment to goals is validation, not verification.^[2]

15. C. Requirements (validated) are those demonstrated to deliver benefit to stakeholders and align with the business goals and objectives of the change. Quality checks are verification.^[3]

16. B. Specified and modelled requirements are any combination of requirements and designs in the form of text, matrices, and diagrams.^[1]

17. B. Conflicting requirements as a set are a requirements-architecture problem: the task ensures requirements collectively support one another to achieve the objectives. Verifying each one individually would miss the conflict.^[4]

18. D. Allocating requirements across solution components is part of Define Design Options — the option takes shape as requirements are assigned to components.^[5]

19. D. Validate Requirements ensures requirements and designs support the delivery of needed value and align to the business requirements. Verification checks quality, a different gate.^[3]

20. C. Verify Requirements ensures specifications and models meet quality standards and are usable for the purpose they serve.^[2]

21. A. Specify and Model Requirements analyzes, synthesizes, and refines elicitation results into requirements and designs — raw notes become requirements here. Verification checks requirements that already exist against quality standards, so it cannot be the step that creates them.^{[1, 2]}

22. A. The purpose of Define Requirements Architecture is to ensure that the requirements collectively support one another to fully achieve the objectives.^[4]

23. B. Define Design Options includes identifying opportunities to improve the business — spotting the eliminable handoff while sketching options is this task. Specify and Model Requirements refines elicitation results into requirements; its purpose does not include finding improvement opportunities.^[5]

24. B. The solution recommendation should maximize the value provided to the enterprise — value, not lowest cost or first definition, guides the choice.^[6]

25. D. The core standard says validation activities may begin before requirements are completely verified, but cannot be completed before they are completely verified. The team lead's rule is the tempting over-simplification: tasks may overlap and run in any order as long as their inputs are present.^{[7, 8]}

Sources cited in this excerpt

1. IIBA Global Business Analysis Core Standard (2017), section 2.5, Specify and Model Requirements CS (7.1).
2. IIBA Global Business Analysis Core Standard (2017), section 2.5, Verify Requirements CS (7.2).
3. IIBA Global Business Analysis Core Standard (2017), section 2.5, Validate Requirements CS (7.3).
4. IIBA Global Business Analysis Core Standard (2017), section 2.5, Define Requirements Architecture CS (7.4).
5. IIBA Global Business Analysis Core Standard (2017), section 2.5, Define Design Options CS (7.5).
6. IIBA Global Business Analysis Core Standard (2017), section 2.5, Analyze Potential Value and Recommend Solution CS (7.6).
7. IIBA Global Business Analysis Core Standard (2017), Validate Requirements CS (7.3), Inputs.
8. IIBA Global Business Analysis Core Standard (2017), chapter 2 introduction.