How do I distinguish a business requirement from a solution requirement?

A business requirement states an outcome the organization needs, such as reducing the time to resolve claims. A solution requirement states a capability or quality a solution must provide, such as displaying all open claims for one customer. Ask whether the statement would still make sense if the proposed product changed. If it would, it may express the underlying business need; if it describes behavior or quality of a particular solution, classify it accordingly and trace it to the need.

When should I use observation instead of an interview?

Use observation when the actual sequence of work, handoffs or workarounds matters and people may omit routine steps when describing them. Use an interview to learn goals, exceptions, reasoning and concerns that may be invisible during observation. For example, watching an agent copy a reference number reveals the extra step; asking why may reveal that two systems use different customer identifiers. The findings complement each other and should be confirmed with the people who do the work.

How can a solution meet its requirements yet fail to deliver value?

Acceptance checks establish that specified behavior works. Value depends on whether that behavior improves the intended outcome in the operating environment. A scheduling tool may pass every functional test while staff continue using spreadsheets because the tool lacks access at the point of work. Measure both use and the target outcome, investigate the cause of any gap, and decide whether to change the solution, the surrounding process or the original value expectation.

CBAP Study Guide: Applying Business Analysis

Start with concept 1 Choose a topic

CBAP scenarios ask you to make business analysis decisions with incomplete information, competing stakeholder interests and real constraints. A useful starting point is to identify the decision being made: how to plan the analysis, obtain reliable information, manage a changing requirement, choose a future state, define a solution or judge its results. The same technique can serve different purposes. An interview may reveal a need, while a decision table may expose a missing business rule. Trace a proposed feature back to the outcome it should improve, then decide what evidence would show that improvement occurred. The sixty concepts below follow that path across IIBA’s six BABOK-aligned knowledge areas, with worked situations that require a choice and an interpretation.

Business analysis planning and monitoring

1. Choose an analysis approach

Choose an approach by asking which decisions can be settled early, which need feedback, and how expensive late changes would be. Predictive analysis defines requirements and approvals before dependent work proceeds; it suits stable obligations and costly rework. Adaptive analysis refines requirements through short cycles when users must see a working option to judge it. A hybrid approach assigns these methods to different parts of the same change. Identify dependencies between the parts so a dashboard iteration cannot silently alter an agreed reporting definition. Record when each requirement will be detailed, reviewed, and approved, then revisit the approach as uncertainty changes. The CBAP Handbook identifies business analysis planning and monitoring as an examination knowledge area; choosing an approach still depends on the case's risks and evidence.

Worked example: A reporting team has a fixed submission date and known mandatory fields, but users disagree about dashboard layouts. The analyst gets the field definitions and reporting rules approved before building dependent data flows. Users then test dashboard versions in short cycles. A layout change is inexpensive; a late change to a submitted field could force data and validation rework. The plan therefore treats the two workstreams differently.

Watch the distinction: A fixed deadline does not make every requirement stable. Treating dashboard preferences as settled early may create rework, while leaving mandatory reporting definitions open can endanger the submission.

Reference: [1]

2. Set decision authority

Decision authority should be explicit before disagreements arise. For each important decision, identify who supplies evidence, who recommends an option, who approves it, and who resolves an impasse. A stakeholder may perform several roles, but participation in an interview does not grant approval rights. Use a stakeholder or decision matrix to record the decision subject, accountable owner, consulted parties, and escalation path. Check that the owner can accept the effect on the business outcome, not merely explain a technical constraint. Present competing options with consequences for service, cost, and operations so the owner can make an informed choice. Record the decision and rationale where affected requirements can trace to them. If the named owner lacks authority over a consequence, resolve that gap before treating the decision as final.

Worked example: Sales wants orders accepted until 5 p.m.; operations says capacity requires a 2 p.m. cutoff. The analyst checks order volumes and fulfillment delays, documents both options, and asks the product owner, who owns the service outcome, to decide. Sales and operations are consulted, and engineering checks feasibility. Their attendance and expertise do not replace the product owner's approval.

Watch the distinction: Consensus among attendees is not necessarily authorization. If the accountable owner was absent, label the outcome a recommendation or open decision until that owner approves it.

Reference: [1]

3. Find the affected stakeholders

Start with the proposed change, then follow work, information, and decisions across its boundaries. List people who create inputs, use outputs, approve exceptions, support the process, or bear consequences when it fails. This finds stakeholders who are missing from the initial project list. For each group, assess what changes for them, what knowledge they hold, their influence over decisions, and how much engagement they need. High influence calls for timely decision access; detailed operational knowledge may call for observation even when its holder has little formal authority. A stakeholder map is therefore a working analysis tool, not a directory. Recheck it when a new handoff or exception appears, and give each engagement a purpose such as validating a rule or testing a service effect.

Worked example: Finance and engineering are named for a billing change. Mapping the refund flow shows that support agents start requests and refund approvers decide exceptions. The analyst adds agents to observe intake and test wording, and approvers to confirm authority rules. Finance validates ledger effects; engineering checks implementation constraints. Each group is included because a specific task or decision changes.

Watch the distinction: A project roster can omit people affected by the process. Adding only senior sponsors misses frontline handoffs; inviting everyone to every meeting wastes time and obscures each person's purpose.

Reference: [1]

4. Plan stakeholder engagement

Engagement methods should match the evidence needed and the stakeholder's ability to participate. A workshop is useful when several groups must inspect one process and negotiate a shared rule. Interviews can uncover individual experiences, sensitive concerns, or customer effects that a group session may suppress. Observation tests descriptions against actual work, while a short written review can confirm a specific decision without convening everyone again. Plan who will attend, what they should prepare, what artifact they will review, and how absent perspectives will be obtained. Separate consultation from approval so a well-attended workshop is not mistaken for a final decision. Where interests conflict, use concrete cases and a visible issue log; circulate the outcome in a form each group can check.

Worked example: Branch managers have one hour together, while customers live across many locations. The analyst uses the joint workshop to compare branch cutoff rules and record unresolved conflicts. Targeted customer interviews then test whether the proposed cutoff causes missed service. The analyst summarizes both findings for the authorized owner; the manager workshop alone cannot establish the customers' experience.

Watch the distinction: The easiest group to assemble is not necessarily representative. A rule that works for branch managers may still harm dispersed customers whose experience was never examined.

Reference: [1]

5. Manage analysis information

Analysis information includes more than requirements: decisions, assumptions, models, evidence, and unresolved questions also need a dependable home. Define a naming and organization scheme that lets readers locate the current item and its related material. Give controlled items an owner, status, version, and change history; link an approved rule to the decision that authorized it. Set access according to sensitivity, so examples containing personal information are protected while approved business wording remains available to implementers. Decide how feedback is incorporated and how long superseded versions must remain available for impact analysis. A repository alone does not create trust: teams need to know which item is authoritative and whether it is proposed, approved, or retired. Periodically check that links and ownership remain accurate.

Worked example: Two teams have different consent-rule documents. The analyst compares them with the recorded decision, gets the rule owner to confirm the approved wording, and publishes one version with its status and decision link. Both teams can read that wording. Customer examples used to explain the dispute stay in a restricted area, while the superseded versions remain identifiable.

Watch the distinction: Putting every document in one shared folder does not resolve contradictory versions. Without status and ownership, teams may continue implementing whichever copy they found first.

Reference: [1]

6. Estimate analysis work

Estimate the activities needed to produce reliable decisions, not just the time spent in meetings or the number of documents promised. Break work into preparation, elicitation, synthesis, modelling, review, revision, and coordination. Estimate each using the number of stakeholder groups, process variants, interfaces, and review cycles. State assumptions separately: an estimate based on one approval round will change if several owners must reconcile conflicting rules. Use a range or an explicit contingency for uncertain work, then refine it after initial evidence. Distinguish analyst effort from elapsed time; four hours of work can take a week if reviewers are unavailable. This logic also helps explain estimates in a business case, as the FPAC study guide explores for broader planning decisions. Track actual effort to improve later estimates.

Worked example: Four interviews each require two hours of preparation, one hour in the session, and one hour of synthesis. Analyst effort is 4 × (2 + 1 + 1) = 16 hours. If one group review is estimated at three hours, the stated total becomes 19 analyst hours. That excludes waiting time for reviewers and any revisions they request.

Watch the distinction: Counting only four interview hours hides preparation and synthesis. Adding an unexplained percentage afterward also makes it hard to see which uncertainty the allowance covers.

Reference: [1]

7. Select techniques for the question

