Foundation · ~15% of the ECBA exam

The Business Analysis Core Concept Model

The BACCM is the conceptual backbone of the BABOK® v3. It names the six things every BA works with on every initiative — Change, Need, Stakeholder, Value, Solution, and Context — and the way they shape each other. If you can talk about a problem fluently in these six terms, the rest of the BABOK starts to feel like vocabulary, not memorisation.

At a glance

The six core concepts

Change

The act of transformation in response to a need.

Read in depth →

Need

A problem or opportunity to be addressed.

Read in depth →

Solution

A specific way of satisfying one or more needs in a context.

Read in depth →

Stakeholder

A group or individual with a relationship to the change, the need, or the solution.

Read in depth →

Value

The worth, importance, or usefulness of something to a stakeholder within a context.

Read in depth →

Context

The circumstances that influence, are influenced by, and provide understanding of the change.

Read in depth →

Change

Core concept

The act of transformation in response to a need.

Change is the reason a BA exists on the engagement. Without a change to shape, there is nothing to analyze, justify, design, or evaluate. Every BABOK task either describes a change, plans a change, supports a change, or measures a change.

Key ideas

Change is purposeful — undertaken to deliver value, not for its own sake.
Change moves an enterprise from a current state, through a transition state, to a future state.
Change can be incremental (one capability at a time) or transformational (rethinking how the business operates).
Scope of change is broader than software — it includes process, policy, structure, roles, data, and culture.

Relationships with the other concepts

→A Change addresses one or more Needs.
→A Change is realised by a Solution within a Context.
→A Change affects, and is affected by, Stakeholders.
→A Change is justified and measured by the Value it delivers.

In practice

Before agreeing on what to build, the BA captures the current state honestly (workarounds and all), describes the future state in business terms, and names the transition activities (data migration, training, cutover, parallel running) that get from one to the other.

Common pitfalls

!Treating 'go-live' as the end of the change instead of the start of adoption.
!Documenting the future state without describing how to get there.
!Confusing the change with the project that delivers it.

Example

An insurer replaces a paper claims process with digital intake. The change is not 'a new web form' — it is the shift from physical mail rooms, manual indexing and 14-day cycle times to digital intake, automated triage and 3-day cycle times, including the retraining of 80 adjusters and the retirement of three legacy mailboxes.

Exam probe

Look for words like 'transformation', 'transition', 'current state vs future state', or 'move from X to Y'.

Need

Core concept

A problem to be solved or an opportunity to be pursued.

If the BA does not isolate the real need, every later artefact — scope, requirements, design, tests — solves the wrong problem efficiently. Need is the anchor against which value is later measured.

Key ideas

A need is the underlying driver, not a proposed solution dressed up as a requirement.
Needs exist at multiple levels: enterprise, organizational unit, process, and individual stakeholder.
Needs may be problems (something is broken or costly) or opportunities (something could be better).
Multiple needs can be addressed by one change; one need can spawn many candidate solutions.

Relationships with the other concepts

→A Need motivates a Change.
→A Need is held by Stakeholders.
→A Need is satisfied (well or poorly) by a Solution.
→A Need is shaped by Context — the same symptom in a different context implies a different need.

In practice

When a sponsor says 'we need a new portal', the BA probes: who is hurting, how often, what does it cost today, what would 'better' look like? The output is a problem statement that survives without naming any technology.

Common pitfalls

!Accepting the first stated solution as the need.
!Mistaking a symptom (e.g. 'too many support tickets') for the underlying need (e.g. 'self-service docs are unfindable').
!Failing to confirm that the named stakeholder actually feels the need.

Example

Stated: 'We need a chatbot for support.' After 5 Whys and a quick log review, the underlying need is: 'Tier-1 support is overwhelmed by 7 repeat questions whose answers already exist in our help centre but are not surfaced at the moment of frustration.' That need can be served by a chatbot — or by better in-app help, search, or onboarding.

Exam probe

If the stem describes 'a problem worth solving' or 'an opportunity to pursue', the question is about Need.

Stakeholder

Core concept

A group or individual with a relationship to the change, the need, or the solution.

Requirements come from stakeholders, are validated by stakeholders, and are accepted (or rejected) by stakeholders. Missing a stakeholder usually means missing a requirement, a risk, or a blocker.

Key ideas

BABOK names 10 generic stakeholder roles every BA should screen for on any initiative.
Roles are not job titles — one person can hold several roles, and one role can be held by many people.
Stakeholders differ in authority, influence, attitude, and availability — analyze each axis, not just job title.
Stakeholders inside the change team are stakeholders too (Project Manager, Tester, Implementation SME).

Relationships with the other concepts

→Stakeholders hold Needs and judge Value.
→Stakeholders are affected by, or affect, the Change.
→Stakeholders provide requirements for the Solution.
→Stakeholders sit inside a Context that shapes their attitude and authority.

In practice

Build a stakeholder list early, then categorize using a power/interest grid or RACI. Re-check on every major scope change — stakeholders are not set once.

Common pitfalls

!Equating 'stakeholder' with 'people in the steering committee'.
!Forgetting silent stakeholders such as Regulator, Operational Support, and the End User who never gets invited to the workshop.
!Treating the loudest voice as the most important voice.

Example

On a new in-store payments feature: Sponsor (CFO), Regulator (PCI compliance officer), End User (cashier and customer), Implementation SME (engineer), Operational Support (helpdesk), Domain SME (head of retail ops), Tester (QA lead), Supplier (terminal vendor).

Exam probe

Memorize the 10 generic stakeholder roles. Scenario questions often turn on whether you remembered to consult one of them — commonly Regulator or Operational Support.

The 10 generic stakeholder roles

Business Analyst

