ECBA: Integrated foundations: ECBA study guide

Business analysis through need, change, value and context

Business analysis begins with a need and the context in which people experience it. A request for an application is a proposed solution, not yet a complete account of the problem. Ask what outcome matters, who is affected, what happens now and which constraints shape possible changes. A need might concern an opportunity as well as a failure. Value is the worth of an outcome to a stakeholder in a particular context, so a single measure of speed does not necessarily capture all relevant benefits and burdens.

A connected way of reasoning

The concepts of change, need, solution, stakeholder, value and context can be used together. A new booking process changes work for customers and staff; the need might be fewer missed appointments; possible solutions include reminders or a redesigned scheduling process. The relevant stakeholders include people who use, maintain and are affected by that process. Context includes existing systems, resources and applicable constraints. Describing these relationships helps avoid selecting technology before understanding the decision.

Elicit and confirm

Elicitation is purposeful discovery of information. Interviews can explore experience, observation can reveal actual work, workshops can resolve shared questions and surveys can gather responses from a distributed group. These are tools, not automatic guarantees of representative or complete evidence. Compare what a participant says with the context and other relevant evidence. Confirm the meaning of a requirement with the appropriate people before treating an initial statement as an agreed decision.

Model, trace and test

A process model can show activities and decisions; a data model can clarify relationships; a simple prototype can expose an assumption. Choose a representation that helps the audience make a decision. Traceability connects requirements to origins, related requirements, designs and tests. It supports impact analysis without establishing that every requirement is correct. Verification checks quality and consistency, while validation considers whether the requirement supports the intended need and value. Clear acceptance criteria make the expected behavior observable.

Evaluate the outcome

Compare delivered performance with the outcome and baseline that justified the change. A system can meet its specification yet deliver little value because adoption, organizational conditions or an incorrect assumption limits the result. Investigate that gap before simply adding more features. Current English ECBA materials organize learning around nine domains and the Business Analysis Standard alongside BABOK concepts; the six BABOK knowledge areas used in many related practice questions are not asserted here to be the current ECBA blueprint. Exact examination administration and weighting remain separate from these transferable foundations.

Business Analysis Planning and Monitoring: Deciding How the Work Will Be Done

This knowledge area covers how the business analyst plans the analysis work itself: which lifecycle fits, who must be engaged, how decisions and changes are governed, how information is stored and reused, and how BA performance is measured. BABOK Guide v 3 organises it into five tasks. Exam questions here ask you to match planning choices to context rather than recite a template.

The five tasks and their outputs

Plan Business Analysis Approach - choose a predictive, adaptive, or hybrid lifecycle and set deliverables, timing, techniques, and how the approach will be adjusted. Output: business analysis approach.
Plan Stakeholder Engagement - analyse who can affect or be affected by the change, their authority, influence, attitude, and communication needs. Output: stakeholder engagement approach.
Plan Business Analysis Governance - define decision-making, change control, prioritisation, and approval authority. Output: governance approach.
Plan Business Analysis Information Management - set level of abstraction, storage, access, reuse, retention, and traceability. Output: information management approach.
Identify Business Analysis Performance Improvements - measure the BA work and find improvements. Output: business analysis performance assessment.

Worked example

A bank must document claims handling to a regulator with fixed dates and a prescribed template. The BA chooses a largely predictive approach for specification and approvals, plans one requirements workshop per department, establishes a change board chaired by the compliance lead, and stores requirements in a repository with clause-level traceability. When a department head asks for daily stand-ups, the BA keeps the fixed deliverable dates but runs a short daily clarification call. Real work is adjusted, not abandoned. The reasoning: regulator-driven constraints shape governance and information management, while collaboration can still flex.

Traps that cost marks

Reading predictive as "no change control". Predictive fixes scope early, which makes disciplined change control more important, not less.
Answering a stakeholder-engagement question with a communication plan. Engagement also covers analysis of influence, attitude, and collaboration needs.
Choosing "solution performance measures" when the task is BA performance improvement - that task measures the analyst's own work.
Assuming every stakeholder needs the same level of involvement and the same information format.

Elicitation and Collaboration: Getting Information and Keeping People With You

This domain tests how the analyst obtains information and sustains stakeholder cooperation through the change. BABOK Guide v 3 defines five tasks: Prepare for Elicitation, Conduct Elicitation, Confirm Elicitation Results, Communicate Business Analysis Information, and Manage Stakeholder Collaboration. Questions typically probe technique selection, what confirmation actually requires, and how to tailor communication.

The task flow