Choose a technique for the uncertainty it can resolve. A process model exposes sequence, handoffs, and decision points. A decision table makes combinations of conditions and resulting actions inspectable. Observation reveals workarounds that participants may forget to describe; interviews reveal motives and constraints that observation alone may miss. Begin with a precise question, then select the smallest set of techniques that produces evidence for the decision. Check what each technique cannot show. A process diagram may identify where an approval occurs without establishing the rule for granting it. A decision table can establish the rule but may omit who supplies the data. Use findings from one technique to focus the next, and validate the resulting model with the people who perform or own the work.

Worked example: Everyone agrees that an order reaches a supervisor before release, but exceptions remain disputed. The analyst maps the flow to locate the supervisor decision, then builds a table using order type, customer status, and capacity as conditions. Stakeholders review each combination and identify a missing action for a new customer when capacity is full. Another broad interview would have made that gap harder to see.

Watch the distinction: Familiarity with a technique is not a reason to use it everywhere. Repeated interviews may collect opinions without exposing contradictory condition combinations.

Reference: [1]

8. Measure analysis performance

Measure analysis work with indicators that connect to decision quality and delivery timeliness. Possible measures include the share of requirements returned for ambiguity, time from an open question to a decision, and changes caused by overlooked stakeholders. Define each measure's numerator, denominator, period, and review point before comparing results. A rising return rate might indicate weaker drafting, stricter review, or a more complex batch; investigate the causes rather than treating the number as a verdict. Pair a quality measure with a flow measure so quicker reviews do not hide poor decisions. Use findings to change an activity, such as testing wording with users before formal review, then check whether the measure improves. CBAP practice questions can also be used to rehearse this interpretation in scenarios.

Worked example: Ten of 40 requirements reviewed this month are returned for ambiguous wording. The return rate is 10 ÷ 40 = 25%. Eight of the ten came from one exception workflow, so the analyst reviews its terms with operational staff before the next submission. A later rate is useful only if the review criteria and requirement mix are comparable.

Watch the distinction: Fewer returned requirements do not automatically mean better analysis. Reviewers may be less rigorous, or difficult requirements may have been deferred rather than clarified.

Reference: [1]

9. Adjust the analysis plan

A plan is an agreement about how analysis will answer known questions, so new evidence may make it incomplete. When a discovery changes scope or risk, identify the affected decisions and whether planned activities can still provide enough evidence. Add or replace activities accordingly, estimate the effort and schedule effect, and explain the reason to decision makers. Preserve the earlier plan and record the change so later reviewers can see why time or resources moved. Do not automatically restart all analysis: focus on the newly exposed process, dependency, or stakeholder. Check whether the discovery also changes who must approve a rule. Replanning is successful when it produces a better decision path and keeps delivery expectations realistic, not merely when a revised schedule is issued.

Worked example: During a refund pilot, an agent reveals that every refund receives a manual approval absent from the process map. The analyst observes the handoff, examines approval criteria, and adds the approvers to review. The schedule gains a rule workshop and an approval checkpoint. The change record explains the added effort and identifies which original assumptions were wrong.

Watch the distinction: Keeping the original activity list for the sake of schedule consistency can leave a material approval rule unanalyzed. Quietly adding work hides its effect on delivery commitments.

Reference: [1]

Elicitation and collaboration

10. Prepare an elicitation session

Preparation starts with the decision the elicitation must support. Write an objective narrow enough to test, such as identifying where late deliveries are rerouted, then review existing process steps and known exceptions. Select participants for the knowledge they hold across the relevant handoff, including someone who handles failures rather than only the normal path. Choose a format that suits the question: an interview for detailed experience, observation for actual sequence, or a workshop for conflicting rules. Prepare prompts for recent concrete cases and for conditions that change the outcome. Decide what evidence to capture, how assumptions will be marked, and who will confirm the notes. Send enough context for participants to bring examples while leaving room to discover unanticipated behavior.

Worked example: The analyst needs to understand why late deliveries are rerouted. Before meeting dispatchers, they review the current routing map and collect two delayed-order records. A dispatcher explains the normal handoff; an exception handler explains what happens when no driver accepts it. The session aims to identify triggers and ownership, producing a corrected flow and specific open questions.

Watch the distinction: An open meeting can generate many suggestions without answering the decision at hand. Inviting only the normal-process owner may also conceal exception work.

Reference: [1]

11. Probe beyond stated requests

A requested feature is evidence about a problem, but its proposed form may be too broad or mistimed. Ask what event prompts the request, what action the recipient can take, and how success would be recognized. Probe recent incidents, including one where the feature would have helped and one where it would not. Separate the trigger, the actionable time window, the responsible actor, and the information needed to decide. This converts a visual preference into a capability that can be evaluated against alternatives. Avoid dismissing the original idea; record it as an option and test whether it serves the need. Confirm the refined need with the requester and the people expected to act, since an alert without an available response can create noise rather than value.

Worked example: A manager requests a red alert for every delayed order. Recent cases show that dispatchers can reassign an order before a driver leaves, but cannot recover time once it is in transit. The analyst defines the need as identifying likely delays before dispatch and naming the dispatcher who can intervene. A red alert remains one possible display, subject to testing.

Watch the distinction: Implementing the requested color for all delays may satisfy the words spoken while flooding staff with cases they cannot change. First establish the actionable condition.

Reference: [1]

12. Facilitate a decision workshop

A decision workshop needs a defined issue, participants with relevant knowledge, and a method for making differences visible. Begin with a shared example or timeline rather than asking for abstract preferences. Put each proposed rule, its supporting evidence, and its effect on customers and capacity where the group can inspect them. Facilitate discussion around conditions and consequences, then distinguish an agreed recommendation from an authorized decision. Record the exact rule, owner, rationale, and any unresolved dependency. An issue log prevents a staffing or data question from being treated as settled simply because the meeting ended. Close by confirming what participants believe was decided and when the remaining question will return. This structure turns competing views into testable rules without forcing false consensus.

Worked example: Sales requests same-day order changes; operations proposes a noon cutoff. A timeline shows that post-noon changes sometimes disrupt packing. The group agrees to recommend normal changes through noon and later changes only with an exception approver. The analyst records who may approve and leaves evening approver coverage open, with an owner and due date, before seeking formal approval.

Watch the distinction: A friendly meeting is not evidence that every exception was resolved. If staffing for the approver remains unknown, the proposed rule cannot yet operate reliably.

Reference: [1]

13. Observe work as performed

Observation shows what people actually do, including pauses, duplicate entry, informal checks, and handoffs omitted from written procedures. Set a specific observation objective and note the case type, workload, and systems used. Distinguish what was directly seen from an explanation offered afterward. One instance establishes that a step occurs, not how often it occurs or why. Ask the worker to explain the step, compare additional cases or records, and check whether circumstances such as a system outage made the case unusual. Observation can itself change behavior, so allow for that when interpreting results. Document the underlying cause and consequence: duplicate entry may result from missing integration, inconsistent identifiers, or a deliberate control. Each cause implies a different response.

Worked example: During one return, an agent copies an address into a second system. The agent says the systems do not share return addresses. The analyst checks several further returns and asks other agents; the step appears in most routine cases, though guest returns differ. The finding records the duplicate work and its system handoff, while keeping the frequency claim tied to the checked cases.

Watch the distinction: One observed workaround should not be labeled universal. Nor should duplicate entry automatically be removed before checking whether it serves a validation or control purpose.

Reference: [1]

14. Compare documents with practice

Documents and system records are valuable starting evidence, but they may describe different times or levels of authority. Compare a written rule, configured system behavior, transaction records, and what workers report. Mark discrepancies explicitly: the policy may be outdated, the system may have an unauthorized exception, or the record may reflect a special case. Identify the rule owner and ask which version governs, then examine effective dates and approval history where available. Do not infer legitimacy from frequency alone; a widely used shortcut can still be contrary to an approved rule. Conversely, do not specify a future workflow from an old manual without testing its current use. The result should state the operative rule, its exceptions, the evidence supporting it, and any unresolved governance issue.

Worked example: A manual says supervisors approve every discount, but recent transactions show automatic approval for some smaller discounts. The analyst checks configuration history and asks the pricing-rule owner. The owner confirms a later approved rule introduced automatic approval under a configured limit. The future workflow reflects that rule, and the manual is flagged for correction rather than treated as current.

Watch the distinction: Assuming the manual is current can create unnecessary approval work. Assuming the software is authoritative can preserve an unauthorized configuration; verify ownership and effective date.

Reference: [1]

15. Confirm elicitation results