Responsible for the BA work itself.

Customer

Uses or consumes the products and services produced by the enterprise.

Domain Subject Matter Expert

Deep knowledge of the business area under change.

End User

Directly interacts with the solution.

Implementation Subject Matter Expert

Specialist in delivery — developer, architect, trainer.

Operational Support

Keeps the solution running day-to-day after go-live.

Project Manager

Manages scope, schedule, budget, and risk of the project.

Regulator

External or internal authority defining mandatory rules.

Sponsor

Authorizes and funds the change; owns the business case.

Supplier

External party providing products or services to the enterprise.

Tester

Verifies the solution meets requirements and quality standards.

Value

Core concept

The worth, importance, or usefulness of something to a stakeholder within a context.

Value is the ultimate test of whether the change was worth doing. It frames prioritization, scope decisions, trade-offs, and post-implementation evaluation.

Key ideas

Value is judged by the stakeholder receiving it, not by the BA producing it.
Value can be tangible (revenue, cost, hours saved) or intangible (trust, safety, brand, morale).
Value can be positive (a benefit gained) or negative (a loss avoided, a risk reduced).
Different stakeholders perceive different value from the same outcome — sometimes in conflict.

Relationships with the other concepts

→Value is delivered by a Solution that addresses a Need.
→Value is perceived by Stakeholders.
→Value is shaped by Context — what is valuable in one market may be irrelevant in another.
→Value justifies the Change.

In practice

Frame each requirement, feature, or release in terms of who gets value, what kind of value, and how that value will be measured. Without a measurable value statement, prioritization becomes politics.

Common pitfalls

!Treating value as universal (the BA's view vs the customer's view).
!Counting outputs (features shipped) as if they were outcomes (value delivered).
!Ignoring negative value to one stakeholder group while celebrating positive value to another.

Example

A faster claims process delivers value to the customer (speed and certainty), to the insurer (lower handling cost per claim), and to the regulator (auditable trail) — for three different reasons. A redesign that speeds the customer up but blinds the regulator is not net-positive value.

Exam probe

Value is always relative to a stakeholder and a context. Beware answers that present value as absolute or one-dimensional.

Solution

Core concept

A specific way of satisfying one or more needs in a context.

The solution is what gets built, bought, configured, retrained, or restructured. The BA's job is not to design the solution alone, but to ensure the solution genuinely addresses the need and delivers value.

Key ideas

A solution may be a system, a process, an organizational change, a policy, or any combination.
Solutions are evaluated by the value they deliver, not by the elegance of their features.
A solution exists in a context — the same solution will perform differently in different organizations.
Solutions can be partial — a single change may deliver one solution component now and another later.

Relationships with the other concepts

→A Solution satisfies one or more Needs.
→A Solution delivers Value to Stakeholders.
→A Solution is realised through a Change.
→A Solution must fit its Context.

In practice

Always present at least two viable solution options against the same needs and context, with their trade-offs. A single proposed solution is a recommendation in disguise — and removes the sponsor's right to choose.

Common pitfalls

!Jumping to a solution before the need is agreed.
!Treating the technical system as the entire solution and ignoring process, role, and policy components.
!Evaluating solutions on feature lists rather than on value delivered.

Example

To address renewal friction: a self-service portal, a redesigned renewal workflow with a 14-day reminder cadence, an updated customer email template, and retraining for the retention team — together form the solution. The portal alone would not.

Exam probe

When the question lists multiple options and asks which best satisfies the need, it is testing your ability to evaluate Solutions, not to design them.

Context

Core concept

The circumstances that influence, are influenced by, and provide understanding of the change.

Context is what makes business analysis a judgment discipline rather than a checklist. Two organizations with the same need can correctly arrive at different solutions because their context differs.

Key ideas

Context includes culture, attitudes, beliefs, behaviors, geography, regulation, language, technology in place, and existing investments.
Context is partly internal (org structure, capability, history) and partly external (market, competitors, law).
Context changes — what was true at project start may not be true at go-live.
Context constrains what is feasible and shapes what is desirable.

Relationships with the other concepts

→Context shapes Needs (what is felt as a problem here may be normal elsewhere).
→Context constrains the Solution (regulation, infrastructure, capability).
→Context influences Value (what is valuable to this stakeholder, in this market, today).
→Context affects Stakeholders (their authority, their attitude, their availability).

In practice

Before recommending a solution, document the context assumptions it depends on. When a recommendation is challenged, the conversation should move to the assumptions, not to the recommendation itself.

Common pitfalls

!Importing a 'best practice' from another company without checking whether the context still holds.
!Treating context as static — it shifts as the organization, market, and regulation evolve.
!Ignoring informal context (politics, history, prior failed projects) because it is not in any document.

Example

Mobile-first digital banking is the obvious solution where smartphone penetration and 4G coverage are high. In a market where connectivity is patchy and many customers do not own a smartphone, USSD or agent banking may deliver more value — same need, different context, different solution.

Exam probe

Look for words like 'environment', 'circumstances', 'organizational culture', 'regulation', or 'market conditions' — they signal Context.

How the concepts shape each other

The six concepts are a system, not a list

BABOK is explicit that the BACCM concepts are equally necessary — none is more important than the others, and a change to one always implies a re-examination of the rest. These are the most common interactions to internalise before the exam.

Need→Change

A Need motivates a Change. No need, no change worth doing.

Change→Solution

A Change is realised through one or more Solutions.

Solution→Value

A Solution exists to deliver Value — measured against the original Need.

Stakeholder→Value

Value is judged by the Stakeholder receiving it, not by the BA producing it.

Context→Solution

Context constrains and shapes which Solutions are viable and desirable.

Stakeholder→Need

Stakeholders hold the Needs the change must address.