CBAP key terms

The knowledge area that governs how business analysis work is organized: choosing approaches, planning stakeholder engagement, deciding governance, and planning how performance will be monitored and improved.

A documented decision on how analysis work will be performed on an initiative, covering deliverables, timing, methods, and level of formality, chosen to fit the change context and risk.

An analysis style that emphasizes early, comprehensive documentation and formal approval gates, suited to stable, regulated, or contract-bound environments where rework is expensive.

An analysis style that favors short cycles, lightweight documentation, and frequent stakeholder feedback, suited to evolving needs where learning happens through delivery rather than upfront specification.

A plan describing which stakeholders matter for the work, what each needs, and how, when, and by whom they will be involved, including escalation routes when agreement stalls.

A visual model placing stakeholders by influence, interest, attitude, or impact so the analyst can tailor communication and involvement strategies to each group.

A responsibility assignment grid naming who is Responsible for doing work, Accountable for the outcome, Consulted for input, and Informed of progress or decisions on each activity.

A review of how well analysis activities performed against the plan, identifying gaps, root causes, and corrective actions so later work benefits from the lessons.

The agreed rules for how requirements are identified, prioritized, approved, changed, and traced, including who holds decision authority when views conflict.

The planned drawing out of information from people and sources, using techniques such as interviews, workshops, observation, and document analysis, before that information is confirmed and organized.

A schedule of what information to gather, from which sources, by which techniques, in what sequence, and with what logistics, prepared before elicitation events begin.

Working jointly with stakeholders so information is shared, misunderstandings surface early, and decisions gain commitment rather than mere compliance.

Guiding a group session so participants reach a shared outcome: setting ground rules, managing airtime, resolving conflict, and recording decisions transparently.

A structured group event convened to elicit, elaborate, prioritize, or resolve requirements, valued for speed and for building shared understanding across functions.

Watching people perform real work in their own environment to capture tacit knowledge, workarounds, and context that interviews or documents may not reveal.

Validating that elicited information is accurate and complete with the sources who provided it, closing the loop before the information is treated as agreed requirements.

The knowledge area covering how requirements are traced, maintained, prioritized, assessed for change impact, and approved from creation through retirement.

Recording and following links between requirements and their origins, related requirements, designs, and test cases, so impact of change and coverage of scope can be assessed.

A defined process for logging, evaluating, deciding on, and communicating proposed changes to requirements or baselines, protecting agreed scope from unmanaged drift.

The formal or informal acceptance of requirements by those with authority, confirming that the stated need is understood, agreed, and fit to be used as a basis for further work.

Ranking requirements by value, risk, difficulty, or urgency so limited effort goes first to what matters most; approaches include ranking, grouping, and time-boxed allocation.

The knowledge area that examines the current state, defines a desired future state, assesses risks and change options, and produces a recommended direction for the enterprise.

Examining how the enterprise works today - processes, capabilities, systems, culture, and pain points - to establish a baseline against which change will be judged.

Describing the desired condition after change in terms of goals, capabilities, and value, giving the initiative a target to design and measure against.

Comparing current and future states to identify what capabilities, processes, or resources are missing, and therefore what the change must deliver.

The boundary of what a proposed solution will and will not change, used to keep expectations, design, and delivery effort aligned with the intended value.

The knowledge area that structures raw requirements, models and refines them, verifies quality, and identifies design options that satisfy the need.

Grouping requirements by type or level - such as business, stakeholder, solution, functional, or non-functional - so each is analyzed, documented, and verified appropriately.

Attributes used to judge a requirement, such as being clear, complete, consistent, feasible, testable, and unambiguous, applied during verification and review.

Checking that requirements are correctly written, internally consistent, and meet quality standards - distinct from validation, which asks whether they describe the right need.

Confirming with stakeholders that requirements actually represent the real need and will deliver expected value, beyond merely being well-formed statements.

A candidate way of satisfying requirements, described with its costs, benefits, risks, and constraints so decision makers can compare alternatives and select one.

The knowledge area that measures how well a delivered or partially delivered solution performs, analyzes why value is or is not realized, and recommends action.

A defined metric used to judge a solution in use, chosen to reflect the value expected, and compared against agreed targets to reveal shortfalls.

The extent to which expected benefits actually appear once a solution is in use, which may lag delivery and depends on adoption, environment, and supporting conditions.

A constraint or defect that prevents a solution from delivering full expected value, which the analyst analyzes to recommend removal, workaround, or replacement.

The smallest solution increment that delivers enough value to be usable and to generate learning, used to test assumptions early rather than after full build.

Techniques such as the five whys or cause-and-effect diagrams used to trace a symptom back to underlying causes, so recommendations address causes rather than appearances.