Elicitation produces observations and interpretations that must be checked with their sources. Send a concise record of statements, diagrams, examples, and open assumptions to participants who can detect errors. Ask them to verify precise terms, boundaries, exceptions, and who performs each action. Confirmation establishes that the elicitation result accurately captures their meaning; it does not necessarily approve a proposed future requirement. Track corrections and disagreements rather than silently merging them into a single statement. A model is particularly useful for confirmation because stakeholders can point to a missing path or mislabeled decision. Once the source confirms the record, take proposed requirements through the appropriate analysis and approval steps. This protects later design work from a plausible but wrong interpretation of a workshop phrase.

Worked example: A note says urgent claims bypass review. The analyst asks participants to define urgent and identify the review. They clarify that an urgent flag moves the claim to a priority queue; payment approval still occurs. The corrected result names the queue change and keeps the approval step. The participants confirm the description, while the future rule awaits its authorized owner.

Watch the distinction: Treating an unchecked note as an approved rule could remove a required decision. Confirmation of what someone said is also different from approval to change future behavior.

Reference: [1]

16. Communicate through conflict

Conflict often begins with different definitions rather than opposing goals. Show each stakeholder the precise term, population, time period, and calculation behind a disputed finding. Present the effect of each definition on the same underlying cases so the disagreement can be examined. Then ask what decision the measure must support: cash reconciliation may call for a payment date, while service response analysis may call for a request date. Record both views until an authorized owner selects a definition for the stated purpose. Communicate the chosen measure with its calculation and known limits, and preserve the unresolved issue if a decision is still pending. Clear communication does not require hiding differences; it makes their consequences visible enough for the right person to decide.

Worked example: Finance reports 90 refunds this month by payment date; operations reports 110 by request date. Reviewing the same records shows that 25 requests made this month remain unpaid, while five payments this month came from earlier requests: 110 − 25 + 5 = 90. For a payment-reconciliation report, the owner selects payment date and records the definition.

Watch the distinction: Choosing the larger or smaller figure as the 'correct' one ignores the question being answered. Both counts can be valid for different purposes.

Reference: [1]

Requirements life cycle management

17. Build useful traceability

Traceability connects a business need to the requirements that express it, the designs that implement those requirements, and the tests that check them. Build links at a useful level of detail, with a clear relationship type and current status. Forward tracing asks whether each need has coverage; backward tracing asks why a requirement or test exists. For a proposed change, follow links in both directions to find affected objectives, components, rules, and verification work. A link identifies what to examine, not the answer to the decision. Check whether a replacement control could preserve the original need, and whether any apparently unrelated requirement shares the same design element. Maintain the links as changes occur; stale traceability can mislead an impact assessment more than a small, accurate map.

Worked example: A team proposes removing address verification to shorten checkout. The requirement traces to a fraud-control need, a validation service, and two acceptance tests: one for a matching address and one for a mismatch. The analyst reviews fraud impact, the service dependency, and both tests. The links show what must change; the owner may still accept an alternative control.

Watch the distinction: A trace link does not make a requirement permanent. It reveals the consequences that must be assessed before removal, replacement, or retirement.

Reference: [1]

18. Maintain requirements over time

A requirement remains useful only if its wording and context reflect current understanding. Keep its owner, rationale, status, version, and related decisions alongside the statement. When evidence exposes ambiguity, identify the trigger, condition, expected response, and important exception before revising the wording. Compare the revision with dependent designs and tests, then route it through the agreed decision process if it changes an approved baseline. Preserve the prior version and reason for the change so reviewers can distinguish clarification from a new obligation. Do not let a working draft silently replace an approved requirement. Maintenance also includes closing obsolete questions and identifying requirements no longer needed. These practices let a later reader understand both the current instruction and how the team reached it.

Worked example: A pilot reveals that 'notify the customer immediately' says nothing about failed delivery. The analyst proposes a trigger of refund approval, a notification attempt after that event, and a defined retry or failure-handling path. The owner reviews timing and channel assumptions; linked tests are revised after approval. The earlier wording stays in version history with the pilot finding as the reason.

Watch the distinction: Changing a sentence in a shared file does not complete requirement maintenance. Reviewers need to know whether the change clarifies intent or alters an approved commitment.

Reference: [1]

19. Prioritize for value and dependency

Prioritization compares requirements using criteria agreed for the decision, such as expected value, risk reduction, urgency, cost, and effort. Separate importance from sequence. A high-value feature may depend on lower-visibility work that must be delivered first. Map prerequisite relationships before ranking a release; identify conflicts and scarce resources that could alter the order. A scoring method can make tradeoffs explicit, but scores are inputs to discussion rather than automatic instructions. Ask what happens if a requirement is delayed, what benefit can be realized independently, and what must be ready to measure that benefit. Revisit priorities when new evidence changes value or risk. Record why an enabling requirement precedes a more visible feature so stakeholders do not mistake the sequence for a rejection of their need.

Worked example: An analytics screen receives the highest value score, but the system does not capture the events it must display. The analyst maps event capture as a prerequisite, estimates its work, and schedules it first. A small initial report can test the data before the full screen is built. The screen remains high priority; its value cannot be realized until trustworthy events exist.

Watch the distinction: A ranked list that ignores dependencies can put a desired output before its input. High value does not make missing data appear or remove the need to validate it.

Reference: [1]

20. Assess a proposed change

Assess a proposed change by tracing the affected requirements, process steps, designs, measures, and stakeholders before seeking a decision. Define the intended benefit and the new cost or burden using comparable units and an explicit population. Examine whether the change creates a dependency, shifts authority, or undermines a target already agreed. Use observed data where possible, while stating uncertainty and any cases the data excludes. Compare alternatives, such as targeted review for higher-risk refunds, against applying the change to every case. Present the likely benefit, delivery impact, service impact, risks, and assumptions to the authorized decision maker. Record the outcome and update baselines and tests if approved. The analyst makes the tradeoff visible; the accountable owner accepts or rejects it.

Worked example: A second approval might reduce erroneous refunds. In a hypothetical pilot of 100 refunds, eight errors occurred, and a second check caught five. The check added one business day to all 100 cases. The analyst reports a potential reduction from eight to three observed errors, alongside 100 delayed cases, then tests whether targeting riskier refunds offers a better tradeoff before the owner decides.

Watch the distinction: Counting only the five caught errors overstates the case for universal review. The extra day affects every reviewed refund, and pilot results may not represent future volume or case mix.

Reference: [1]

21. Obtain meaningful approval

A stakeholder can confirm that elicitation results accurately describe what they said without approving a proposed requirement. Confirmation checks the evidence; approval authorizes a choice for future work. Before seeking approval, identify the decision being made, the requirement version, its rationale, affected parties, unresolved issues and the person with authority to decide. A subject expert may establish how a process works, while a sponsor or delegated owner decides whether a future rule meets the business need and accepts its tradeoffs. Record these actions separately so an accurate description of today's work cannot be mistaken for agreement to change it. If approval is conditional, capture the condition and who will verify it before treating the requirement as ready. The CBAP Handbook identifies requirements life cycle management as part of the examination scope.

Worked example: A claims specialist reviews a diagram and confirms that today's urgent claims enter a separate queue but still receive normal approval. Record that as confirmation of the current state. A proposed rule would let urgent claims bypass approval. Present its service benefit, control risk and exact wording to the sponsor who owns the outcome. Until that sponsor decides, mark the future rule proposed, not approved.

Watch the distinction: A signature on workshop notes proves only what the signer agreed to confirm. Check the stated purpose and decision authority before recording it as requirement approval.

Reference: [1]

22. Control baselines and versions

A baseline is an identified, agreed collection of requirement versions used as the reference for delivery and change decisions. It need not freeze learning; it makes later differences visible. Give each requirement a stable identifier, record its version and status, and identify which baseline a release implements. When a new version appears, compare its rule, rationale and acceptance criteria with the baseline. Trace the changed elements to designs, tests, interfaces, training and stakeholders, then estimate consequences before the authorized decision maker accepts or rejects the change for that release. A later version can remain proposed while the earlier version stays in force. This distinction prevents two teams from believing different rules govern the same release. Keep the decision and effective release with the version history so future analysts can reconstruct what was agreed.

Worked example: Release A uses refund rule version 2, which requires a verified payment reference. After development starts, version 3 adds a proposed approval threshold. Compare the versions and identify changes to the workflow, test cases and agent instructions. If the owner approves version 3 for Release B, Release A still implements version 2. Record both release assignments explicitly.

Watch the distinction: The newest document is not automatically the approved release rule. A version number shows sequence; the baseline and change decision show what delivery must implement.

Reference: [1]

23. Reuse with context