Prepare - clarify the purpose and scope of the activity, choose techniques, confirm participants and logistics, assemble materials. Output: elicitation activity plan.
Conduct - BABOK v 3 groups elicitation into collaborative, research, and experimental forms. Interviews and workshops are collaborative; document analysis and questionnaires are research; prototyping and observation are experimental. Interactive techniques suit small, available groups; questionnaires suit large, dispersed populations; observation surfaces tacit, habitual work.
Confirm - compare results against the source, resolve contradictions, close gaps, and record the confirmed results. This is a real analysis step, not a formality.
Communicate Business Analysis Information - adjust format, level of detail, and formality to each audience, and check that the message landed.
Manage Stakeholder Collaboration - monitor engagement, surface and resolve conflict, negotiate commitments, and keep working relationships productive.

Worked example

A logistics firm is building a driver app. Warehouse managers insist paper manifests are obsolete, and drivers never mention printing. Observation at depots shows drivers printing every morning because mobile signal is poor. The BA records offline capability as a non-functional requirement and confirms it with the drivers in a follow-up interview. The reasoning: interviews captured stated needs, observation captured actual behaviour, and confirmation closed the gap between the two.

Traps that cost marks

Treating confirmation as a signature. It requires checking consistency, resolving conflicts, and identifying missing information.
Selecting a workshop for fifty dispersed stakeholders, or a questionnaire when you need to probe reasons in depth.
Assuming the sponsor's account represents all stakeholders.
Forgetting that elicitation also verifies and elaborates requirements you already hold, and that preparation is a scored task in its own right.
Assuming silence means agreement.

Requirements Life Cycle Management: Traceability, Change, and Approval

This domain covers managing requirements and design information from inception to retirement: tracing it, maintaining it, prioritising it, judging changes to it, and getting it approved. BABOK Guide v 3 lists five tasks - Trace Requirements, Maintain Requirements, Prioritize Requirements, Assess Requirements Changes, and Approve Requirements. The exam tests whether you can keep a requirement set coherent as the change unfolds.

Core rules

Traceability uses specific relationships, including derive, depend, necessitate, satisfy, and validate. Requirements are traced from business requirement down to stakeholder, solution, and transition requirements, and across to design components and test cases.
Requirement types matter: business, stakeholder, solution (functional and non-functional), and transition. Transition requirements are temporary - needed only to move from current to new state - and are a frequent exam gap.
Maintenance keeps attributes accurate: source, owner, priority, status, and version, plus baselines for reuse.
Prioritisation uses value, risk, difficulty, and regulatory obligation. Techniques include ranking, grouping (such as MoSCoW), time-boxing, budgeting, or a combination. Priorities are revisited, not frozen.
Change assessment weighs cost, benefit, risk, and impact before routing the request through governance to be approved, deferred, or rejected.
Approval happens at defined points and by defined authority; it can be formal sign-off or documented informal agreement.

Worked example

Mid-project, marketing requests single sign-on. The BA traces it to the business goal "cut login support calls by 30%" and to one stakeholder requirement, then finds it touches four solution requirements, two interfaces, and six test cases, with a security review attached. At the change board the BA recommends deferral to release two because a regulatory date is fixed. The reasoning: the trace proved the value, the impact analysis priced the disruption, and governance made the decision rather than the loudest stakeholder.

Traps that cost marks

Assuming an approved priority stays fixed for the project.
Omitting transition requirements such as data conversion, cutover, and training because they disappear afterwards.
Approving or rejecting a change without tracing it to a business need.
Confusing maintaining requirements with assessing changes to them.

Strategy Analysis: From Current State to Change Strategy

Strategy Analysis examines how the enterprise moves from where it is to where it needs to be. BABOK Guide v 3 defines four tasks: Analyze Current State, Define Future State, Assess Risks, and Define Change Strategy. Expect questions on the difference between goals and objectives, gap analysis, risk tolerance, solution scope, and transition states.

Core rules

Analyze Current State establishes the business need and the internal and external context: capabilities, processes, technology, structure, and constraints. Root cause analysis keeps you from solving the wrong problem.
Define Future State sets business goals and business objectives - measurable and time-bound - plus the scope of the solution space and its constraints. Future state describes outcomes, not a product design.
Assess Risks identifies and evaluates risks against the enterprise's risk tolerance, that is, how much uncertainty it will accept.
Define Change Strategy compares current and future states (gap analysis), determines solution scope, sequences transition states, and sets out the change strategy and business case.

Worked example

