CCBA key terms

The set of decisions about how business analysis will be carried out on an initiative, covering the level of detail, timing, techniques, and deliverables chosen for the work.

An approach that settles most business analysis activities and deliverables early, favoring formal documentation and sequential progress before solution work moves ahead.

An approach that keeps documentation light and plans short, delivering analysis in repeated cycles so understanding and requirements can adapt as feedback arrives.

Identifying the individuals and groups who affect or are affected by an initiative, and assessing their interests, influence, attitudes, and information needs.

A description of how each stakeholder group will be involved, including what they need to know, when to bring them in, and which collaboration methods to use.

The agreed way business analysis information will be stored, named, accessed, versioned, and reused so that it stays consistent and available across the initiative.

The possibility that requirements, or the business analysis work producing them, will prove incomplete, unclear, or misunderstood enough to threaten the value of the solution.

The activity of drawing out relevant information from stakeholders and other sources so that needs, context, and requirements can be understood.

A structured method such as a workshop, interview, observation, or document review, used to obtain business analysis information from people or materials.

A facilitated group session in which stakeholders work together to surface, clarify, or resolve requirements and reach a shared understanding.

Watching people carry out their work in context to learn how tasks really happen, including details they might not think to describe.

Reviewing existing documents, records, and system outputs to extract information about the business, its rules, and how work is currently done.

Elicitation output that stakeholders have reviewed and agreed accurately reflects what they meant, before it is treated as a requirement.

The ability to follow a requirement in both directions, linking it back to its source and forward to related designs, tests, and delivered components.

A table recording relationships between requirements and other items such as sources, designs, and test cases, so coverage and impact can be checked.

An agreed and recorded set of requirements or plans that acts as a reference point, against which later changes are compared and managed.

Formal confirmation by an authorized stakeholder that a requirement or set of requirements is acceptable and may move forward into design or delivery.

Assessing what a proposed change would affect - requirements, designs, effort, cost, and value - so decision makers can accept, reject, or defer it.

The process for requesting, assessing, deciding on, and recording changes to baselined requirements or other business analysis information.

A piece of information attached to a requirement, such as its priority, owner, status, source, or complexity, used to manage and report on it.

Examining the existing business situation - processes, capabilities, systems, and problems - to understand what is happening and why change is needed.

Describing the business situation the organization wants to reach, including the goals, capabilities, and conditions that the change should produce.

Comparing the current and future states to identify what must be added, removed, or altered to move from one to the other.

The problem or opportunity that motivates a change, stated in terms of the value the organization expects to gain or protect.

A decision document justifying an investment by setting out the need, options considered, expected benefits, costs, risks, and a recommendation.

The overall approach for moving from the current state to the future state, covering scope, transition steps, and how the change will be supported.

Needs that must be met only while moving to the new solution, such as data conversion, training, or temporary parallel running, and that disappear afterwards.

A statement of behavior the solution must perform, describing what it does with data or in response to a user or another system.

A statement of a quality or constraint the solution must satisfy, such as performance, availability, security, or usability, rather than a behavior it performs.

A policy, constraint, or condition that governs how the business operates and that a solution must respect, independent of any particular implementation.

The conditions a solution or increment must satisfy to be accepted by stakeholders, usually written as testable statements.

Checking that requirements are well formed and of good quality - complete, clear, consistent, and unambiguous - rather than confirming they address the real need.

Confirming with stakeholders that requirements describe the real need and would deliver the intended value once the solution is implemented.

A description of how solution components will be arranged and will interact to satisfy the requirements, at whatever level of detail is useful.

Assessing a solution that is in use or under construction to judge how well it delivers value and where it falls short.

A defined indicator with a target and a method of measurement, used to judge whether a solution or process achieves the intended outcome.

A shortcoming in the solution itself that keeps it from delivering full value, such as a missing capability, poor usability, or a defect.

A constraint outside the solution - in policy, culture, systems, or organizational structure - that limits the value the solution can deliver.

An evaluation carried out after a solution has been in use for some time, comparing actual outcomes and benefits with what was expected.