Reuse starts with the purpose of an existing requirement, then tests whether its assumptions still hold. Examine the original business need, users, data definitions, rules, interfaces and acceptance evidence. Some elements may transfer unchanged, while others depend on a region, product, process or former system. Trace any adapted wording to the shared need and document why local conditions differ. This is especially useful when a common requirement expresses an invariant, such as collecting a usable delivery address, but a detailed validation pattern varies. Ask the receiving stakeholders to check the adapted rule against real examples, including exceptions. Reuse saves analysis effort only if it reduces uncertainty without importing a false constraint. Where the original rationale is unknown, treat the requirement as a candidate to investigate, not as an established standard.

Worked example: Region A's address rule requires a five-digit postal code. Region B uses letters and digits in a different pattern. Both regions need an address that carriers can use, so reuse that purpose. Test Region B's actual address data and define its own format and exception handling. Copying the five-digit check would reject valid Region B orders.

Watch the distinction: A requirement that worked elsewhere is not automatically portable. Its wording may contain local data assumptions that are invisible until realistic cases are tested.

Reference: [1]

24. Analyze requirement dependencies

Dependencies explain why requirements must be assessed together. A prerequisite means one capability must exist before another can work. A conflict means two requirements cannot both be satisfied as written under the same conditions. A related requirement shares an object, rule or outcome but may have no strict sequence. Label the relationship and the reason, rather than drawing an unexplained line in a traceability tool. Then check what changes if either requirement is delayed, altered or removed. Prerequisites guide sequencing; conflicts call for a decision or a design that resolves the competing needs; ordinary relationships prompt coordinated review. Distinguish business necessity from a dependency created by a chosen design, since another design might remove it. Scenario practice in CBAP practice questions can help test these distinctions.

Worked example: Automatic refunds require a verified payment reference, making verification a prerequisite. A proposed rule to delete every payment record immediately after settlement conflicts with the need to check that reference during later returns. Ask how long verification is needed and whether a protected reference can be retained. Then revise the deletion or refund design and test both outcomes.

Watch the distinction: Two requirements touching payment data are not necessarily in conflict. Show the exact condition under which satisfying one would prevent the other from working.

Reference: [1]

25. Retire requirements deliberately

Retirement is a controlled decision that a requirement no longer applies to a defined scope or release. First establish why it has become obsolete: the need disappeared, another capability meets it, or the chosen strategy changed. Trace the requirement to its business need, design, tests, reports, procedures and dependent requirements. Confirm that removing it will not leave an unmet obligation or an unexplained gap for another stakeholder. Record the authorized decision, effective release and replacement relationship, if any. Mark the old requirement retired rather than deleting its history, because previous releases and decisions may still need explanation. Update linked acceptance criteria and tests so teams do not validate a behavior that should no longer exist. A requirement may be retired in a new release while remaining valid for support of an earlier one.

Worked example: A manual export sends daily recipient data to a partner. An approved integration now delivers the same fields at the needed time. Compare sample outputs, confirm the partner accepts the integration and check whether any exception still needs the export. If none does, retire the export requirement for the integration release and update its linked tests and operating instructions.

Watch the distinction: Removing a feature from a plan does not complete retirement. Its tests, procedures and dependent requirements may still direct teams to deliver the old behavior.

Reference: [1]

Strategy Analysis

26. Define the business need

State a business need as a problem or opportunity and the outcome that would show improvement. A requested product is a possible response, so investigate what triggers the request, who is affected, how often the problem occurs and what result matters. Separate symptoms, such as a long queue, from the desired result, such as timely resolution of routine inquiries. Define a measure and population before comparing options; otherwise each option may appear successful by a different standard. Constraints such as available staff or required access matter, but avoid embedding an untested design in the need statement. This framing allows a business analyst to compare changes to process, information, staffing and technology. If evidence later changes the diagnosis, the outcome statement can be refined without treating a favored feature as the objective itself.

Worked example: A director asks for a chatbot because routine inquiries wait too long. The team defines the need as resolving those inquiries sooner and measures elapsed time from receipt to answer. It compares a chatbot, clearer self-service content and revised staffing against the same measure, expected demand and service constraints. The chatbot remains an option until evidence shows its contribution.

Watch the distinction: Writing 'implement a chatbot' as the business need hides the actual service problem. It also prevents a fair comparison with options that may meet the outcome.

Reference: [1]

27. Assess the current state

A current-state assessment describes how work actually proceeds across people, process, information and technology. Start with the outcome and scope, then map the stages, decisions, queues, handoffs and systems that contribute to it. Use records to quantify delays or errors, and observations and interviews to explain what the records omit. Distinguish active processing time from waiting time; they suggest different remedies. Record variation by case type, location or period so an average does not conceal an exceptional group. Also identify existing capabilities worth preserving and constraints the future state must respect. Check findings with the people who perform and govern the work. The result should explain where performance is lost and what evidence supports that conclusion, giving later option analysis a defensible starting point.

Worked example: Return records show an average six-day cycle. Process mapping finds four days waiting for inspection, one day for inspection and one day for refund processing. The stages sum to six days. Payment software can affect at most the final one-day stage in this simplified model, so investigate inspection capacity and queue rules before making it the main investment.

Watch the distinction: A six-day average does not prove every return follows the same path. Check case mix and the distribution of wait times before treating one process map as universal.

Reference: [1]

28. Find a cause worth addressing

Root cause analysis asks what condition produces a recurring problem and what evidence would distinguish that explanation from alternatives. Define the symptom precisely, segment cases and trace the process backward from failure. Techniques such as a cause-and-effect diagram or repeated why questions can generate hypotheses, but counts, observations and rule checks are needed to test them. Separate a proximal cause, such as a missing field, from the upstream reason it is missing, such as an optional form field or a handoff that drops data. Prioritize causes by frequency, consequence and ability to intervene. Watch for overlapping categories and unrepresentative samples. A useful conclusion names a changeable mechanism and predicts what should improve if it is addressed; later measurement tests whether that prediction was right.

Worked example: In a sample of 80 invoices, 40 need correction: 28 lack purchase-order data and 12 have price mismatches. The correction rate is 40/80 = 50%; missing data explains 28/40 = 70% of observed corrections. Inspect the intake form and handoff for that field first. Confirm the sample covers typical suppliers and periods before projecting the 70% share across all invoices.

Watch the distinction: The largest error category is a lead, not a proven root cause. Find why its errors arise and check whether the sample reflects normal operations.

Reference: [1]

29. Describe the future state

A future state defines the outcome the organization wants and the capabilities and operating conditions required to sustain it. Describe who must act, what information they need, what decisions they must make and how success will be measured. Include governance and control needs, such as explainable decisions and an audit trail, when they are material to the outcome. Keep the description independent of a particular screen or system until options are evaluated. This leaves room for process changes, integrations or new tools that deliver the same capability. Compare the future state with the current state to identify gaps, then test whether proposed capabilities are necessary and sufficient. An attractive future-state picture is incomplete if it omits exception handling, ownership or the conditions under which the outcome can be achieved.

Worked example: The target is to decide eligible service requests during the customer's contact and explain each decision. Agents therefore need current eligibility information, usable decision rules and a record of the reason given. Those capabilities could come from one platform or connected systems. Measure the share of eligible requests decided during contact and review exceptions before selecting an architecture.

Watch the distinction: A future state is not simply a drawing of a proposed application. It must specify the operating result and the capabilities needed to achieve it.

Reference: [1]

30. Map capability gaps

A capability gap is the difference between what the enterprise can reliably do now and what the desired state requires. Compare the two states across people, process, information and technology, and state the gap as a missing or insufficient ability. Then look for dependencies: timely decisions may need trustworthy source data, a way to access it, an authorized decision role and a workable procedure. A gap is useful when it points toward a class of change without prematurely selecting a product. Identify evidence for current performance and conditions for the future capability. Rank gaps by their effect on the outcome and by prerequisites, since improving a downstream interface may add little value while upstream data remain stale. Recheck gaps after pilots; some apparent training problems are caused by unavailable information or unclear authority.

Worked example: Agents must decide eligibility during a customer call, but their file refreshes only overnight. Training can improve interpretation of the file but cannot supply changes made that morning. The primary information gap is current, trusted eligibility data. Assess a live lookup or more frequent feed, plus source reliability and access controls, before revising agent training.

Watch the distinction: Labeling every delay a technology gap can misdirect investment. Identify the exact missing capability and test whether data, authority or process causes the delay.

Reference: [1]

31. Assess strategic risk