An online retailer has high return-related contact volume. Current state shows returns can only be processed in store. Future state objectives are a 40% reduction in returns contacts and refunds within two days. The gap: no self-service return portal and no reverse-logistics integration. Risks include fraud, carrier capacity, and low digital adoption among older customers. The change strategy covers a single-region pilot, then national rollout as two transition states; solution scope includes the portal and carrier integration but excludes in-store returns, which remain unchanged. The reasoning: the gap determines scope, the transition states manage risk, and the objectives carry measures and timeframes.

Traps that cost marks

Writing the future state as a solution design or a feature list.
Stating goals without measures, timeframes, or baselines.
Ignoring the do-nothing option and the business case behind change strategy.
Confusing gap analysis with solution design - the gap explains why change is needed, not how to build it.
Skipping transition states, which leave both the origin and destination and the route between them undefined.

Requirements Analysis and Design Definition: Modelling, Verifying, and Choosing

This domain turns raw information into structured requirements and evaluated design options. BABOK Guide v 3 lists six tasks: Specify and Model Requirements, Verify Requirements, Validate Requirements, Define Requirements Architecture, Define Design Options, and Analyze Potential Value and Recommend Solution. Questions usually hinge on the requirement-versus-design split and on verification versus validation.

Core rules

Requirements state what must be satisfied; design states how it will be satisfied. Both are requirements and design information, but they are not interchangeable.
Models present different views: process, data, state, interface, roles and permissions, and business rules. Text alone rarely captures rules and states cleanly.
Verification checks the quality of the requirement itself: complete, consistent, correct, feasible, unambiguous, and testable.
Validation checks that the requirement addresses the business need and will deliver value; acceptance criteria and prototypes support it.
Requirements architecture organises requirements and models into a coherent whole with defined viewpoints.
Design options allocate requirements to solution components; evaluation uses value analysis - financial measures such as net present value, ROI, and payback, plus non-financial factors.

Worked example

A refund flow has two conflicting rules: treasury releases refunds after ten days, published policy promises five. Verification flags the inconsistency before build. A prototype then validates with customers that five days is what the business objective - reduced complaints - actually requires. Two design options follow: extend the existing billing module (cheaper now, more rework risk later) or build a dedicated module (higher cost, better value over five years once support costs are counted). The recommendation follows value, not the lowest sticker price.

Traps that cost marks

Calling a prototype or a model the solution design and skipping requirement specification.
Swapping verification and validation under time pressure.
Choosing the cheapest design option without analysing value or lifecycle cost.
Treating non-functional requirements as optional detail when they often determine design choice.
Building an architecture of disconnected models that contradict each other.

Solution Evaluation: Measuring Delivered Value and Finding Constraints

Solution Evaluation asks whether a deployed or partially deployed solution delivers the value the enterprise expected, and if not, why. BABOK Guide v 3 defines five tasks: Measure Solution Performance, Analyze Performance Measures, Assess Solution Limitations, Assess Enterprise Limitations, and Recommend Actions to Increase Solution Value. Expect questions that separate solution limitations from enterprise limitations.

Core rules

Measure solution performance against measures derived from business objectives, and compare to a baseline captured before or during deployment. Without a baseline, a number proves nothing.
Analyse performance measures by identifying variances from expected results, testing whether the measure truly reflects the objective, and looking for causes rather than symptoms. Correlation is not causation.
Solution limitations are factors inside the solution: defects, slow performance, missing capability, poor usability, design constraints.
Enterprise limitations are factors outside the solution: culture, skills, training, policy, process, incentives, and dependencies on other systems.
Recommendations can include fixing the solution, changing the enterprise, expanding scope, retiring or replacing the solution, or taking no action. Recommendations follow analysis, never precede it.

Worked example

A new CRM reaches 45% usage against an 80% target, with satisfaction at 3.1 out of 5. Analysis shows usage is concentrated on desktop; mobile page load takes twelve seconds (a solution limitation), and records for a major client segment were never migrated, so staff cannot rely on the data (an enterprise limitation). The recommendation is to fix mobile performance, complete migration, and retrain - not to replace the CRM. The reasoning: two distinct limitation types require two distinct fixes, and replacement would not address either.

Traps that cost marks

Recommending replacement or retirement before root cause analysis of performance measures.
Blaming the solution for an enterprise limitation such as missing training or misaligned incentives.
Reporting raw metrics with no baseline, target, or business objective attached.
Measuring only lagging indicators and declaring success before behaviour stabilises.
Stopping at measurement and never producing recommended actions, which is the final task output.