Strategic risk concerns uncertainty that could change the outcome of a proposed change path. For each material event, identify its cause, plausible likelihood, consequence, timing and owner. A risk register is most useful when it connects those facts to a response and a trigger for action. Compare options on the same assumptions: a faster launch may increase supplier dependency, while a staged launch may reduce exposure but defer benefits. Where credible numbers exist, expected loss can aid comparison by multiplying probability and impact, but it does not replace judgment about severe outcomes or correlated events. Choose whether to avoid, reduce, transfer or accept the exposure within the organization's decision authority. Revisit risks as evidence changes, especially at dependency milestones. Stating 'integration risk' alone is too vague to guide a response.

Worked example: A supplier promises launch before peak season, but its interface may arrive late. Estimate the affected peak-season volume, identify the latest safe integration date and assign an owner to monitor delivery. Compare a staged release that excludes the interface with a temporary manual fallback. Choose a trigger, such as missing a tested milestone, for activating the fallback.

Watch the distinction: A low probability does not make a risk negligible when its consequence is severe. Examine exposure, timing and available responses before accepting it.

Reference: [1]

32. Choose a change strategy

A change strategy explains how an enterprise will move from its current state to the intended future state. Sequence changes by prerequisites, value, risk and readiness. Identify what must be decided before deployment, what can be piloted, who needs training and what evidence will justify expansion. A pilot can test workflow and adoption under controlled conditions, but only if it includes representative cases and clear measures. Include transition work such as migration, temporary procedures, communication and support; the eventual solution may function correctly while the organization is unprepared to use it. Define decision points and rollback or adjustment options for material uncertainty. This creates an actionable path rather than a list of features. Reassess the sequence when new evidence changes a dependency or the cost of delay.

Worked example: A new claims process requires revised approval authority and trained staff. First approve who may decide each exception, then train one team and pilot the workflow. Measure decision errors and time to resolution against the current process. Expand only after the results meet the agreed criteria; deploying the software before authority is settled would leave staff unable to complete cases.

Watch the distinction: A software release date is not a complete change strategy. People, decision rights and transition procedures may be prerequisites for the expected benefit.

Reference: [1]

33. Compare solution paths

Compare solution paths against one defined outcome, time horizon and set of constraints. Include all relevant costs, expected benefits, implementation effort, operating effects and material risks for each option. State assumptions separately so decision makers can challenge them. A simple undiscounted total can screen options over a short hypothetical horizon, while longer or differently timed cash flows may need discounting and sensitivity analysis. Check whether options deliver equivalent service; the cheaper option may lack capacity, quality or flexibility. Identify a break-even benefit difference rather than presenting cost as the whole decision. Also compare reversibility and dependency risk when estimates are uncertain. Keep the recommendation tied to the sponsor's priorities and explain what change in an assumption would reverse it.

Worked example: A manual triage team costs a hypothetical $90,000 yearly, or $180,000 over two years. Automation costs $150,000 initially plus $30,000 yearly, or $210,000. Automation is $30,000 dearer before discounting. If service outcomes are otherwise equal, it needs at least $30,000 of additional two-year benefit to break even; higher delivery risk would require further justification.

Watch the distinction: A two-year cost comparison is not a complete business case. Check service equivalence, benefit timing and risks before treating the lower total as the winner.

Reference: [1]

34. Make the business case testable

A testable business case links a proposed change to measurable benefits, full costs and explicit assumptions. Define the baseline, target, population, measurement period and owner of each benefit. Distinguish a reduction in work from cash savings: released staff time has value only if it can be redeployed, avoid new hiring or reduce expenditure as assumed. Include implementation, transition and recurring costs, along with risks that could delay benefits. Show how results will be checked after launch and which decision would follow a shortfall. For financial measures, keep units and timing consistent; the certified management accountant CMA guide provides related study on cost and benefit reasoning. A range or sensitivity check is more informative than one precise forecast when adoption or volumes are uncertain.

Worked example: A proposal predicts 2,000 fewer manual reviews per year at a hypothetical $12 of staff time each: 2,000 × $12 = $24,000 in annual capacity. If implementation costs $30,000 and annual support costs $4,000, first-year net capacity value is $24,000 − $30,000 − $4,000 = −$10,000. Track review counts and confirm whether released time is actually redeployed.

Watch the distinction: Multiplying avoided tasks by labor cost does not automatically prove cash savings. State how the released capacity will be used and measure whether it appears.

Reference: [1]

Requirements analysis and design definition

35. Classify requirement types

Requirement types describe different levels of need and change. A business requirement states the enterprise outcome or objective. A stakeholder requirement describes what a particular group needs to achieve that outcome. A solution requirement specifies behavior or qualities the solution must provide; functional behavior and quality conditions belong here. A transition requirement enables movement from the current state to the future state and may cease to apply after migration. Trace downward to ask whether each detailed requirement supports a higher need, and upward to ask whether a need has enough support. Classification helps expose gaps and prevents a temporary migration task from being treated as permanent system behavior. It also keeps a proposed interface feature from replacing the business objective. The same statement may need rewriting if it mixes an outcome, feature and implementation step.

Worked example: For faster claims resolution, 'resolve routine claims sooner' expresses the business outcome. Agents' need to see current claim status is a stakeholder requirement. Displaying the latest status with its update time is a solution requirement. Importing open claims before launch is a transition requirement. Trace the display rule to the agents' need and measure whether it improves resolution.

Watch the distinction: Calling every requested feature a business requirement loses the link to the outcome. Ask whose need it serves and at what level it specifies behavior.

Reference: [1]

36. Specify observable behavior

A functional requirement is easier to implement and test when it states a trigger, relevant conditions, the required response and meaningful exceptions. Name the business object and define comparison terms precisely. For duplicate prevention, clarify whether the match uses customer identity, an external reference, order status or a time window. Describe what the system displays, whether it creates a record and how an authorized user handles a legitimate repeat. Avoid hiding a policy decision inside a vague verb such as 'handle.' Use examples or a decision table if several conditions interact. Check that the response is observable at the interface or through records, and that error paths do not silently violate the rule. The result should support both development and acceptance testing without dictating unnecessary screen details.

Worked example: On order submission, if an existing order has the same customer ID and external reference, the system shows that order and creates no new one. If the customer legitimately needs a repeat, the user must enter a new reference, which still passes ordinary validation. Test an exact match, a different customer's matching reference and a valid new reference for the same customer.

Watch the distinction: 'Prevent duplicates' leaves the match and response undefined. Teams may block legitimate orders or create unwanted ones while believing they met the same statement.

Reference: [1]

37. Define quality requirements

A quality requirement describes how well a solution must operate under stated conditions. Turn words such as fast, available or usable into a measure, workload, population and observation point. For response time, specify when timing starts and ends, the search data volume and concurrent demand. A percentile describes the experience of a chosen share of requests; an average can conceal slow cases. Include the environment and measurement method so a test result is interpretable. Choose a target based on business use and evidence, rather than presenting a hypothetical number as a universal standard. Also check tradeoffs: faster results may require indexing, caching or narrower queries that affect freshness or completeness. Link the quality condition to the stakeholder task it supports and include any critical exception that must still work.

Worked example: For a hypothetical service, require the first search results within two seconds for 95% of searches at an agreed workload. In a test of 200 searches, at least 190 must meet two seconds because 200 × 0.95 = 190; up to 10 may exceed it. Record data volume and concurrency, then inspect the slow cases for a business-critical pattern.

Watch the distinction: 'Search must be fast' cannot be tested consistently. Even a numeric target is incomplete without the workload, timing points and share of searches covered.

Reference: [1]

38. Separate need from design

Stakeholders often describe a familiar design when explaining a need. Ask what decision or task the requested feature supports, who uses it, which information is required and what constraints apply. Then express the underlying capability separately from candidate designs. This preserves the stakeholder's evidence while allowing alternatives to be compared. A spreadsheet export may support flexible comparison, but it may also expose sensitive data or create stale copies; an in-app view might control access but offer less flexibility. Evaluate options against the same task, frequency, data freshness, auditability and cost. If a design choice is mandatory because of a genuine external constraint, record the constraint and its source. The aim is to avoid committing to a mechanism before confirming that it best meets the need.

Worked example: A supervisor asks for a spreadsheet export to compare regional exceptions. The need is to identify differences by region and period. Compare an in-app filtered view, a controlled export and a scheduled report using freshness, access and analysis flexibility. If only a few authorized supervisors need ad hoc comparisons, a controlled view may satisfy the task without circulating sensitive files.

Watch the distinction: Rejecting a requested design outright can discard useful context. Keep it as an option while verifying the task and constraints it was meant to address.

Reference: [1]

39. Model process handoffs

A process model shows how work moves among roles, activities, decisions and handoffs. Mark the start and end states, then follow both successful and unsuccessful paths. Decision points should have defined conditions and outcomes; each handoff should name who receives the work and what information travels with it. Look for loops, queues, duplicate entry and paths with no resolution. A missing branch can reveal an unstated requirement, while repeated rework may show a rule or data quality problem. Validate the model with people who perform the work and with records where possible, because documented procedures may omit workarounds. Keep the model at the level needed for the question: a broad view locates bottlenecks, while a detailed view tests exception behavior. Update linked requirements when the model changes.

Worked example: Map a return as request, eligibility check, inspection and refund. The model sends passed inspections to refund but has no path for failed inspections. Ask the policy owner what should happen, then add rejection notification and an appeal route if approved. Assign the notification to customer support and record the information it must include. Test a failed case end to end.

Watch the distinction: A tidy main path does not prove the process is complete. Follow every decision outcome until it reaches a defined next step or end state.

Reference: [1]

40. Model business data

A business data model defines the things the enterprise cares about, their meanings and how they relate. Identify entities such as Customer and Order, then specify relationship cardinality and relevant business rules before choosing database fields. Distinguish an entity from a label: 'customer' may mean an account holder, purchaser, recipient or guest, and each meaning produces different counts and controls. Check optional relationships, identity rules and lifecycle events. A conceptual model helps stakeholders agree on meaning; a logical model can add attributes and identifiers for implementation analysis. Use real examples to test edge cases such as merged accounts, canceled orders and guest checkout. When systems exchange data, shared definitions prevent one team's 'customer count' from disagreeing with another's for reasons hidden in mapping logic.

Worked example: One customer may place many orders, and each order belongs to one customer in the proposed model. A guest checkout raises a question: must it create a customer record? If yes, define a guest identifier and later account linking; if no, revise the relationship so an order can have no registered customer. Decide before teams build incompatible counts and integrations.

Watch the distinction: A one-to-many line is not enough when 'customer' has multiple meanings. Define identity and optional cases before relying on the relationship for reports or interfaces.

Reference: [1]

41. Use cases and alternate flows

A use case describes how an actor achieves a business goal through interactions with a solution. Start with the trigger and preconditions, then follow the normal path to a clear outcome. Add alternate flows where a condition changes the path, and exception flows where the goal cannot be completed. State what the actor and solution do, including decisions and resulting information, without prescribing a sequence of screens. This keeps the model useful when the interface changes. Check each alternate path for a defined end state: completed, saved for later, or stopped with an explanation. A business analyst can use the flows to elicit missing rules, connect requirements to the actor's need, and identify acceptance tests. The CBAP Handbook identifies requirements analysis and design definition as an examination knowledge area.

Worked example: An employee submits an expense claim. In the normal flow, the solution checks the entered amount and receipt, records the claim, and confirms submission. If the receipt is missing, it saves a draft, tells the employee what evidence is needed, and leaves the claim unsubmitted. The analyst confirms whether a draft may later expire; the alternate flow cannot imply approval.

Watch the distinction: A use case is not a click-by-click screen tour. If it names buttons but omits the actor's goal, business decisions, and exception outcomes, it will miss important requirements.

Reference: [1]

42. Test rules with decision tables

A decision table makes a rule inspectable by placing conditions in rows and possible combinations in columns, with an action for each column. For two independent yes-or-no conditions, start with four combinations; three conditions produce eight before any combinations are shown to be impossible or equivalent. Use business definitions for each condition, since words such as “returned” may refer to a request date or the date goods arrive. Examine every column for a missing action, conflicting actions, and exceptions that need separate authority. A table is especially useful when prose contains several “and,” “or,” and “unless” clauses. After confirming the rules with their owner, turn the columns into test cases. A blank cell can mean an unresolved rule, so do not silently treat it as permission to proceed.

Worked example: Assume a hypothetical policy makes a refund eligible only when an item is returned within 30 days and is undamaged. The four combinations are yes/yes, yes/no, no/yes, and no/no. Only yes/yes yields eligibility. Each of the other three needs rejection or a separately defined exception route. The analyst must also define how the 30 days are counted.

Watch the distinction: Testing one eligible case does not establish that the rule is complete. The remaining condition combinations may reveal an undefined rejection, an unauthorized exception, or contradictory actions.

Reference: [1]

43. Model states and transitions

A state model describes the status of a business object and the events that permit it to change status. Name states that matter to business decisions, then define each transition's trigger, conditions, responsible actor, and result. Ask what actions are permitted while the object stays in each state. This exposes gaps that a process diagram may conceal, especially when work is paused, reopened, or cancelled. Distinguish a status label from an event: “Approved” is a state, while “approve application” is an action that may cause a transition. Review forbidden transitions as carefully as allowed ones. If an approved record can be edited, the model must explain whether approval remains valid, is revoked, or requires a fresh decision. Those outcomes affect audit history, notifications, and tests.

Worked example: An application starts in Draft. Submission moves it to Submitted; an authorized decision moves it to Approved or Rejected. A user asks to edit an Approved application. The analyst proposes a controlled reopen event that records the reason and returns it to Draft or another defined review state. Direct editing would leave the approval attached to content the approver never saw.

Watch the distinction: A list of statuses is not a complete state model. Without transition conditions and allowed actions, developers may permit edits or approvals that bypass the intended decision.

Reference: [1]

44. Prototype to resolve uncertainty

A prototype provides a concrete representation that people can react to when words leave workflow or meaning uncertain. Choose its fidelity to match the question: a rough sketch can test task order, while an interactive model can expose navigation and handoff problems. Give participants realistic tasks and observe where they hesitate, rather than asking only whether they like the appearance. Record findings as hypotheses or candidate requirements until the relevant rule owner confirms them. Visual feedback about a label is different from authority to change the underlying business definition. A prototype can also hide cases that are absent from its sample data, so test meaningful exceptions. Keep its status explicit when discussing it with designers and stakeholders; an attractive mockup can otherwise be mistaken for an approved specification.

Worked example: Agents testing a claim prototype cannot tell whether “paid” means a transfer was authorized or the funds settled. The analyst observes two agents make different decisions from the same label. The payment owner confirms the two statuses are distinct. The prototype then uses separate labels and shows the settlement status before agents test the revised workflow.

Watch the distinction: Positive feedback on a screen does not approve its business rules. Participants may like the layout while interpreting its statuses differently or overlooking an important exception.

Reference: [1]

45. Set acceptance criteria

Acceptance criteria translate a requirement into observable conditions for deciding whether a delivered behavior satisfies it. Begin with the trigger, relevant data and preconditions, expected response, and a meaningful exception. State outcomes from a business perspective, including what must not happen. Criteria should be specific enough that independent reviewers reach the same result, yet avoid prescribing internal code where several designs could work. Trace each criterion to the requirement and check that the set covers its important boundaries. For numeric limits, say which unit, measurement point, and workload apply; otherwise a passing test may prove little. Acceptance criteria support a decision about the delivered solution, while test cases supply particular inputs and steps to exercise those criteria. CBAP practice questions can help you rehearse that distinction in scenarios.

Worked example: For duplicate orders, assume customer C has order 417 with external reference R8. Reusing C and R8 must display order 417 and create no new order. Using C with a different reference, R9, may create a new order if other validation passes. These cases test both duplicate prevention and the boundary that allows a legitimate second order.

Watch the distinction: “Duplicate prevention works” is too vague to accept. It does not identify the matching fields, the expected response, or how a legitimate repeat purchase is treated.

Reference: [1]

46. Verify requirement quality

Verification asks whether a requirement is written well enough to be implemented and tested consistently. Check clarity, completeness, internal consistency, feasibility, and whether its result can be observed. Also compare it with related requirements: two individually clear statements can conflict when applied to the same case. Ask what event starts a timing requirement, whose clock is used, and what exceptions change the outcome. Resolve ambiguity with the appropriate stakeholders, then update the requirement and its linked criteria together. Verification precedes a different question, validation: whether the requirement helps meet the business need. A perfectly measurable requirement can still be unnecessary. Reviewers should record the specific defect and proposed correction so the author can revise it; a general mark of “unclear” gives little direction.

Worked example: One refund requirement says “pay immediately”; another requires a next-day review before payment. The analyst asks whether “immediately” starts after request, eligibility confirmation, or approval. The owner decides payment begins after approval and defines a measurable target for that interval. Both statements and their tests are revised; the original pair could not be accepted together.

Watch the distinction: A requirement is not verified merely because it has an owner or an approval signature. Contradictory timing and undefined terms can survive approval and cause incompatible implementations.

Reference: [1]

47. Validate against the need

Validation tests a proposed requirement against the underlying business need and expected outcome. Trace the requirement to the stakeholder goal, then ask how its use would change the measure that matters. Examine assumptions about users, frequency, timing, and alternative ways to achieve the same result. This is a decision about relevance and value, not simply wording quality. A requirement may be clear and feasible yet consume effort without improving the target outcome. Conversely, a useful capability may need further verification before it is buildable. When challenging a proposal, preserve the reason someone requested it and test that reason with evidence. If the benefit lies outside the current outcome, make that separate value claim visible so decision makers can weigh it rather than burying it in the original scope.

Worked example: The business wants today's unassigned tickets routed faster. A proposed dashboard lists every historical ticket, which may help later reporting but gives dispatchers no clear next action. The analyst compares it with a live unassigned queue showing age and owner options. The latter connects directly to the routing goal, so it receives priority while the history need is assessed separately.

Watch the distinction: A requirement does not become valuable just because stakeholders requested it. Ask which outcome it changes and whether another capability would address that outcome more directly.

Reference: [1]

48. Structure requirements architecture

Requirements architecture organizes requirements so their relationships remain visible across capabilities and releases. Group items under business capabilities, then connect shared rules, data, interfaces, decisions, and tests across those groups. A hierarchy helps navigation, but cross-links are necessary when one rule affects several paths. Record whether a link means “depends on,” “constrains,” or “implements”; an unlabeled connection is hard to use for impact analysis. Apply a release boundary to show what must work together and what can follow later. Review the architecture for orphan requirements with no justified need and for capabilities lacking supporting behavior. When a shared rule changes, follow its links to identify affected stakeholders, designs, and tests before deciding on the change. The structure should aid decisions, rather than merely mirror a document's headings.

Worked example: A claims decision capability contains identity verification, eligibility decision, and notification. A shared consent rule constrains both verification and notification, so the analyst links it to each path. If consent wording changes, the links identify two affected functions and their tests. The release plan must include both changes if they are needed for consistent handling of claims.

Watch the distinction: Putting every requirement in one folder under a capability does not show dependencies. Shared rules need explicit links, or a change can appear local while affecting several functions.

Reference: [1]

49. Define design options

Design options are materially different ways to satisfy the same validated requirements. Hold the required outcome and constraints constant before comparing approaches; otherwise a cheaper option may simply deliver less. For each option, describe its operating model, major dependencies, assumptions, and consequences for users. A live integration and a local copy can both display customer status, but they differ in availability, data age, recovery, security, and maintenance. Identify assumptions that could reverse a recommendation and test those first. A business analyst need not select detailed technical components alone; the analyst makes the tradeoffs and business consequences explicit for the people making the decision. Use evidence such as source availability or acceptable delay to narrow the choices before estimating costs. Keep the requirement distinct from the design selected to meet it.

Worked example: Agents need current customer status. Option A queries the source during each interaction, assuming it remains available at the needed times. Option B reads a local copy refreshed periodically, assuming agents can tolerate its age. The analyst asks the service owner to define acceptable staleness and the technical team to assess outage behavior. Those answers determine which option can meet the same need.

Watch the distinction: Calling one design “the requirement” hides alternatives. If the requirement is current status, a live interface is only one possible means and carries its own assumptions.

Reference: [1]

50. Analyze option tradeoffs

A weighted comparison makes tradeoffs visible by scoring every option against the same criteria and multiplying each score by the criterion's agreed weight. Define what high and low scores mean before scoring; cost and speed might otherwise be interpreted in opposite directions. Weights should total 100%, and the resulting number is a discussion aid, not a decision rule. Check mandatory constraints separately: an option that fails a required control cannot be rescued by a high total. Then perform sensitivity analysis by changing uncertain weights or scores to see when the ranking reverses. Document the evidence behind scores and who accepted the weights. Small score gaps deserve particular scrutiny because rough estimates can overwhelm the apparent difference. Finally, explain the business consequence in ordinary terms, including risks the score cannot represent well.

Worked example: On a hypothetical five-point scale where higher is better, A scores 5 for speed and 2 for cost; B scores 3 and 4. At 60% speed and 40% cost, A is 5 × 0.60 + 2 × 0.40 = 3.8. B is 3 × 0.60 + 4 × 0.40 = 3.4. A leads only under these weights and assumptions.

Watch the distinction: The highest weighted score is not automatically the recommendation. Invalid weights, uncertain scores, or failure of a mandatory constraint can make the ranking misleading.

Reference: [1]

51. Allocate requirements

Allocation assigns each required behavior to a person, process, system, or interface that can perform it. Begin with the end-to-end outcome, then separate detection, decision, action, and recordkeeping. Specify who or what owns each step, what information crosses the handoff, and what happens if the recipient is unavailable. This reveals gaps that a broad statement such as “resolve alerts” can conceal. A system may identify a pattern, while a person applies judgment and an authorized role approves a consequential action. Check that the allocated responsibilities match actual authority and capacity. Trace the allocation back to the requirement so a design change does not silently remove a business obligation. Test the handoffs with a normal case and at least one delayed or disputed case, since work often fails between components.

Worked example: Software flags a suspicious payment and records the reason. An analyst reviews the alert with supporting transactions and recommends release or escalation. A supervisor decides escalated cases and records the outcome. The analyst specifies notification and timing between these roles, including what happens when the supervisor is unavailable. Assigning the entire task to software would omit the authorized judgment.

Watch the distinction: A requirement is not fully allocated when its first automated step has an owner. Human decisions, information handoffs, and failure paths also need explicit responsibility.

Reference: [1]

52. Recommend a solution for value

A solution recommendation connects expected benefits to costs, risks, constraints, and the evidence behind them. State the comparison period and whether figures are cash savings, capacity released, revenue, or another kind of value; these are not interchangeable. Compare viable options on a consistent basis and test assumptions that have the greatest effect on the result. A simple undiscounted net benefit is total expected benefit minus total cost, but it omits timing, uncertainty, and implementation disruption. Confirm that the proposed option can satisfy mandatory requirements and that affected stakeholders can operate it. Present the recommendation with conditions that would cause reconsideration, such as an unproven adoption rate. Approval belongs to the authorized decision maker; the analyst's role is to make the reasoning and alternatives inspectable.

Worked example: Assume an option costs $80,000 once and yields $55,000 in benefit each year for two years. Undiscounted benefit is 2 × $55,000 = $110,000; net benefit is $110,000 − $80,000 = $30,000. The analyst recommends it only after checking delivery risk, whether benefits can be realized, and how competing options perform over the same two years.

Watch the distinction: A positive net benefit alone does not settle the choice. Benefits may depend on adoption, costs may arrive earlier, and another feasible option may offer better value.

Reference: [1]

Solution Evaluation

53. Define solution measures

Solution measures should connect what the delivered solution does to the business outcome it was meant to improve. Use a small chain: adoption shows whether people use it, operational performance shows how well it works, and outcome measures show whether the need is met. Define each measure's population, start and end points, period, and data source before collecting results. A routing tool might increase automated assignments while sending more cases to the wrong team, so measure correctness and time as well as volume. Distinguish leading indicators, which can signal emerging problems, from final outcomes, which may take longer to appear. Review segments that could hide poor results in an overall average. Assign an owner to interpret measures and decide what evidence would trigger further analysis or action.

Worked example: For automated case routing, the analyst tracks 800 cases in a hypothetical month. If 600 are routed automatically, adoption is 600 ÷ 800 = 75%. The team also measures median time to the correct team. If that time rises from two to three hours, the high automation share does not demonstrate improved routing; misroutes need investigation.

Watch the distinction: Counting feature use is not the same as measuring success. Users can use a solution frequently while accuracy, speed, or the business outcome gets worse.

Reference: [1]

54. Compare results with targets

A performance gap is the difference between an observed result and a defined target, interpreted using the same measure and population. First verify the unit, period, case mix, and measurement points. For a time measure where lower is better, subtract the target from the observed value to show how far performance exceeds the limit; divide by the target for a relative gap. Avoid mixing a mean with a median or comparing routine cases with a later period containing harder cases. A gap identifies a problem for investigation, not its cause. Break results down by relevant segments and examine adoption, process changes, and data quality before attributing the difference to the solution. Record whether the target itself still reflects the business need and whether meeting it would produce the intended value.

Worked example: Assume a hypothetical target median routing time of four hours and a post-launch median of six hours for comparable cases. The absolute gap is 6 − 4 = 2 hours. Relative to the target, 2 ÷ 4 = 50% above target. Before blaming the tool, the analyst checks whether the measured period included a different mix of cases or staffing levels.

Watch the distinction: A result above target proves a gap, not a cause. Changing the solution immediately may miss a shift in case mix, staffing, or measurement definitions.

Reference: [1]

55. Assess contribution to value

Observed improvement and solution contribution are different claims. Compare the outcome before and after implementation, then examine other changes that could explain it, such as staffing, demand, policy, or seasonal case mix. Look for a credible comparison group or staggered rollout where possible. Check whether people actually used the solution and whether greater use aligns with better results. No single comparison is perfect, so state what the evidence supports and where uncertainty remains. Distinguish gross improvement from net value after operating costs and unintended effects. If a new workflow reduces resolution time but requires substantial extra staffing, the benefit attributed to the workflow should be limited. The analyst helps decision makers avoid overstating benefits while still recognizing evidence of genuine contribution.

Worked example: Average resolution time falls from ten to eight days, an observed reduction of two days or 20% of the original ten days. During the same period, staffing increases. A comparable team without the workflow also improves by one day. That pattern suggests the workflow may contribute, but it does not justify crediting it with the entire two-day change.

Watch the distinction: A before-and-after difference is not proof of causation. Concurrent staffing or demand changes can account for some improvement even when the solution was deployed successfully.

Reference: [1]

56. Identify solution limitations

A solution limitation is a shortcoming in the delivered capability that restricts the intended result. Compare observed behavior with validated needs and the agreed solution scope, then locate the gap in functions, data, usability, interfaces, or performance. Confirm whether the supposedly missing capability was required; otherwise it may be a new need rather than a delivery defect. Measure the effect on the business outcome and identify which users and cases are affected. A workaround can show how staff cope, but it can also hide the true cost of the limitation. Consider a targeted enhancement, changed design, or accepted limitation based on expected value. When evaluating control-related gaps, the certified internal auditor guide offers a related perspective on evidence and control effectiveness.

Worked example: Agents use a new account search for returns, but it omits archived accounts. The analyst checks the agreed requirement and confirms archived accounts were included, then counts affected returns and the manual lookup time. The shortfall is in the solution's data coverage. Adding archived records or a suitable interface is evaluated against the time and risk it would remove.

Watch the distinction: Poor results do not always mean a solution defect. First verify what the solution was required to cover and whether the obstacle lies in delivered capability or organizational practice.

Reference: [1]

57. Identify enterprise limitations

An enterprise limitation arises from the organization's arrangements around a solution, even when the solution performs as specified. Authority, staffing, skills, incentives, policies, and upstream processes can all suppress value. Diagnose where work stops: if the screen presents the right information and supports the required action, but nobody on duty is authorized to decide, the constraint is organizational. Confirm this with transaction records, observation, and the people who handle exceptions. Compare possible responses such as delegated authority, changed coverage, training, or a revised process. A software change might assist those responses but cannot itself grant decision rights. Document the expected outcome and responsible owner so corrective work can be evaluated later. Separating enterprise from solution limitations prevents effort being spent on the wrong part of the system.

Worked example: An evening approval screen displays all required evidence and records decisions correctly. Yet requests wait until morning because no evening supervisor has delegated authority. The analyst checks queue timestamps and the authority schedule, then presents coverage or delegation options. A faster screen cannot shorten the wait while the approval role remains vacant.

Watch the distinction: When users cannot finish work, the interface is an easy target. If the real constraint is authority or staffing, redesigning the screen may leave the delay untouched.

Reference: [1]

58. Recommend corrective action

Corrective action begins with evidence about why expected value is missing. Identify the limiting condition, its effect, and the feasible responses: change the solution, change the surrounding operation, accept the shortfall, or retire an option that no longer pays off. Compare responses against the same operational need and include implementation cost, ongoing effort, risk, and likely uptake. Avoid selecting the cheapest visible fix if it cannot work in the real environment. Pilot uncertain responses where a small test can reveal usage or performance. Specify an owner and a measure that will show whether the correction worked. If acceptance of a limitation is recommended, state the residual consequence and who has authority to accept it. A recommendation should make the decision and its assumptions clear, not merely list possible fixes.

Worked example: Warehouse staff rarely use a feature because terminals are distant. Mobile access would cost a hypothetical $20,000, a shared terminal $8,000, and a process change $3,000. Observation shows the process change would add delays, while one shared terminal is reachable during normal work. The analyst recommends piloting the terminal and measuring use before wider purchase.

Watch the distinction: The least expensive option on paper is not necessarily the best correction. It must be usable in the actual workflow and improve the measured outcome.

Reference: [1]

59. Reassess residual risk

Residual risk is the uncertainty that remains after a solution or control is operating. Evaluate it by the likelihood and consequence of remaining events, not by event count alone. Segment exceptions by severity and cause, then compare the remaining exposure with the organization's agreed tolerance and the cost of further action. Check whether the control creates new risks, such as false positives that block legitimate work. A percentage reduction can describe performance, but it cannot tell decision makers whether the most harmful cases are controlled. Identify who owns the residual risk and what monitoring would reveal deterioration. If risk is unacceptable, propose a targeted response and estimate its effect; if accepted, record the reason and review point. Avoid implying that any control eliminates uncertainty.

Worked example: Assume automated checks reduce exceptions from 100 to 20 per month. The count reduction is (100 − 20) ÷ 100 = 80%. Five remaining exceptions are high impact. The analyst reviews their causes and severity against the agreed tolerance. If they exceed it, targeted human review may be justified despite the strong overall count reduction.

Watch the distinction: An 80% reduction in exceptions does not mean risk fell by 80%. The remaining cases may be more severe, and their consequences drive the acceptance decision.

Reference: [1]

60. Track realized value

Realized value is assessed after deployment by comparing actual benefits and costs with the business case over a defined period. Preserve the original assumptions, including adoption, demand, and the ability to redeploy saved effort. Measure the same population and unit each time, then explain variances rather than immediately rewriting the forecast. Separate a temporary rollout effect from a persistent shortfall, and consider external changes that alter the baseline. Review whether released capacity became a genuine saving, additional service capacity, or simply unused time. Decide whether to improve adoption, adjust the process or solution, revise future expectations, or stop further investment. Benefit ownership should continue after project delivery because value depends on ongoing operations. A trend across periods is more informative than a single favorable or unfavorable result.

Worked example: A business case predicts 1,500 fewer manual reviews per quarter. Actual reductions are 900 and 1,100 in two comparable quarters. Their average is (900 + 1,100) ÷ 2 = 1,000 per quarter, 500 or one-third below the assumption. The analyst examines adoption and case mix before changing the forecast or funding another feature.

Watch the distinction: Delivering the solution does not prove the promised benefit was realized. Compare measured results with assumptions and check whether saved effort produced usable capacity or financial value.

Reference: [1]

Official references and further reading

CBAP Handbook

All study guides

Business analysis planning and monitoring

1. Choose an analysis approach

2. Set decision authority

3. Find the affected stakeholders

4. Plan stakeholder engagement

5. Manage analysis information

6. Estimate analysis work

7. Select techniques for the question

8. Measure analysis performance

9. Adjust the analysis plan

Elicitation and collaboration

10. Prepare an elicitation session

11. Probe beyond stated requests

12. Facilitate a decision workshop

13. Observe work as performed

14. Compare documents with practice

15. Confirm elicitation results

16. Communicate through conflict

Requirements life cycle management

17. Build useful traceability

18. Maintain requirements over time

19. Prioritize for value and dependency

20. Assess a proposed change

21. Obtain meaningful approval

22. Control baselines and versions

23. Reuse with context

24. Analyze requirement dependencies

25. Retire requirements deliberately

Strategy Analysis

26. Define the business need

27. Assess the current state

28. Find a cause worth addressing

29. Describe the future state

30. Map capability gaps

31. Assess strategic risk

32. Choose a change strategy

33. Compare solution paths

34. Make the business case testable

Requirements analysis and design definition

35. Classify requirement types

36. Specify observable behavior

37. Define quality requirements

38. Separate need from design

39. Model process handoffs

40. Model business data

41. Use cases and alternate flows

42. Test rules with decision tables

43. Model states and transitions

44. Prototype to resolve uncertainty

45. Set acceptance criteria

46. Verify requirement quality

47. Validate against the need

48. Structure requirements architecture

49. Define design options

50. Analyze option tradeoffs

51. Allocate requirements

52. Recommend a solution for value

Solution Evaluation

53. Define solution measures

54. Compare results with targets

55. Assess contribution to value

56. Identify solution limitations

57. Identify enterprise limitations

58. Recommend corrective action

59. Reassess residual risk

60. Track realized value

Official references and further reading

Frequently Asked Questions

Related Study Guides

Accredited Business Valuation (ABV)

Association of Chartered Certified Accountants Qualification (ACCA)

Certification in Distressed Business Valuation (CDBV)