A–Z reference

The language of business analysis

A searchable A–Z reference covering BABOK concepts, techniques, modeling notations, methodologies, and BA roles. Search or filter to find what you need.

Showing 375 terms

A

16
Activity Diagram
Modeling
UML diagram that models the flow of activities, decisions, and parallelism in a process or system.
Actor
Modeling
A role that interacts with a system, process, or use case from outside its boundary. Actors may be humans, organisational units, or other systems. BABOK treats actor identification as a precondition for use case modelling and scope definition.
Adaptive Approach
Process & Methodology
Change-driven BA approach where requirements emerge progressively and are elaborated just-in-time. Best fit for high uncertainty, evolving needs, or where early feedback materially reduces risk.

Used in 1 place

Affinity Diagram
Techniques
Technique for grouping a large number of ideas or items into related categories.
Agile
Process & Methodology
Iterative, incremental approach to delivery emphasizing collaboration, adaptability, and customer value, defined by the Agile Manifesto.
Deep dive · extended definition + exam tip

Extended

An umbrella term for iterative, incremental delivery approaches grounded in the Agile Manifesto's four values and twelve principles. Common frameworks: Scrum, Kanban, XP, SAFe, LeSS, DSDM. Agile is a mindset; the frameworks are operationalizations.

When used

When requirements are uncertain, change is expected, and feedback loops add more value than upfront specification.

Common confusions

  • vs. ScrumScrum is one Agile framework; Agile ≠ Scrum.
  • vs. WaterfallWaterfall plans all requirements upfront; Agile elaborates them just-in-time.

Exam tip

BABOK lists Agile as one of five Perspectives — recognize Agile-flavored elicitation and prioritization on the exam.

Agile Perspective
BABOK Core
BABOK lens for BA work in iterative, incremental delivery. Emphasises just-in-time analysis, lightweight artefacts (e.g. user stories), close collaboration with the Product Owner and team, and validation through working product.
AIArtificial Intelligence
Data & Analytics
Field of computer science focused on building systems that perform tasks normally requiring human intelligence.
ANDParallel Gateway
Modeling
BPMN gateway that splits flow into concurrent paths and joins them when all have completed.
Anonymisation
Data & Analytics
Irreversible removal of personally identifying information from a dataset so individuals cannot be re-identified.
APIApplication Programming Interface
General BA
Defined interface that allows software components or systems to communicate with one another.
ARPUAverage Revenue Per User
Business & Strategy
Total revenue divided by the number of users or accounts over a defined period.

Used in 1 place

ARRAnnual Recurring Revenue
Business & Strategy
Normalised annual value of subscription revenue from existing contracts at a point in time.

Used in 1 place

As-Is Process
Process & Methodology
The current-state representation of a process, modelled as it actually runs today rather than as policy describes it.
Assumption
General BA
Factor considered to be true, real, or certain without proof, that influences planning.

B

32
BABusiness Analyst
Roles
Practitioner who identifies business needs and recommends solutions that deliver value to stakeholders.

Used in 120 places

BABOKBusiness Analysis Body of Knowledge
BABOK Core
The globally recognized standard for the practice of business analysis, published by IIBA. The current edition is BABOK Guide v3.

Used in 41 places

Deep dive · extended definition + exam tip

Extended

BABOK Guide v3 organizes business analysis into 6 knowledge areas, 30 tasks, 50 techniques, 5 perspectives, and the BACCM. It is descriptive, not prescriptive — it catalogs what BAs do across contexts rather than mandating one method.

When used

As the source of truth when discussing BA terminology, scoping a BA approach, or preparing for any IIBA certification exam.

Common confusions

  • vs. PMBOKPMBOK governs project management; BABOK governs business analysis. They overlap on stakeholder and risk topics but have different audiences.
  • vs. ISO/IEC standardsBABOK is a body of knowledge published by IIBA, not an ISO standard. Compliance is voluntary and reputational.

Related terms

Exam tip

Every ECBA question is anchored in BABOK v3 vocabulary — when two answers seem right, pick the one that uses BABOK wording verbatim.

BACCMBusiness Analysis Core Concept Model
BABOK Core
Conceptual framework of six core concepts essential to business analysis: Change, Need, Solution, Stakeholder, Value, and Context.
Deep dive · extended definition + exam tip

Components — what each part means

Six equal, mutually-defining concepts. Every BA piece of work should make all six visible.

  1. Change

    The act of transformation in response to a need — what is being altered (process, system, capability, behaviour).

    ExampleReplacing manual invoice approval with an automated workflow.

  2. Need

    A problem, opportunity, or constraint that motivates the change. Without a need, the change has no justification.

    ExampleApprovals take 9 days on average and block month-end close.

  3. Solution

    A specific way of satisfying one or more needs in a context — process, product, service, or combination.

    ExampleA new approval workflow tool integrated with the ERP.

  4. Stakeholder

    Any group or individual with a relationship to the change, the need, or the solution. Each has interests and influence.

    ExampleAP clerks, finance director, auditors, IT operations.

  5. Value

    The worth, importance, or usefulness of something to a stakeholder — can be tangible (money, time) or intangible (trust, morale).

    ExampleCycle time cut from 9 days to 2 saves 6 FTE days/month.

  6. Context

    The circumstances that influence, are influenced by, and provide understanding of the change — culture, regulations, infrastructure, etc.

    ExampleSOX-regulated environment, hybrid workforce, legacy ERP.

How they relate

The six concepts define each other: a Need exists only in a Context, a Solution delivers Value to a Stakeholder, and any Change must be expressible in all six. If one is missing or weak, the BA work is incomplete.

How a BA uses it

Use as a checklist when scoping or reviewing. Walk through each concept aloud — if you cannot answer one, that's the gap to elicit next.

Extended

The Business Analysis Core Concept Model is six concepts that must all be considered on every initiative: Change, Need, Solution, Stakeholder, Value, and Context. They are equal in importance, mutually defining, and serve as a checklist for whether a piece of BA work is complete.

When used

When framing a new initiative, sanity-checking a requirements package, or explaining the scope of BA work to a non-BA audience.

Common confusions

  • vs. Knowledge AreasBACCM is conceptual (the 'what we reason about'); KAs are activity-based (the 'what we do').
  • vs. Underlying CompetenciesCompetencies are personal skills of the BA; BACCM concepts describe the work itself.

Exam tip

If a question lists five of the six BACCM concepts and asks what's missing, the answer is almost always Context — it's the most-forgotten one.

Backlog Management
Techniques
Practice of recording, prioritizing, and refining items to be addressed by the team.
Backlog Refinement
Process & Methodology
Ongoing activity of adding detail, estimates, and order to product backlog items.

Used in 2 places

BAPMBusiness Analysis Planning and Monitoring
BABOK Core
Knowledge area abbreviation (KA 1) covering how BA work is organized, governed, and improved across an initiative.
Deep dive · extended definition + exam tip

Extended

Business Analysis Planning and Monitoring (KA 1) defines how BA work will be performed: the approach, stakeholder engagement, governance, information management, and performance improvements. Outputs of BAPM govern the other five KAs.

When used

At the start of an initiative and whenever the BA approach needs to adapt — for instance, switching from predictive to adaptive partway through.

Common confusions

  • vs. RLCMBAPM plans the BA work; RLCM manages the requirements that work produces.
  • vs. Project ManagementBAPM plans BA tasks specifically; PM plans the whole project.

Exam tip

BAPM = the only KA whose outputs are used by every other KA. Remember it as 'the meta-KA'.

Bar Chart
Data & Analytics
Chart that uses rectangular bars whose lengths are proportional to the values they represent. Best for comparing discrete categories or ranking. BABOK convention: start the value axis at zero to avoid misleading comparisons.
Benchmarking
Techniques
Comparing organizational practices, performance, or processes against peers or industry leaders.
Benefits Realisation
Business & Strategy
The discipline of identifying, planning, measuring, and confirming the benefits expected from a change. Linked in BABOK to Solution Evaluation (KA 6) and to logic models / benefits dependency networks.
Big Data
Data & Analytics
Datasets too large or complex for traditional tools, typically characterised by volume, velocity, variety, veracity, and value.
BMCBusiness Model Canvas
Business & Strategy
One-page strategic template describing nine building blocks of a business: customer segments, value propositions, channels, relationships, revenue, resources, activities, partners, and costs.
Bottleneck
Process & Methodology
The step that constrains the throughput of an entire process; improving non-bottleneck steps yields no end-to-end gain.
BPMNBusiness Process Model and Notation
Modeling
Standard graphical notation maintained by OMG for modeling business processes.

Used in 53 places

Deep dive · extended definition + exam tip

Extended

Business Process Model and Notation is the OMG-maintained standard for process diagrams. Core elements: events (circles), activities (rounded rectangles), gateways (diamonds), and sequence/message flows. Pools and lanes show participants.

When used

When modeling current or future business processes that span roles or systems and need a notation business and IT can both read.

Common confusions

  • vs. UML Activity DiagramBoth look similar but UML is software-centric; BPMN is business-process-centric with richer event semantics.
  • vs. FlowchartBPMN has formal semantics for events and gateways; informal flowcharts do not.

Exam tip

Diamond = gateway (decision/parallel split), circle = event, rectangle = activity. ECBA shape questions are easy points.

BPOBusiness Process Outsourcing
Business & Strategy
Contracting a third-party service provider to perform specific business processes such as payroll, support, or accounting.

Used in 1 place

BPRBusiness Process Re-engineering
Business & Strategy
Radical redesign of core business processes to achieve dramatic improvements in productivity, cycle time, quality, and customer satisfaction.

Used in 1 place

Burndown Chart
Process & Methodology
Chart showing the amount of work remaining over time in a sprint or release.
Burnup Chart
Process & Methodology
Chart showing work completed and total scope over time, useful for tracking scope changes.
Business Analysis Information Management
BABOK Core
Defines how BA information is captured, stored, integrated, accessed, and reused across the initiative.
Business Architecture Perspective
BABOK Core
BABOK lens that takes an enterprise-wide view, framing the organisation in terms of capabilities, value streams, information, and operating model. Used to align change initiatives with strategy and avoid local optimisation that fragments the whole.
Business Capability
Business & Strategy
What an organization does — a stable building block of the business expressed as a noun phrase, independent of how or where it is performed.
Business Intelligence Perspective
BABOK Core
BABOK lens for BA work focused on transforming data into decisions. Covers data sourcing, modelling, quality, KPIs, dashboards, and governance — starting from the decision a stakeholder needs to make.
Business Requirement
Requirements
Higher-level statement of the goals, objectives, or needs of the enterprise. Describes why a change is being undertaken.
Deep dive · extended definition + exam tip

Components — what each part means

A well-formed business requirement usually has four parts. If any are missing, push back before signing the business case.

  1. Outcome

    The measurable change in the business — usually a KPI delta, not an activity.

    ExampleCut customer onboarding time from 5 days to 1.

  2. Driver

    The problem, opportunity, or external pressure that makes the change worth doing now.

    ExampleTwo competitors launched same-day onboarding last quarter.

  3. Target / Metric

    The number that says ‘done’. Without a target the requirement cannot be validated post-deployment.

    Example≥ 80% of new customers onboarded in < 24h by Q3.

  4. Constraint

    Boundaries the enterprise puts on the change — budget, regulatory, brand, timeline.

    ExampleMust stay within €500k capex; must remain GDPR-compliant.

How they relate

Outcome answers ‘what changes’; Driver answers ‘why now’; Target makes it measurable; Constraint bounds the solution space. Together they form the input to Strategy Analysis (KA 4) and the parent of every stakeholder requirement that follows.

How a BA uses it

When reviewing a sponsor’s vision statement, mark each sentence with one of the four labels. Anything you can’t label is decoration — push for clarity.

Extended

A higher-level statement of the goals, objectives, and needs of the enterprise — the 'why' behind the change. They are typically owned by executives or the sponsor and trace down to stakeholder and solution requirements.

When used

At the start of an initiative, in the business case, charter, or vision document.

Common confusions

  • vs. Stakeholder RequirementBusiness reqs are enterprise goals; stakeholder reqs are needs of a specific group.
  • vs. Functional RequirementBusiness reqs describe outcomes; functional reqs describe system behavior.

Exam tip

If the wording is at the enterprise/strategic level ('increase market share by 10%'), it's a Business Requirement.

Business Rule
Modeling
A statement that defines or constrains some aspect of the business; rules are typically extracted from process tasks into decision tables or DMN.

C

32
CACCustomer Acquisition Cost
Business & Strategy
Average cost of acquiring a new customer, including marketing and sales spend, divided by new customers won.

Used in 1 place

Call Activity
Modeling
BPMN element that invokes a re-usable process defined elsewhere, supporting process composition and re-use.
CBACost-Benefit Analysis
Techniques
Comparison of expected costs and benefits of a solution to assess its overall value.

Used in 1 place

CBAPCertified Business Analysis Professional
BABOK Core
Senior IIBA certification requiring at least 7,500 hours of BA work experience within the past ten years.
CCBChange Control Board
Process & Methodology
Group authorized to review, evaluate, approve, defer, or reject change requests.

Used in 1 place

CCBACertification of Capability in Business Analysis
BABOK Core
Mid-level IIBA certification requiring at least 3,750 hours of BA work experience within the past seven years.
CDContinuous Delivery
Process & Methodology
Practice of keeping software in a deployable state at all times, with automated release to staging or production.
CDCChange Data Capture
Data & Analytics
Technique for tracking and propagating only the data that has changed in a source system.

Used in 1 place

CESCustomer Effort Score
Business & Strategy
Metric measuring how easy it was for a customer to get an issue resolved or a task completed.

Used in 1 place

Churn Rate
Business & Strategy
Percentage of customers, accounts, or revenue lost over a given period.
CIContinuous Integration
Process & Methodology
Practice of frequently merging code changes into a shared branch and automatically building and testing them.
Class Diagram
Modeling
UML diagram that shows the static structure of a system: classes, attributes, operations, and relationships.
CLVCustomer Lifetime Value
Business & Strategy
Total revenue a business can reasonably expect from a single customer account throughout the business relationship.

Used in 1 place

CMMICapability Maturity Model Integration
Process & Methodology
Process improvement framework that rates organizational maturity across five levels.
Deep dive · extended definition + exam tip

Components — what each part means

Five maturity levels, each building on the previous. Most organizations sit at Level 2 or 3.

  1. 1

    Initial

    Processes are ad-hoc, heroic, and unpredictable. Success depends on individuals, not the system.

    ExampleEvery project run differently; results vary wildly.

  2. 2

    Managed

    Basic project-level processes exist and are followed: planning, tracking, requirements management.

    ExampleAll projects use the same status reporting.

  3. 3

    Defined

    Processes are standardized at the organization level and tailored per project from a common playbook.

    ExampleOrg-wide SDLC standard, tailored per project.

  4. 4

    Quantitatively Managed

    Processes are measured statistically and controlled using data — performance is predictable.

    ExampleDefect density tracked with control charts.

  5. 5

    Optimising

    Continuous, data-driven improvement of the processes themselves. The org learns from variation.

    ExampleImprovement experiments running across teams.

How they relate

Levels are cumulative and ordered: each builds on the goals of the previous. You cannot 'pick' Level 4 — you reach it by satisfying 2 and 3 first.

How a BA uses it

Treat CMMI as a diagnostic, not a destination. Use the level descriptions to spot where current process discipline breaks down and target the next level's practices.

Extended

CMMI rates how mature an organization's processes are on a 5-level scale. Level reflects how repeatable and improvable the process is, not how good the product is.

When used

When assessing organizational process discipline — common in regulated, defence, and outsourcing contexts where customers require a maturity level.

Common confusions

  • vs. ISO 9001ISO 9001 certifies a quality management system; CMMI rates process maturity on a graded scale.
  • vs. ITILITIL is a body of practice for IT service management; CMMI is a maturity-rating framework.

Exam tip

Levels are cumulative — you cannot be Level 4 without satisfying Levels 2 and 3 first.

CMMNCase Management Model and Notation
Modeling
OMG-standard notation for modeling knowledge-intensive, event-driven case work that does not follow a fixed flow.
Concept Model
Modeling
Model showing key business concepts, their definitions, and the relationships between them.
Conceptual Data Model
Data & Analytics
High-level model that describes business entities and their relationships, free of technical detail.
Conceptual Model
Modeling
Highest-abstraction model focused on business meaning — entities, concepts, or processes — with no implementation detail.
Constraint (Requirement)
Requirements
A restriction on the design or implementation of the solution, often technical, regulatory, or budgetary.
Continuous Deployment
Process & Methodology
Extension of continuous delivery in which every change passing automated checks is released to production automatically.
Correlation
Data & Analytics
A statistical relationship between two variables in which they tend to move together. Visualised on scatterplots; BAs must remember correlation does not imply causation.

Used in 1 place

CRChange Request
Process & Methodology
Formal proposal to modify a product, system, requirement, or other baselined item.
CRMCustomer Relationship Management
General BA
Strategy and software for managing an organization's interactions with current and prospective customers.
CSATCustomer Satisfaction Score
Business & Strategy
Metric capturing customers' satisfaction with a specific interaction, product, or service, typically on a 1–5 scale.

Used in 1 place

CSFCritical Success Factor
Business & Strategy
Element required for an organization or initiative to achieve its mission or strategic objectives.

Used in 1 place

Customer
Roles
The stakeholder who consumes a product or service produced by the enterprise.

Used in 46 places

Customer Journey Map
Modeling
Visualisation of the steps, touchpoints, emotions, and pain points a customer experiences while achieving a goal with an organization.
Cycle Time
Process & Methodology
Elapsed time from the start to the end of a process or step, including waits and rework — a primary BPM metric.

D

41
Daily Scrum
Process & Methodology
15-minute daily Scrum event where developers inspect progress and adapt the plan for the day.
Dashboard
Data & Analytics
Curated visual display of the most important information needed to monitor performance against objectives, consolidated and arranged on a single screen so it can be monitored at a glance. Distinct from a report by its focus on monitoring over analysis.
Data Catalog
Data & Analytics
Inventory of data assets in an organization, with metadata describing meaning, ownership, lineage, and usage.
Data Cleansing
Data & Analytics
Process of detecting and correcting (or removing) corrupt, inaccurate, or irrelevant records from a dataset.
Data Dictionary
Modeling
Centralized repository defining the meaning, structure, and usage of data elements in a system.
Data Fabric
Data & Analytics
Architectural approach that integrates data services and metadata across distributed environments to provide unified access.
Data Governance
Data & Analytics
Framework of policies, roles, and processes that ensures data is accurate, available, secure, and used responsibly across an organization.

Used in 1 place

Data Lake
Data & Analytics
Centralized repository that stores large volumes of raw structured and unstructured data in its native format.
Data Lineage
Data & Analytics
End-to-end record of where data comes from, how it moves, and how it is transformed across systems.
Data Mart
Data & Analytics
Subset of a data warehouse focused on a specific business area or function (e.g. sales, finance).
Data Mesh
Data & Analytics
Decentralized data architecture where domain teams own and serve their data as discoverable, interoperable products.
Data Object
Modeling
BPMN artefact representing information consumed or produced by a task; should change the reader's understanding of the flow, not just decorate it.
Data Owner
Data & Analytics
Senior role accountable for a data domain, including its protection, integrity, and value to the business.
Data Pipeline
Data & Analytics
Series of automated steps that move and transform data from source systems to a destination, such as a warehouse or report.
Data Privacy
Data & Analytics
Discipline concerned with how personal data is collected, used, stored, and shared in line with regulation and ethics.
Data Profiling
Data & Analytics
Examining data to collect statistics and information about its structure, content, and quality.
Data Quality
Data & Analytics
Degree to which data is fit for its intended use — measured by accuracy, completeness, consistency, timeliness, validity, and uniqueness.
Data Steward
Data & Analytics
Role accountable for the quality, definition, and proper use of a specific data domain or dataset.
Data Table
Data & Analytics
Structured tabular display of data in rows and columns. Preferred when readers need to look up exact values, compare many attributes, or perform their own analysis — chosen over charts when precision outweighs pattern recognition.
Data Visualisation
Data & Analytics
The graphical representation of data to support understanding, decision-making, and communication. BABOK lists data visualisation among RADD techniques; effective practice matches chart type to the analytical question (comparison, trend, distribution, relationship, composition).
Decision Modeling
Modeling
BABOK v3 technique that depicts how operational business decisions are made, decomposing them into sub-decisions, input data, and the business knowledge (rules) that produce an outcome. Commonly expressed using DMN decision requirements diagrams and decision tables.
Decision Tree
Modeling
Tree-shaped diagram used to model decisions and their possible consequences, often with probabilities and values.
Deliverable
General BA
Any tangible or intangible output produced as a result of project work.
Dependency
General BA
Relationship in which one item, task, or requirement relies on another.
Descriptive Analytics
Data & Analytics
Analytics that summarises what has happened, typically through dashboards and reports.
Design
Requirements
A usable representation of a solution. Designs focus on how value is realized; requirements focus on what is needed.
DevOps
Process & Methodology
Set of practices combining software development and IT operations to shorten the delivery life cycle.
DFDData Flow Diagram
Modeling
Graphical representation of how data moves through a system between processes, stores, and external entities.
Deep dive · extended definition + exam tip

Components — what each part means

Four — and only four — symbol types. A correct DFD uses nothing else.

  1. Data Flow

    An arrow showing data moving from one element to another. Always labelled with what the data is.

    Example'Approved invoice' flowing from Approver to Payment system.

  2. Process

    A circle (or rounded rectangle in some notations) representing a transformation that takes input data and produces output data.

    Example'Validate invoice' process consumes raw invoice, produces validated invoice + error log.

  3. Data Store

    A pair of parallel lines (or open rectangle) representing where data is held at rest — a database, file, or queue.

    Example'Customer database', 'Pending approvals queue'.

  4. External Entity

    A square representing a source or destination of data outside the system boundary — a person, organization, or other system.

    Example'Customer', 'Tax authority', 'CRM system'.

How they relate

Data flows always connect a process to one of the others — never store-to-store, never entity-to-entity directly. Every process must have at least one input and one output flow (no 'black holes' or 'miracles').

How a BA uses it

Start with a Level 0 context diagram (one process bubble = the system, plus external entities). Decompose only the processes that carry meaningful complexity; stop when further detail would not change a design decision.

Extended

A Data Flow Diagram models how data moves through a system: where it comes from, what transforms it, and where it ends up. DFDs are decomposed in levels — a Level 0 (context) shows the system as a single process; lower levels show internal detail.

When used

When the BA needs to understand or specify data movement and transformation, especially for integrations, reporting, or migration scope.

Common confusions

  • vs. FlowchartFlowcharts show control flow (decisions/sequence); DFDs show data flow only.
  • vs. ERDERDs model stored data structure; DFDs model data movement and transformation.

Exam tip

DFDs have FOUR symbol types — if a question lists five or three, it's wrong.

Diagnostic Analytics
Data & Analytics
Analytics that explores why something happened, often through drill-down, segmentation, and root-cause analysis.
Dimension Table
Data & Analytics
Table in a dimensional model that holds descriptive attributes (e.g. time, product, customer) used to slice facts.
DMAICDefine, Measure, Analyze, Improve, Control
Process & Methodology
Six Sigma improvement cycle for existing processes: define the problem, measure performance, analyze causes, improve, and control gains.
Deep dive · extended definition + exam tip

Components — what each part means

Five gated phases. Don't skip ahead — Analyse before Improve is the discipline that distinguishes Six Sigma from guesswork.

  1. D

    Define

    Pin down the problem, scope, customer (CTQ — Critical to Quality), and goal of the project.

    Example'Reduce invoice rejections in EU AP from 12% to 4% by Q3.'

  2. M

    Measure

    Establish a baseline using reliable data. You cannot improve what you have not measured.

    ExampleSample 500 invoices over 4 weeks; current defect rate = 12.3%.

  3. A

    Analyse

    Find the root causes of the variation or defects, using tools like Pareto, Fishbone, regression, hypothesis testing.

    ExampleRoot cause: missing PO references on 78% of rejected invoices.

  4. I

    Improve

    Design and pilot changes that address the root causes; validate with data that they actually move the metric.

    ExampleMake PO field mandatory in supplier portal; pilot drops rejections to 3.8%.

  5. C

    Control

    Lock the gains in: standard work, monitoring, control charts, ownership transfer to operations.

    ExampleMonthly control chart owned by AP manager; alert at >5%.

How they relate

Each phase produces an artifact (charter, baseline, root-cause map, validated solution, control plan). A phase-gate review usually approves moving forward.

How a BA uses it

BAs often own Define and Measure — write the project charter and the data-collection plan — then partner with Six Sigma practitioners through Analyse-Improve-Control.

Extended

DMAIC is the Six Sigma improvement cycle for an EXISTING process that already has a measurable performance problem. It is data-driven and gated — each phase has deliverables before the next can start.

When used

When an existing process is producing variation, defects, or missed targets, and you have the data (or can collect it) to investigate.

Common confusions

  • vs. DMADVDMADV (Design-Measure-Analyse-Design-Verify) is for designing a NEW process; DMAIC fixes an existing one.
  • vs. PDCAPDCA (Plan-Do-Check-Act) is a lighter Lean cycle; DMAIC is heavier, statistical, and Six Sigma-anchored.

Exam tip

If a stem mentions 'reduce variation', 'control chart', or 'Six Sigma' on an existing process — pick DMAIC.

DoDDefinition of Done
Requirements
Shared agreement on the criteria a work item must satisfy to be considered complete.
Domain SMEDomain Subject Matter Expert
Roles
Stakeholder with expertise in some aspect of the business domain affected by the change.

Used in 2 places

DoRDefinition of Ready
Requirements
Criteria a backlog item must meet before a team will commit to working on it in a sprint.
DRDDecision Requirements Diagram
Modeling
DMN diagram showing how decisions depend on sub-decisions, input data, and business knowledge — the top-level view of a decision model.
DWData Warehouse
Data & Analytics
Centralized, structured store of integrated data from multiple sources, optimized for reporting and analytics.

E

13
EAEnterprise Architecture
General BA
Conceptual blueprint of an organization's structure, processes, information, and IT systems.
ECElicitation and Collaboration
BABOK Core
Knowledge area abbreviation (KA 2) covering tasks to draw out, confirm, and communicate BA information with stakeholders.
Deep dive · extended definition + exam tip

Extended

Elicitation and Collaboration (KA 2) draws BA information from stakeholders and other sources, confirms results, and communicates BA information to those who need it. Elicitation is iterative, not a one-shot phase.

When used

Continuously throughout an initiative — not just at the start. New questions trigger new elicitation.

Common confusions

  • vs. Requirements gatheringBABOK avoids 'gathering' because it implies requirements are sitting around waiting to be picked up. Elicitation is active — drawing them out.
  • vs. RADDEC produces raw input; RADD analyses and specifies it.

Exam tip

If a stem says 'gather requirements', the right answer almost always replaces it with 'elicit'.

ECBAEntry Certificate in Business Analysis
BABOK Core
IIBA's entry-level certification for individuals beginning a career in business analysis. No prior BA work experience is required.
Deep dive · extended definition + exam tip

Extended

The Entry Certificate in Business Analysis is the only IIBA credential with no BA work-experience requirement. The exam is 50 multiple-choice questions in 60 minutes, drawn from BABOK v3 chapters 1–4 plus a small share from techniques and perspectives.

When used

By career entrants, switchers from QA/PM/dev roles, and students who want a credential before their first BA job.

Common confusions

  • vs. CCBACCBA requires 3,750 BA hours and a harder, scenario-heavy exam.
  • vs. CBAPCBAP requires 7,500 BA hours and tests applied judgment, not recall.

Related terms

Exam tip

Roughly half the ECBA weighting sits in RADD (~30%) and Foundations (~20%). Master those before drilling techniques.

Elicitation
General BA
Iterative process of drawing out information from stakeholders and other sources.

Used in 47 places

ELTExtract, Load, Transform
Data & Analytics
Modern variant of ETL where raw data is loaded into the target store first and then transformed in-place.

Used in 2 places

End Event
Modeling
BPMN thick-bordered circle that terminates a process path; multiple distinct end events (e.g. success, cancelled, error) are often clearer than one.
End User
Roles
The person who will ultimately interact with the solution to perform their work.
Epic
Requirements
A large body of work that can be broken down into smaller user stories.
ERDEntity Relationship Diagram
Modeling
Diagram showing data entities, their attributes, and the relationships between them.
Deep dive · extended definition + exam tip

Extended

An Entity Relationship Diagram models the data a system stores: entities (things), attributes (properties), and the relationships between them, usually with cardinality (1:1, 1:M, M:N).

When used

When the BA needs to specify or validate the data model — especially when integrating systems or designing reports.

Common confusions

  • vs. Class DiagramClass diagrams add behavior; ERDs are data-only.
  • vs. Data DictionaryERD is visual; data dictionary is a textual catalog of fields, types, and rules.

Exam tip

Crow's foot notation = many. Single line + circle = optional. ECBA often tests cardinality reading.

ERPEnterprise Resource Planning
General BA
Integrated software system that manages core business processes such as finance, HR, supply chain, and operations.
Estimation
Techniques
Forecasting the cost, effort, duration, or resources needed for work. Techniques include analogous, parametric, and three-point.
ETLExtract, Transform, Load
General BA
Data integration process that extracts data from sources, transforms it, and loads it into a target system.

F

6
Fact Table
Data & Analytics
Central table in a dimensional model that stores measurable events, transactions, or metrics.
Fishbone Diagram
Techniques
Cause-and-effect (Ishikawa) diagram used to identify possible causes of a problem grouped by category.

Used in 1 place

Focus Group
Techniques
Facilitated discussion with a selected group of stakeholders to gather opinions, attitudes, and ideas.
Functional Requirement
Requirements
Behavior the solution must perform and information it must manage.
Deep dive · extended definition + exam tip

Components — what each part means

A testable functional requirement names five elements. Drop one and the FR is either ambiguous or untestable.

  1. Trigger

    The event or condition that causes the behaviour to start.

    ExampleWhen a customer submits a return form…

  2. Actor

    Who or what initiates the behaviour — a user role, an upstream system, or a scheduler.

    Example…the Customer (or returns API)…

  3. Action

    What the system shall do — the verb phrase, ideally one observable behaviour per FR.

    Example…the system shall validate the order ID and create a return case…

  4. Data

    The information consumed and produced. Names every field that matters.

    Example…using order_id, reason_code; producing return_case_id, status.

  5. Rules

    Business rules, validations, or branches that govern the behaviour.

    ExampleIf the order is > 30 days old, reject with code R02.

How they relate

Trigger + Actor scope the entry; Action is the verb; Data names the I/O contract; Rules define branches and edge cases. Together they map cleanly onto a use case (Trigger=precondition, Actor=primary actor, Action=main flow, Rules=alternate flows) and onto Gherkin scenarios for test (Given-When-Then).

How a BA uses it

When grooming a backlog item, walk the five labels aloud. The first one you can’t answer is the next question for the Product Owner or SME.

Extended

A solution requirement describing the behavior the system must exhibit — what it must do. Expressed as inputs, outputs, calculations, validations, or workflows.

When used

During RADD when specifying solution behavior; captured in use cases, user stories, process models, or rules.

Common confusions

  • vs. Non-Functional RequirementFunctional = what the system does; NFR = how well it does it (performance, security, usability).
  • vs. Business RuleA business rule is a constraint owned by the business; an FR is a system behavior derived in part from rules.

Exam tip

If you can phrase it as 'the system shall <verb>…', it's an FR.

G

6
Gap Analysis
General BA
Comparison of current state and future state to identify capabilities that are missing or need to change.
Gateway (BPMN)
Modeling
BPMN diamond used to control divergence and convergence of flow — exclusive (XOR), parallel (AND), inclusive (OR), event-based, or complex.
GDPRGeneral Data Protection Regulation
General BA
European Union regulation governing the protection of personal data and privacy.
Glossary
Modeling
Collection of business terms with agreed definitions, used to ensure consistent understanding.

Used in 3 places

Governance
Business & Strategy
The framework of decisions, accountability, and oversight that directs how an organization or initiative is run.
GUIGraphical User Interface
General BA
Visual interface using elements like windows, icons, and buttons that allows users to interact with software.

Used in 1 place

H

3
Hand-off
Process & Methodology
Transfer of work between actors or systems; a primary source of delay, error, and lost context in business processes.

Used in 1 place

Heat Map
Data & Analytics
Two-dimensional matrix in which cell colour intensity encodes a quantitative value. Used in BA work to visualise risk (likelihood × impact), capability maturity, process performance, or any value across two categorical dimensions. Clear legend and consistent colour scale are essential to avoid misreading.
Hybrid
Process & Methodology
Combination of predictive (waterfall-style) and adaptive (agile) approaches tailored to an initiative.

I

17
IaaSInfrastructure as a Service
General BA
Cloud service offering virtualized computing resources over the internet.

Used in 1 place

IIBAInternational Institute of Business Analysis
BABOK Core
The professional association that maintains the BABOK Guide and the ECBA, CCBA, and CBAP certifications.
Implementation SMEImplementation Subject Matter Expert
Roles
Stakeholder with expertise in the implementation of solution components, e.g., developers, architects, testers.
In Scope
General BA
Items, capabilities, processes, or stakeholders explicitly included in the scope of analysis or delivery. Listed alongside out-of-scope items on scope models to prevent later disputes.

Used in 1 place

Increment
Process & Methodology
A working, potentially releasable piece of the product produced during an iteration. The Scrum increment must meet the Definition of Done and add to all prior increments.
Incremental Development
Process & Methodology
Approach in which a solution is delivered in successive pieces, each adding usable functionality.
Influence/Interest Grid
Techniques
Two-by-two matrix plotting stakeholders by their influence over the change against their interest in it. Quadrants (Manage Closely, Keep Satisfied, Keep Informed, Monitor) drive engagement strategy. Referenced by BABOK as a stakeholder-analysis aid.
Information Technology Perspective
BABOK Core
BABOK lens for BA work performed within or for the IT function — implementing, integrating, modifying, or retiring software and infrastructure. Emphasises functional/non-functional requirements, interfaces, and enterprise architecture alignment.
Interface Analysis
Techniques
BABOK v3 technique used to identify and define interactions between systems, organisational units, or solution components — including data exchanged, format, frequency, triggers, and protocols. Output typically captured on context diagrams or interface specifications.
Intermediate Event
Modeling
BPMN double-bordered circle representing something that happens during a flow — typically a timer, message receipt, escalation, or signal.
INVESTINVEST
Requirements
Quality criteria for user stories: Independent, Negotiable, Valuable, Estimable, Small, Testable.
Deep dive · extended definition + exam tip

Components — what each part means

Six independent quality tests for a user story. A good story passes all six.

  1. I

    Independent

    Can be delivered on its own, without depending on another story being done first. Order shouldn't matter.

    Example'Email password reset' doesn't require 'social login' to ship first.

  2. N

    Negotiable

    The story is an invitation to a conversation, not a fixed contract. Details can be adjusted with the Product Owner.

    ExampleHow exactly the 'export' button looks is open until refinement.

  3. V

    Valuable

    Delivers visible value to a user or stakeholder — not a technical task with no observable outcome.

    Example'Customer can download invoice as PDF' (valuable) beats 'Add PDF library' (not).

  4. E

    Estimable

    The team understands it well enough to size the work. If they can't estimate, the story is too vague or too unknown — split or spike it.

    ExampleAcceptance criteria are clear enough to give a story-point estimate.

  5. S

    Small

    Fits comfortably inside one sprint, ideally a few days. Anything bigger should be split — usually by workflow steps, data variations, or rules.

    ExampleSplit 'Manage users' into create / edit / deactivate.

  6. T

    Testable

    Has clear, verifiable acceptance criteria. You can write a test that proves it's done.

    Example'Login fails after 5 wrong attempts within 10 minutes' is testable.

How they relate

The letters reinforce each other: a Small story is easier to make Independent and Estimable; a Valuable story is easier to make Negotiable because the goal anchors the conversation. Failing one letter usually drags the others down.

How a BA uses it

Walk the team through I-N-V-E-S-T at refinement. The first failed letter is the refactor target — split for Small, clarify for Testable, rewrite for Valuable, and so on.

Extended

INVEST is a six-letter checklist for the quality of a single user story. Each letter is a separate test — a story should pass all six before a team commits to it. Originally proposed by Bill Wake.

When used

During backlog refinement, before sprint planning, or any time a story feels too big, vague, or risky to start.

Common confusions

  • vs. Definition of ReadyDoR is a team-agreed gate for any backlog item; INVEST is the specific quality test for user stories.
  • vs. Acceptance CriteriaAC say WHEN a story is done; INVEST tests whether the story is well-formed enough to start.

Exam tip

If asked 'what makes a good user story?', the answer is INVEST — and the most-tested letters are Independent and Small.

IRRInternal Rate of Return
Techniques
Discount rate at which the net present value of an investment's cash flows equals zero.
Issue
General BA
A risk that has materialized or a current problem that requires action and tracking.
Iterative Development
Process & Methodology
Approach in which a solution is built and refined through repeated cycles of planning, building, and evaluating.
ITILITIL
Process & Methodology
Information Technology Infrastructure Library — a framework of best practices for IT service management.
Deep dive · extended definition + exam tip

Components — what each part means

ITIL 4's Service Value System has four 'dimensions' that must all be balanced for any service to deliver value.

  1. 1

    Organizations & People

    Roles, responsibilities, culture, skills, and structure needed to support the service.

    ExampleService desk team with clear escalation paths.

  2. 2

    Information & Technology

    The information the service uses and the tools (hardware, software, platforms) that run it.

    ExampleITSM tool, CMDB, monitoring stack.

  3. 3

    Partners & Suppliers

    External relationships that contribute to the service — vendors, cloud providers, contractors.

    ExampleCloud provider with SLA; outsourced after-hours support.

  4. 4

    Value Streams & Processes

    How the activities of the organization flow together to create value end-to-end.

    ExampleIncident-to-resolution value stream measured for cycle time.

How they relate

Neglecting one dimension breaks the others — great tools (#2) without the right people (#1) still fails. ITIL insists they are co-equal.

How a BA uses it

When scoping or reviewing an IT service, walk the four dimensions as a coverage check — most service problems trace back to a weak or missing dimension.

Extended

ITIL is the de-facto framework for IT Service Management (ITSM). The current version (ITIL 4) is built around a Service Value System with four dimensions and a value chain of six activities. Older versions (ITIL v3) used a five-stage service lifecycle.

When used

When designing or improving how an IT organization delivers and supports services to the business.

Common confusions

  • vs. CMMIITIL is a body of best practices for IT services; CMMI rates organizational process maturity.
  • vs. COBITCOBIT governs IT (control objectives, audit); ITIL operates IT services day-to-day.

Related terms

Exam tip

ITIL is a perspective in BABOK's Information Technology perspective context — recognise its vocabulary (incident, problem, change, service request) on the exam.

J

1
JTBDJobs To Be Done
Business & Strategy
Framework describing what customers are trying to accomplish ('the job they hire a product to do'), independent of features.

Used in 1 place

K

4
KAKnowledge Area
BABOK Core
A grouping of related BA tasks. BABOK v3 defines six knowledge areas, each containing a set of tasks.

Used in 50 places

Kanban
Process & Methodology
Lean method that visualizes work on a board, limits work in progress, and manages flow.

Used in 1 place

KPIKey Performance Indicator
Techniques
A measurable value that shows how effectively an objective is being achieved.
KRIKey Risk Indicator
Data & Analytics
Metric used to signal increasing risk exposure in an activity, process, or organization.

Used in 1 place

L

7
Lane (BPMN)
Modeling
Sub-division of a BPMN pool used to assign responsibility for tasks to a role, department, or system within the same participant.
Lead Time
Process & Methodology
Elapsed time from a customer request to the customer receiving the outcome; usually longer than cycle time because it includes upstream queueing.
Lean Canvas
Business & Strategy
Adaptation of the Business Model Canvas for startups, replacing partner/relationship blocks with problem, solution, key metrics, and unfair advantage.

Used in 1 place

Logical Data Model
Data & Analytics
Detailed model of entities, attributes, keys, and relationships, independent of any specific database technology.
Logical Model
Modeling
Detailed model that fully specifies structure or behaviour while remaining independent of any specific technology platform.

M

14
Market Analysis
Techniques
Studying customers, competitors, and market conditions to inform decisions about products and services.
MDAModel-Driven Architecture
Modeling
OMG approach in which models at successive levels of abstraction (CIM, PIM, PSM) are progressively transformed toward implementation.

Used in 1 place

MDMMaster Data Management
General BA
Discipline for defining and managing an organization's critical shared data to provide a single trusted view.

Used in 1 place

Milestone
General BA
Significant point or event in a project, often marking completion of a major deliverable.
Mind Mapping
Techniques
Visual diagram used to organize information around a central concept and explore relationships.
Mitigation
Process & Methodology
A risk response that reduces the likelihood or impact of a risk to an acceptable level. One of four standard responses alongside avoid, transfer, and accept.
MLMachine Learning
Data & Analytics
Branch of AI in which systems learn patterns from data to make predictions or decisions without being explicitly programmed.

Used in 1 place

MMPMinimum Marketable Product
Process & Methodology
Smallest product that can be released to customers and generate value in the market.

Used in 1 place

Mockup
Modeling
Higher-fidelity static design of a user interface showing visual style and content.

Used in 1 place

MoSCoWMust, Should, Could, Won't
Techniques
Prioritization technique categorizing requirements as Must have, Should have, Could have, or Won't have this time.
Deep dive · extended definition + exam tip

Components — what each part means

Four buckets, applied per release or time-box. The lower-case 'o's are filler — only M, S, C, W carry meaning.

  1. M

    Must have

    Non-negotiable for this release. If any Must is missing, the release fails — legally, contractually, or because the solution is unusable.

    ExampleGDPR consent capture before go-live in the EU.

  2. S

    Should have

    Important and painful to omit, but the release can still ship without it via a workaround. Targeted for inclusion if capacity allows.

    ExampleBulk-import for historical records — manual entry is possible but slow.

  3. C

    Could have

    Desirable, low-cost-of-omission. Included only if Musts and Shoulds finish early. First to be cut when scope tightens.

    ExampleDark-mode UI theme.

  4. W

    Won't have (this time)

    Explicitly out of scope for THIS release. Not rejected — parked, with a record of the decision so it can return next time.

    ExampleMobile app — deferred to phase 2.

How they relate

The four are mutually exclusive and ordered. A useful rule of thumb: keep Musts at ≤60% of effort so Should/Could can absorb estimation slip without sinking the release.

How a BA uses it

Score every backlog item once, with stakeholders in the room. Re-score whenever scope, capacity, or deadline changes — never treat the labels as permanent.

Extended

A prioritization technique grouping items into Must have, Should have, Could have, and Won't have (this time). 'Won't' is explicit — it parks the item without rejecting it. The split is typically targeted at no more than 60% Must in any release window.

When used

When prioritizing a backlog, release scope, or feature list with mixed-priority stakeholders. Especially common in DSDM and time-boxed agile.

Common confusions

  • vs. Kano ModelMoSCoW prioritizes by importance/timing; Kano classifies by customer satisfaction impact (basic, performance, delighter).
  • vs. Numeric rankingMoSCoW is bucketed; numeric ranking forces a strict order.

Exam tip

The 'W' in MoSCoW = Won't have THIS TIME, not 'never'. ECBA distractors often misstate this.

MoSCoW Prioritisation
Techniques
Prioritisation method that classifies items as Must have, Should have, Could have, or Won't have (this time). Originating in DSDM and widely adopted in BABOK practice; the 'Won't have' category is critical for managing scope.
MRRMonthly Recurring Revenue
Business & Strategy
Normalised monthly value of subscription revenue, used widely in SaaS finance and product analytics.

Used in 1 place

MVPMinimum Viable Product
Process & Methodology
Version of a product with just enough features to satisfy early users and validate learning.

N

5
NFRNon-Functional Requirement
Requirements
Quality attribute or constraint such as performance, security, usability, reliability, or maintainability.
Deep dive · extended definition + exam tip

Components — what each part means

ISO/IEC 25010 groups NFRs into eight quality characteristics. Most exam scenarios map cleanly to one of these — recognise the cue word and you have the answer.

  1. Performance

    Speed, response time, throughput, resource use under specified load.

    Example95% of search results return in < 800ms at 1,000 concurrent users.

  2. Reliability

    Uptime, MTBF, fault tolerance, disaster recovery (RTO/RPO).

    Example99.9% monthly availability; RTO ≤ 4h, RPO ≤ 15min.

  3. Security

    Confidentiality, integrity, authentication, authorisation, audit.

    ExampleAll PII encrypted in transit (TLS 1.3) and at rest (AES-256).

  4. Usability

    Learnability, accessibility, error prevention, user satisfaction.

    ExampleNew users complete first checkout unaided in ≤ 3 minutes; meets WCAG 2.2 AA.

  5. Maintainability

    Modularity, testability, ease of change, code quality targets.

    Example≥ 80% unit-test coverage on the payments module; mean time to repair < 2h.

  6. Portability

    Ability to run in different environments, browsers, devices, or clouds.

    ExampleRuns unchanged on the latest two versions of Chrome, Safari, Edge, Firefox.

  7. Compatibility

    Coexistence and interoperability with other systems.

    ExampleExposes a REST API conformant to OpenAPI 3.1; backwards-compatible with v1 clients for 12 months.

  8. Compliance

    Conformance to laws, regulations, standards, contracts.

    ExampleMeets PCI-DSS v4.0 SAQ-A; GDPR Art. 17 (right to erasure) supported.

How they relate

Each FR may have NFRs from one or many of these eight categories. NFRs trade off against each other (e.g., higher security usually costs performance) and against cost — surfacing those trade-offs is core BA work.

How a BA uses it

Pair every architecturally significant FR with at least one NFR per relevant category. Capture them in an NFR matrix so testers can write measurable acceptance criteria.

Extended

Non-Functional Requirements (also called quality attributes) describe how well the system performs its functions: performance, scalability, availability, security, usability, maintainability, portability, and compliance. They constrain the design and are often the hardest to test.

When used

Throughout RADD, especially when designing architecturally significant components or when the solution touches regulated data.

Common confusions

  • vs. Functional RequirementFR = what; NFR = how well.
  • vs. ConstraintConstraints are restrictions on the solution (e.g., 'must use Oracle'); NFRs are quality targets ('< 200ms response').

Exam tip

ECBA loves NFR questions disguised as scenarios — look for performance, security, usability, availability cues.

NoSQL
Data & Analytics
Family of non-relational databases (document, key-value, column-family, graph) optimized for flexibility and scale.
NPSNet Promoter Score
Business & Strategy
Customer-loyalty metric calculated from responses to: 'How likely are you to recommend us?' on a 0–10 scale.
NPVNet Present Value
Techniques
Current value of expected future cash flows from an investment, discounted to today using a required rate of return.

O

12
Observation
Techniques
Studying people performing work to understand processes, environments, and unstated needs. May be active or passive.
OKRObjectives and Key Results
Business & Strategy
Goal-setting framework pairing a qualitative Objective with measurable Key Results that show progress toward it.

Used in 1 place

OLAOperational Level Agreement
Techniques
Internal agreement between IT teams that supports delivery of an SLA to the customer.

Used in 1 place

OLAPOnline Analytical Processing
General BA
Class of systems optimized for complex queries and multidimensional analysis of business data.
OLTPOnline Transaction Processing
General BA
Class of systems optimized for managing transaction-oriented workloads such as order entry.
OMGOMG
Modeling
Object Management Group — the international standards consortium that maintains BPMN, DMN, UML, SysML, and CMMN, the notations most commonly cited by BABOK for modelling processes, decisions, and systems.
Operating Model
Business & Strategy
Description of how an organization delivers value, integrating people, process, technology, data, and governance.
Operational Support
Roles
Stakeholder group responsible for the day-to-day management and maintenance of the solution after deployment.

Used in 1 place

ORInclusive Gateway
Modeling
BPMN gateway that activates one or more outgoing paths based on conditions and joins waiting only for the activated paths.
Out of Scope
General BA
Items, capabilities, processes, or stakeholders explicitly excluded from the scope of analysis or delivery. Documenting exclusions is as important as documenting inclusions and is a standard element of a scope model.

Used in 1 place

P

34
PaaSPlatform as a Service
General BA
Cloud service that provides a platform for developing, running, and managing applications.

Used in 1 place

Pain Point
General BA
Specific problem or frustration experienced by a stakeholder that the solution aims to address.
Payback Period
Techniques
Time required for an investment's cumulative cash inflows to equal its initial outlay.

Used in 1 place

PDCAPlan-Do-Check-Act
Process & Methodology
Iterative four-step management method for the control and continuous improvement of processes and products.
Perspective
BABOK Core
A view of business analysis used in a specific context. BABOK v3 defines five: Agile, Business Intelligence, Information Technology, Business Architecture, and Business Process Management.

Used in 39 places

Perspectives
BABOK Core
Five lenses in BABOK v3 — Agile, Business Intelligence, Information Technology, Business Architecture, Business Process Management — through which BA work is performed. They describe context, not methodology, and most initiatives blend several.
PESTLEPolitical, Economic, Social, Technological, Legal, Environmental
Techniques
Framework for analyzing macro-environmental factors affecting an organization. Variants include PEST and STEEPLE.
Deep dive · extended definition + exam tip

Components — what each part means

Six categories of external macro forces. Use as a checklist so no category is missed.

  1. P

    Political

    Government policy, political stability, trade relations, taxation policy, public-sector priorities.

    ExampleNew US tariff on imported steel.

  2. E

    Economic

    Macro-economic conditions: growth, inflation, interest rates, exchange rates, employment.

    ExampleEurozone interest rate hike raises borrowing cost.

  3. S

    Social

    Demographics, culture, lifestyle, attitudes, education levels, consumer preferences.

    ExampleAging population shifts demand toward healthcare.

  4. T

    Technological

    Innovation pace, emerging tech, automation, R&D activity, infrastructure.

    ExampleGenerative AI lowering content-production cost.

  5. L

    Legal

    Laws and regulations the organization must comply with — distinct from political stance.

    ExampleEU AI Act compliance deadlines.

  6. E

    Environmental

    Climate, sustainability, ecological constraints, ESG expectations.

    ExampleCarbon-reporting requirements for listed companies.

How they relate

Categories overlap (a new law is both Legal and Political). Place each factor in its dominant category — the goal is coverage, not perfect taxonomy.

How a BA uses it

Brainstorm one category at a time, score each factor for impact and likelihood, and feed the high-impact items into SWOT (as Opportunities or Threats) and risk analysis.

Extended

PESTLE is a six-factor scan of the external macro-environment. It catalogs forces an organization cannot control but must understand to set strategy. Variants: PEST (no L/E), STEEPLE (adds Ethics).

When used

Early in Strategy Analysis or when entering a new market, geography, or regulatory regime.

Common confusions

  • vs. SWOTPESTLE is external-only and macro; SWOT also includes internal factors (Strengths, Weaknesses).
  • vs. Porter's Five ForcesPorter analyses industry/competitive structure; PESTLE analyses the wider macro environment.

Exam tip

If the stem mentions 'macro environment', 'regulation', or 'demographic shift', think PESTLE. Pure competitor questions point to Porter, not PESTLE.

Physical Data Model
Data & Analytics
Database-specific model showing tables, columns, data types, indexes, and constraints as they will be implemented.
Physical Model
Modeling
Implementation-ready model expressed in the constructs of a specific platform — tables, columns, services, executable BPMN.
Pie Chart
Data & Analytics
Circular chart divided into sectors illustrating numerical proportion. Appropriate only for showing parts of a single whole with a small number of categories; bar charts are usually preferred for comparison.
PIIPersonally Identifiable Information
General BA
Information that can be used on its own or with other data to identify an individual.

Used in 2 places

Plan Business Analysis Approach
BABOK Core
First task of Business Analysis Planning and Monitoring (KA 1). Selects the point on the predictive–adaptive spectrum and defines deliverables, activities, complexity, and change-management approach for the BA work.
Planning Poker
Techniques
Consensus-based estimation technique used in agile teams, often using a Fibonacci-like scale.
PMProject Manager
Roles
Person responsible for planning, executing, monitoring, and closing a project within scope, time, and budget.
PMBOKProject Management Body of Knowledge
Process & Methodology
PMI's standard for project management knowledge and practices.
PMIProject Management Institute
Process & Methodology
Global professional association for project, programme, and portfolio managers; publisher of the PMBOK Guide and PMP credential.
PMPProject Management Professional
Process & Methodology
Globally recognized PMI certification for experienced project managers.
POCProof of Concept
Process & Methodology
Small exercise to verify that a concept, technology, or design is feasible.
Pool (BPMN)
Modeling
BPMN container representing a participant — typically a separate organisation or system with its own process; pools communicate via message flows.
Power/Interest Grid
Techniques
Stakeholder analysis matrix that classifies stakeholders by their level of power and interest in the change.
Predictive Analytics
Data & Analytics
Analytics that uses historical data and statistical or ML techniques to forecast likely future outcomes.
Predictive Approach
Process & Methodology
Plan-driven BA approach where requirements are defined in detail upfront, baselined, and managed through formal change control. Best fit for regulatory, safety-critical, or fixed-price contexts with stable scope.
Prescriptive Analytics
Data & Analytics
Analytics that recommends actions, often combining predictive models with optimisation or decision rules.
PRINCE2PRojects IN Controlled Environments
Process & Methodology
Process-based project management methodology widely used in the UK public sector and globally.

Used in 1 place

Process Map
Modeling
Visual representation of the steps, actors, and decisions in a business process.

Used in 1 place

Process Modeling
Modeling
BABOK v3 technique that visually depicts a sequence of activities, decisions, and hand-offs that transform inputs into outputs. Used to understand current operations (as-is), design future operations (to-be), surface bottlenecks, and align stakeholders on scope. Notations include flowcharts, swimlanes, BPMN, and value stream maps.
Process Owner
Roles
The single accountable individual for end-to-end performance of a business process across the functions it crosses.
Product Backlog
Process & Methodology
Ordered list of everything that might be needed in the product, owned by the Product Owner.

Used in 2 places

Product Manager
Roles
Role responsible for the strategy, roadmap, and feature definition of a product over its life cycle.
Project Scope
Process & Methodology
The work that must be performed to deliver a product, service, or result with the specified features and functions. BABOK distinguishes project scope (the work) from solution scope (the capabilities of the resulting solution).
Pseudonymisation
Data & Analytics
Replacing identifying fields with reversible tokens so data can be processed without exposing identity.

Q

3
QAQuality Assurance
Process & Methodology
Process-oriented activities ensuring that the methods used to deliver products are effective and produce quality outcomes.
QCQuality Control
Process & Methodology
Product-oriented activities focused on identifying defects in deliverables.
Quick Win
General BA
An item with high value and low effort or cost, deliverable in a short time frame. Quick wins occupy the high-value/low-effort quadrant of an impact-effort matrix and are typically scheduled early to build momentum and demonstrate progress.

R

28
RACIResponsible, Accountable, Consulted, Informed
Techniques
Responsibility assignment matrix mapping each task or decision to one Accountable party and one or more Responsible, Consulted, and Informed roles.
Deep dive · extended definition + exam tip

Components — what each part means

Four roles assigned per task or deliverable, one row at a time.

  1. R

    Responsible

    Does the actual work. Can be one person or several. Always at least one R per row.

    ExampleDeveloper writes the migration script.

  2. A

    Accountable

    Owns the outcome and signs off. EXACTLY ONE per row — split accountability is no accountability.

    ExampleEngineering manager approves the migration.

  3. C

    Consulted

    Two-way conversation: their expertise is needed before the work is finalised. Provides input, can push back.

    ExampleDBA consulted on index strategy.

  4. I

    Informed

    One-way update: told after the fact so they can plan around it. No input expected.

    ExampleSupport team informed before deploy so they can brief agents.

How they relate

R does, A owns, C advises, I is told. R and A can be the same person (working manager); A is never blank. Watch for too many Cs — that's process drag.

How a BA uses it

Draw a grid: tasks down the left, roles across the top. Fill each cell with R, A, C, or I. Validate by row (one A?) and by column (no role with too many As, no role that's only ever I).

Extended

A responsibility assignment matrix marking each task or deliverable with who is Responsible (does the work), Accountable (owns the outcome — exactly one), Consulted (two-way input), and Informed (one-way update).

When used

When clarifying ambiguous ownership, especially across cross-functional teams or vendor boundaries.

Common confusions

  • vs. RASCI / RACI-VSVariants add Support, Verify, or Sign-off — same idea, more columns.
  • vs. Org chartAn org chart shows reporting; RACI shows decision rights per task.

Exam tip

Exactly ONE Accountable per row. Multiple A's = a broken RACI.

RACI Matrix
Techniques
Roles and Responsibilities matrix mapping stakeholders to tasks or deliverables as Responsible, Accountable, Consulted, or Informed. BABOK technique used to clarify hand-offs and approval authority across a process or project.
RADDRequirements Analysis and Design Definition
BABOK Core
Knowledge area abbreviation (KA 5) covering specifying and modeling requirements, verifying and validating them, and defining design options. Heaviest ECBA weighting (~30%).
Deep dive · extended definition + exam tip

Extended

Requirements Analysis and Design Definition (KA 5) structures elicited information into models, specifies and verifies requirements, validates them against business need, defines design options, and recommends a solution. It is the heaviest-weighted KA on the ECBA.

When used

After elicitation produces raw stakeholder input — RADD turns that input into specified, validated requirements and viable design options.

Common confusions

  • vs. Elicitation and CollaborationEC produces raw BA information; RADD analyses and structures it.
  • vs. Solution EvaluationRADD defines and recommends; Solution Evaluation measures the deployed solution's actual value.

Exam tip

ECBA questions about 'specify, model, verify, validate, define design options, recommend solution' all map to RADD — recognize those six verbs instantly.

Regression Testing
Process & Methodology
Re-testing of unchanged areas of a solution to ensure existing functionality still works after changes.
Regulator
Roles
Stakeholder responsible for defining and enforcing standards or rules that the solution must comply with.
Regulatory Requirement
Requirements
An externally imposed obligation from law, regulation, standard, or contract that the solution must satisfy (e.g., GDPR, HIPAA, SOX, PCI-DSS, WCAG, ISO 27001). Often realised as a mix of functional behaviour, NFRs, and constraints.
Deep dive · extended definition + exam tip

Components — what each part means

A defensible regulatory requirement names five things so audit can trace it end-to-end.

  1. Source

    The law, regulation, standard, or contract that imposes it — cited precisely, including clause/article.

    ExampleGDPR Article 17 — Right to Erasure.

  2. Obligation

    What the regulation requires the organisation to do or guarantee.

    ExampleOn verified request, erase a data subject’s personal data within 30 days.

  3. Scope

    Which data, processes, geographies, or user groups the obligation applies to.

    ExampleAll EU/EEA customers; all systems holding identifiable personal data.

  4. Realisation

    How the solution will meet it — typically a mix of FRs, NFRs, and constraints traced back to this source.

    ExampleFR: ‘Erase Account’ workflow. NFR: complete within 7 days. Constraint: backups purged on 30-day cycle.

  5. Evidence

    What artefact proves compliance to an auditor — logs, reports, certifications, sign-offs.

    ExampleImmutable audit log of every erasure request and outcome, retained for 6 years.

How they relate

Source justifies why; Obligation defines what; Scope bounds where; Realisation links to the FRs/NFRs/constraints that build it; Evidence proves it after the fact. Without Evidence, even a fully-built solution can fail audit.

How a BA uses it

Maintain a Regulatory Register separate from the backlog. Each entry traces forward to one or more solution requirements (so dev knows what to build) and forward to test cases plus operational evidence (so audit can verify it).

Extended

An externally imposed obligation that the solution must satisfy, originating in law (e.g., GDPR, HIPAA, SOX), industry regulation (PCI-DSS, MiFID II), accessibility or quality standards (WCAG, ISO 27001, ISO 9001), or contractual SLAs. Regulatory requirements cut across the BABOK types — they are usually realised as a mix of Functional behaviour, NFRs, and hard Constraints. They are non-negotiable: failure typically means fines, loss of licence, or contract termination.

When used

From day one of any initiative touching personal data, payments, health, finance, safety, public sector, or accessibility. Reviewed at every gate and at every change request.

Common confusions

  • vs. Non-Functional RequirementAn NFR is a quality target the business chooses (e.g., 99.9% uptime). A Regulatory Requirement is externally imposed — you don’t get to negotiate it down.
  • vs. ConstraintA Constraint restricts the solution (‘must use the existing Oracle DB’). A Regulatory Requirement says what the solution must achieve to be lawful — often realised through one or more constraints.
  • vs. Business RuleBusiness rules are owned and changeable by the business; regulatory rules are owned externally and only change when the law/standard changes.

Exam tip

If a question mentions a named law, regulation, standard, or accreditation (GDPR, SOX, HIPAA, PCI, WCAG, ISO) — it’s a Regulatory Requirement, even if it reads like an NFR.

Release Planning
Process & Methodology
The activity of grouping backlog items into releases that deliver coherent increments of value, balancing scope, capacity, dependencies, and stakeholder expectations.

Used in 1 place

Reporting
Data & Analytics
The systematic production and distribution of information about performance, status, or compliance to defined audiences on a defined schedule. Distinguished from dashboards by its retrospective, narrative orientation.
Requirement
Requirements
A usable representation of a need, focused on understanding what kind of value could be delivered if the requirement is fulfilled.
Deep dive · extended definition + exam tip

Components — what each part means

The six requirement types you will be asked to recognise — what each one is, where it lives, and how it relates to the others.

  1. 1

    Business Requirement

    Enterprise-level goal or outcome that justifies the change. Owned by the sponsor; sits in the business case.

    Example“Reduce month-end close from 9 days to 3 within 12 months.”

  2. 2

    Stakeholder Requirement

    What a specific role or group needs to be able to do. Bridges the business goal and the solution.

    Example“The AP clerk must be able to approve invoices from a mobile device.”

  3. 3

    Solution Requirement — Functional

    What the solution must do — behaviours, calculations, data it manages. Usually phrased ‘the system shall…’.

    Example“The system shall route invoices > €10,000 to a second approver.”

  4. 4

    Solution Requirement — Non-Functional (NFR)

    How well the solution must perform — quality attributes and constraints (performance, security, usability, availability).

    Example“95% of approval screens shall load in < 2s under 500 concurrent users.”

  5. 5

    Transition Requirement

    Temporary capability needed only to move from current to future state. Retires at go-live.

    Example“Migrate 24 months of historic invoices from the legacy AP system before cutover.”

  6. 6

    Regulatory Requirement

    Externally imposed obligation (law, regulation, standard, contract). Cuts across the other types — often realised as a mix of FRs, NFRs, and constraints.

    Example“All approvals shall be logged in an immutable audit trail for 7 years (SOX §404).”

How they relate

They form a layered chain: a Business Requirement is decomposed into one or more Stakeholder Requirements, each of which is realised by Solution Requirements (Functional + NFR). Transition Requirements wrap the cutover; Regulatory Requirements constrain every layer. A Requirements Traceability Matrix (RTM) links them top-to-bottom so any change at one level is visible at every other.

How a BA uses it

When triaging a new statement, ask in order: Is it an enterprise outcome (1)? A role’s need (2)? A system behaviour (3)? A quality target (4)? A go-live-only capability (5)? An external obligation (6)? The first ‘yes’ is its type. Then file it in the matching artefact and trace it up and down the chain.

Extended

BABOK v3 classifies every requirement into one of four core types — Business, Stakeholder, Solution (Functional + Non-Functional), and Transition — plus widely-recognised cross-cutting categories such as Regulatory and Constraint. The type tells you who owns it, what level of abstraction it lives at, where it sits in traceability, and when it retires. Mis-classifying a requirement is the single most common cause of scope drift and unbuildable specs.

When used

Every time you write, review, or sort a requirement so it lands in the correct artefact (business case, user story, NFR matrix, cutover plan, compliance register).

Common confusions

  • vs. DesignRequirements describe what stakeholders need; designs describe how the solution will meet them. The boundary is fluid, especially in agile.
  • vs. User StoryA user story is a format, not a requirement type — usually used to capture stakeholder or solution requirements.

Exam tip

Memorise the chain: Business → Stakeholder → Solution (Functional + NFR) → Transition. Regulatory and Constraint cut across all four. Many ECBA questions hinge on which type a sentence describes.

Retrospective
Process & Methodology
Scrum event where the team reflects on the past sprint and identifies improvements for the next one.
Rework Loop
Process & Methodology
Path in a process where work is returned to an earlier step due to defects or missing information; a key target for process improvement.
RFIRequest for Information
Process & Methodology
Document used to gather general information about vendor capabilities before issuing an RFP.

Used in 1 place

RFPRequest for Proposal
Process & Methodology
Document soliciting proposals from vendors for a product or service, with selection criteria.
RFQRequest for Quotation
Process & Methodology
Document inviting vendors to bid prices on specified products or services.

Used in 1 place

Risk
General BA
Uncertain event or condition that, if it occurs, has a positive or negative effect on objectives.
Risk Matrix
Techniques
Two-dimensional grid plotting risks by likelihood against impact, with cell colour denoting severity. Used to prioritise risk responses; meaning of axes and thresholds must be defined explicitly to support consistent assessment.
RLCMRequirements Life Cycle Management
BABOK Core
Knowledge area abbreviation (KA 3) for managing requirements and designs from inception through retirement, including tracing, prioritizing, and approving.
Deep dive · extended definition + exam tip

Extended

Requirements Life Cycle Management (KA 3) keeps requirements and designs consistent over time: tracing them, maintaining them through change, prioritizing, assessing changes, and approving. RLCM does NOT manage the project life cycle — only the requirements within it.

When used

Whenever requirements exist and could change — which is always. RLCM activities run in parallel with elicitation, analysis, and evaluation.

Common confusions

  • vs. BAPMBAPM plans how BA work will be done; RLCM manages the requirements artifacts produced.
  • vs. Project Life CycleRLCM tracks requirements; the project life cycle tracks the project itself (initiation → closure).

Exam tip

If a question mentions tracing, prioritizing, approving, or maintaining requirements — pick RLCM, not BAPM.

Roadmap
Process & Methodology
Time-oriented visual plan showing how a product, capability, or change will evolve across releases, quarters, or themes. Communicates direction and sequencing without committing to detailed dates.
ROIReturn on Investment
Techniques
Ratio measuring financial return relative to the cost of an investment, expressed as a percentage.
Roles and Permissions Matrix
Modeling
Matrix that maps user roles to the actions or data they are allowed to access.

Used in 1 place

RPARobotic Process Automation
Process & Methodology
Software 'robots' that mimic human interactions with systems to automate rule-based, repetitive tasks; a tactical option within BPM, not a substitute for redesign.
RTMRequirements Traceability Matrix
Requirements
A grid linking requirements to their origin, related requirements, design elements, and the test cases that verify them.

Used in 2 places

S

60
SAStrategy Analysis
BABOK Core
Knowledge area abbreviation (KA 4) for identifying business need, assessing capabilities, and defining the change strategy.
Deep dive · extended definition + exam tip

Extended

Strategy Analysis (KA 4) identifies the business need, assesses current and future state capabilities, identifies the gap, and defines the change strategy and solution scope. It justifies why a change is needed before requirements are detailed.

When used

Early in any initiative, and revisited whenever the business case or external context shifts materially.

Common confusions

  • vs. RADDSA defines the change at a high level (what & why); RADD details the requirements (how).
  • vs. Business CaseThe business case is one output of SA, not the whole KA.

Exam tip

Words like 'business need', 'capability gap', 'future state', and 'change strategy' are SA giveaways.

SaaSSoftware as a Service
General BA
Software licensing and delivery model in which software is hosted centrally and accessed over the internet.
SAMServiceable Available Market
Business & Strategy
Portion of the TAM that a company's products and services can realistically serve.
Scatterplot
Data & Analytics
Chart plotting two quantitative variables as points on Cartesian axes to reveal correlation, clusters, and outliers. The standard visual for exploring relationships between variables.
SCDSlowly Changing Dimension
Data & Analytics
Pattern for handling changes to dimension attributes over time (Type 1 overwrite, Type 2 history, Type 3 limited history).

Used in 1 place

Schema
Data & Analytics
Formal definition of the structure of data, including tables, fields, types, and relationships.

Used in 1 place

Scope
General BA
The boundaries of what a solution, product, or project will and will not include.
Scope Creep
General BA
Uncontrolled expansion of scope without corresponding adjustments to time, cost, or resources.
Scrum
Process & Methodology
Lightweight agile framework with defined roles (Product Owner, Scrum Master, Developers), events, and artifacts, organized into sprints.
Deep dive · extended definition + exam tip

Components — what each part means

The Scrum Guide defines exactly 3 accountabilities (roles), 5 events, and 3 artifacts. Nothing else is 'Scrum'.

  1. Role

    Product Owner

    Maximises product value. Owns the Product Backlog: ordering, clarity, and what is built next.

    ExampleDecides login is more valuable than dark mode this sprint.

  2. Role

    Scrum Master

    Servant-leader for the team and the wider org. Coaches Scrum, removes impediments, protects the team's focus.

    ExampleResolves a blocker with another department.

  3. Role

    Developers

    Cross-functional team that creates the Increment each sprint. Self-managing — decide HOW to build what the PO ordered.

    ExampleDesigner + engineers + tester collectively own delivery.

  4. Event

    Sprint

    The container event. A fixed-length time-box (≤1 month) inside which all other events occur and a usable Increment is produced.

    ExampleTwo-week sprints, back-to-back, no gaps.

  5. Event

    Sprint Planning

    Kicks off the Sprint. Team agrees the Sprint Goal and selects backlog items they believe they can deliver.

    Example8-hour max for a 1-month sprint.

  6. Event

    Daily Scrum

    15-minute daily sync for Developers to inspect progress toward the Sprint Goal and adapt the plan.

    ExampleSame time, same place, every working day.

  7. Event

    Sprint Review

    End-of-sprint inspection of the Increment with stakeholders. Backlog is adapted based on feedback.

    ExampleDemo + open conversation, not a status meeting.

  8. Event

    Sprint Retrospective

    Team-only event to inspect process, people, and tools, and commit to improvements for the next sprint.

    ExampleAction: shorten standups; revisit next retro.

  9. Artifact

    Product Backlog

    The single, ordered list of everything that might be needed in the product. Owned by the PO. Commitment: Product Goal.

    ExampleHundreds of items, top dozen refined and ready.

  10. Artifact

    Sprint Backlog

    The Sprint Goal plus the items selected for the sprint plus the plan to deliver them. Owned by Developers.

    ExampleUpdated daily as work progresses.

  11. Artifact

    Increment

    A concrete stepping-stone toward the Product Goal — usable, integrated, meeting the Definition of Done.

    ExampleA deployable build at the end of the sprint.

How they relate

Roles do the work, events create the cadence, artifacts make work and progress visible. Each artifact has a commitment (Product Goal, Sprint Goal, Definition of Done) that anchors transparency.

How a BA uses it

Use the breakdown to spot anti-patterns: missing Retrospective = no improvement loop; PO doesn't order the backlog = role gap; Increment isn't 'done' = artifact broken.

Extended

An Agile framework with three roles (Product Owner, Scrum Master, Developers), five events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Retrospective), and three artifacts (Product Backlog, Sprint Backlog, Increment).

When used

When delivering complex products iteratively in short, fixed-length sprints (typically 1–4 weeks).

Common confusions

  • vs. KanbanScrum uses fixed-length sprints; Kanban uses continuous flow with WIP limits.
  • vs. AgileScrum is one Agile framework, not a synonym for Agile.

Exam tip

3 roles, 5 events, 3 artifacts. Memorize them — Scrum-vocabulary distractors are common.

Scrum Master
Roles
Scrum role that serves the team by removing impediments and ensuring Scrum is understood and enacted.

Used in 1 place

SCVSingle Customer View
Data & Analytics
Consolidated, consistent record of all data an organization holds about an individual customer.

Used in 1 place

SDLCSoftware Development Life Cycle
Process & Methodology
Structured process used to plan, design, build, test, deploy, and maintain software.
Deep dive · extended definition + exam tip

Components — what each part means

Six logical phases every software product goes through, regardless of methodology. Waterfall does them once and in order; Agile does them in tiny loops, many times.

  1. 1

    Requirements

    Understand the problem and what the software must do — elicit, analyse, specify.

    ExampleBA workshops, user interviews, story writing.

  2. 2

    Design

    Decide how the software will be structured to meet the requirements — architecture, UX, data model.

    ExampleWireframes, ERDs, API contracts.

  3. 3

    Build

    Implement the design in code, configuration, and content.

    ExampleSprint development, code reviews.

  4. 4

    Test

    Verify it works as designed and validate it meets the need — unit, integration, system, UAT.

    ExampleQA cycles + UAT sign-off.

  5. 5

    Deploy

    Release the software into the target environment, including data migration, training, and cutover.

    ExampleProduction release with rollback plan.

  6. 6

    Maintain

    Keep the software healthy in operation: fixes, enhancements, support, eventual decommission.

    ExamplePatching, performance tuning, bug fixes.

How they relate

Waterfall = one big linear pass through phases 1–6. V-model = phases mirrored against testing. Iterative/Agile = phases 1–6 repeated in short cycles, many times per release.

How a BA uses it

Use SDLC to locate where you are in delivery and what BA artefacts belong there — requirements early, UAT late, change control throughout.

Extended

Software Development Life Cycle — the sequence of phases a software product passes through: requirements, design, build, test, deploy, maintain. SDLC is methodology-agnostic; Waterfall, V-model, iterative, and agile are all ways to traverse it.

When used

When discussing where BA work fits in software delivery, or scoping a BA approach across phases.

Common confusions

  • vs. WaterfallSDLC = the phases themselves; Waterfall = one specific way to sequence them (linear, gated).
  • vs. Project Life CycleProject life cycle covers initiation → closure; SDLC covers requirements → maintenance.

Exam tip

SDLC ≠ Waterfall. The exam may test that distinction directly.

SESolution Evaluation
BABOK Core
Knowledge area abbreviation (KA 6) for assessing solution performance and value and recommending improvements.
Deep dive · extended definition + exam tip

Extended

Solution Evaluation (KA 6) measures the value a deployed or partial solution delivers, identifies limiters and enablers, and recommends actions to increase value. It happens after — or alongside — implementation, not before.

When used

Post-deployment, during pilots, or after MVP releases to determine whether expected value is being realized.

Common confusions

  • vs. TestingTesting checks the solution against requirements; SE checks actual business value delivered.
  • vs. Strategy AnalysisSA defines the future state target; SE measures progress toward it.

Exam tip

Any question about measuring whether a deployed solution actually delivers value = SE.

Sequence Diagram
Modeling
UML diagram that shows how objects interact over time through ordered messages.
Sequence Flow
Modeling
BPMN connector showing the order in which tasks are performed within a single pool.
Service Blueprint
Modeling
Diagram extending a customer journey with the front-stage, back-stage, and supporting processes that deliver the service.
Service Level
Business & Strategy
A measurable commitment to a level of service performance (availability, response time, throughput, resolution time). The unit measured by service-level indicators and contracted in service-level agreements.
SIPOCSIPOC
Process & Methodology
High-level process framing showing Suppliers, Inputs, Process, Outputs, and Customers; used to scope a process before detailed modelling.
SITSystem Integration Testing
Process & Methodology
Testing performed to verify that integrated components or systems interact correctly.

Used in 1 place

Six Sigma
Process & Methodology
Data-driven methodology for reducing process variation and defects, often using the DMAIC improvement cycle.
SLAService Level Agreement
Techniques
Formal agreement defining the expected level of service between a provider and a consumer, including metrics and remedies.
SLIService-Level Indicator
Business & Strategy
A measured value of a service attribute (e.g. latency, uptime) compared against the SLO and SLA.

Used in 1 place

SLOService Level Objective
General BA
Specific measurable target for a service attribute, supporting the broader SLA.
SMARTSpecific, Measurable, Achievable, Relevant, Time-bound
Techniques
Criteria for writing clear, actionable objectives or goals.
Deep dive · extended definition + exam tip

Components — what each part means

Five tests an objective must pass to be useful for planning and measurement.

  1. S

    Specific

    Names exactly what will change, for whom, and where. No vague verbs like 'improve' on their own.

    Example'Reduce average call-handling time in the EU support centre' (specific) vs 'improve support' (not).

  2. M

    Measurable

    Has a metric and a baseline so you can tell if it's met. If you cannot count it, you cannot prove progress.

    ExampleFrom 6m 20s to 4m per call.

  3. A

    Achievable

    Realistic given resources, capability, and constraints. Stretching is fine; impossible is not.

    Example33% reduction is achievable with the new IVR rollout — 90% is not.

  4. R

    Relevant

    Connects to a real business need or strategic goal. If it's met, something that matters improves.

    ExampleLower handle-time supports the cost-to-serve OKR.

  5. T

    Time-bound

    Has a deadline. Without one, urgency disappears and progress can't be tracked.

    ExampleBy end of Q3 2026.

How they relate

S and M together let you measure; A and R together keep the goal sane and connected to value; T forces commitment. Drop one letter and the objective becomes wishful thinking.

How a BA uses it

Write the goal in one sentence and underline each SMART element. If you can't underline all five, rewrite — don't promote the goal until you can.

Extended

SMART is a five-criterion checklist for writing objectives, goals, and KPIs that can actually be tracked. Originally formalised by George Doran (1981); the letters have minor variants but the intent is constant.

When used

When defining business objectives, project goals, KPIs, OKRs, or success criteria for a change.

Common confusions

  • vs. INVESTINVEST tests user stories; SMART tests objectives/goals.
  • vs. KPIA KPI is the metric; SMART is the discipline that makes the KPI usable.

Exam tip

ECBA distractors often hide a non-measurable goal (e.g. 'improve customer experience') as a SMART objective — it isn't, because it has no metric or deadline.

Snowflake Schema
Data & Analytics
Variation of the star schema where dimension tables are normalized into multiple related tables.
SOAService-Oriented Architecture
General BA
Architectural style in which services are provided to other components over a network through standard interfaces.

Used in 1 place

Solution Requirement
Requirements
Capabilities and qualities of a solution that meet stakeholder requirements. Split into functional and non-functional.
Deep dive · extended definition + exam tip

Components — what each part means

Solution Requirements split into two sub-types. Every solution requirement is one or the other — never both.

  1. FR

    Functional Requirement

    What the solution does — behaviours, inputs, outputs, calculations, validations, workflows.

    Example“The system shall send an email confirmation within 30s of order placement.”

  2. NFR

    Non-Functional Requirement

    How well the solution does it — quality attributes such as performance, security, usability, availability, maintainability, portability, compliance.

    Example“The order confirmation email shall be delivered in < 60s for 99% of orders.”

How they relate

FRs answer ‘what’; NFRs answer ‘how well / under what conditions’. They are paired: most FRs need at least one NFR to be testable in production. Together they fully specify the solution’s required behaviour and qualities, and trace upward to Stakeholder Requirements and downward to Designs.

How a BA uses it

When writing or reviewing a spec, list FRs and NFRs in two columns. If an FR has no NFR next to it, ask ‘how fast / how secure / how reliable / how accessible’ — the gap is usually where production incidents happen.

Extended

A Solution Requirement specifies a capability or quality the solution itself must have to meet one or more Stakeholder Requirements. BABOK splits it into two sub-types — Functional (what it does) and Non-Functional (how well it does it). Solution requirements are the layer that developers, testers, and architects work directly from.

When used

During RADD, after stakeholder needs are stable, when translating role-level needs into specifications a delivery team can build and test.

Common confusions

  • vs. Stakeholder RequirementStakeholder reqs describe what a person needs; solution reqs describe what the system must provide.
  • vs. DesignSolution reqs describe required capabilities; designs describe the chosen mechanism for providing them.

Exam tip

If the question asks ‘what type of requirement is X’ and X reads ‘the system shall…’ or names a quality attribute, the umbrella answer is Solution Requirement (then split into FR or NFR).

Solution Scope
General BA
The set of capabilities a solution must deliver to meet the business need.
SOMServiceable Obtainable Market
Business & Strategy
Realistic share of the SAM a business can capture in the short to medium term.

Used in 1 place

SOWStatement of Work
Process & Methodology
Document defining the activities, deliverables, timelines, and acceptance criteria for project work.

Used in 1 place

Spiral Model
Process & Methodology
Risk-driven life cycle that combines iterative development with the systematic aspects of waterfall.
Sponsor
Roles
The stakeholder who authorizes the change and provides resources, funding, and high-level direction.

Used in 33 places

Sprint
Process & Methodology
Time-boxed iteration in Scrum, typically 1–4 weeks, that produces a potentially releasable increment.
Sprint Backlog
Process & Methodology
Set of product backlog items selected for a sprint, plus the plan to deliver them.
Sprint Planning
Process & Methodology
Scrum event at the start of a sprint where the team plans the work to be performed.
Sprint Review
Process & Methodology
Scrum event at the end of a sprint where the increment is inspected with stakeholders.
SQLStructured Query Language
Data & Analytics
Standard language for querying, manipulating, and managing data in relational databases.

Used in 1 place

SRESite Reliability Engineering
Process & Methodology
Discipline applying software engineering practices to operations problems, balancing reliability with feature velocity through SLOs and error budgets.

Used in 1 place

SSOTSingle Source of Truth
General BA
Practice of structuring information so that every data element is stored exactly once in an authoritative location.

Used in 1 place

Stakeholder
General BA
Any individual or group affected by, or who can affect, the change, the need, or the solution.
Stakeholder List, Map, or Personas
Techniques
Tools used to record stakeholders, visualize their relationships, and represent typical user types.
Stakeholder Map
Techniques
Visual representation of stakeholders and their relationships to the change, the solution, and one another. BABOK lists stakeholder maps among the outputs of stakeholder analysis; common forms include onion diagrams and matrix grids.
Stakeholder Requirement
Requirements
Needs of a stakeholder or stakeholder group that must be met to achieve a business requirement.
Deep dive · extended definition + exam tip

Components — what each part means

Three things every stakeholder requirement names so it can be turned into solution requirements.

  1. Role

    Who the stakeholder is — a job title, persona, or external party. Specific enough that someone in the room ‘owns’ it.

    ExampleLoan officer, not ‘user’.

  2. Need / Capability

    What that role must be able to do — usually a verb phrase, not a feature.

    ExampleApprove a loan application from outside the office.

  3. Rationale / Outcome

    Why they need it — the link back up to the business requirement.

    ExampleSo decisions aren’t blocked when officers travel to client sites.

How they relate

Role + Need defines scope; Rationale provides the trace up to a Business Requirement and the trace down to one or more Solution Requirements that realise the need. Drop the Rationale and you lose the ability to defend the requirement when scope is squeezed.

How a BA uses it

User stories (As a <Role>, I want <Need>, so that <Rationale>) are the most common shape. Use cases name the same Role as the primary actor.

Extended

Needs of a specific stakeholder or stakeholder group, describing what they must be able to do to interact with or use the eventual solution. They bridge business and solution requirements.

When used

After business needs are clear and before solution specification — typically captured as user stories or use case briefs.

Common confusions

  • vs. Business RequirementStakeholder reqs are role-specific; business reqs are enterprise-wide.
  • vs. Solution RequirementStakeholder reqs describe what a person needs; solution reqs describe what the system does.

Exam tip

Phrasing like 'as a <role>, I need to…' or 'the loan officer must be able to…' = Stakeholder Requirement.

Star Schema
Data & Analytics
Dimensional modeling pattern with a central fact table connected to descriptive dimension tables.
Start Event
Modeling
BPMN thin-bordered circle that triggers a process; can be none, message, timer, signal, conditional, or other event types.
Story Points
Techniques
Unitless measure of relative effort, complexity, and risk used to size user stories in agile.
Sub-process
Modeling
BPMN task that hides further detail and can be expanded into its own diagram; the standard way to manage diagram complexity.
Supplier
Roles
External stakeholder who provides products or services to the organization.
Survey or Questionnaire
Techniques
Set of written questions used to elicit information from a large group of stakeholders.
Swimlane Diagram
Modeling
Process diagram that uses lanes to show which actor or system is responsible for each step.
SWOTStrengths, Weaknesses, Opportunities, Threats
Techniques
Strategic analysis framework evaluating internal strengths and weaknesses, and external opportunities and threats.
Deep dive · extended definition + exam tip

Components — what each part means

A 2×2 grid: internal vs external on one axis, helpful vs harmful on the other.

  1. S

    Strengths (internal, helpful)

    Capabilities, resources, or advantages the organization controls and can build on.

    ExampleEstablished brand, skilled in-house data team.

  2. W

    Weaknesses (internal, harmful)

    Internal gaps, deficits, or disadvantages the organization needs to address or work around.

    ExampleLegacy systems, no mobile presence.

  3. O

    Opportunities (external, helpful)

    External trends or openings the organization could exploit. Future-facing.

    ExampleNew regulation favours digital onboarding.

  4. T

    Threats (external, harmful)

    External pressures or events that could damage the organization if ignored.

    ExampleNew entrant with venture funding undercutting price.

How they relate

Pair quadrants to generate strategy: S+O (use strengths to grab opportunities), W+O (fix weaknesses to unlock opportunities), S+T (use strengths to defend), W+T (avoid or mitigate).

How a BA uses it

Brainstorm into all four quadrants, then pair them to generate concrete strategic options — SWOT alone is just a list; the value is in the pairings.

Extended

A strategy technique pairing internal factors (Strengths, Weaknesses) with external factors (Opportunities, Threats) to inform strategic choices. Internal/external is the key axis — students often invert it.

When used

During Strategy Analysis to characterize current capabilities and external pressures before defining a change strategy.

Common confusions

  • vs. PESTLEPESTLE only covers external macro factors; SWOT covers internal + external.
  • vs. Risk AnalysisThreats are not the same as risks — risks are uncertain events; threats are existing external pressures.

Exam tip

If a stem says 'internal capability gap', think Weakness; 'new regulation', think Threat.

SWOT Analysis
Techniques
BABOK v3 strategy-analysis technique that classifies internal Strengths and Weaknesses against external Opportunities and Threats. Used to frame strategic options and inform the change strategy.

T

16
Takt Time
Process & Methodology
The pace at which a process must produce output to meet customer demand; available time divided by required units.
TAMTotal Addressable Market
Business & Strategy
Total revenue opportunity available if a product or service achieved 100% market share.
TCOTotal Cost of Ownership
General BA
Estimate of all direct and indirect costs of acquiring and operating a system over its life cycle.

Used in 1 place

Tester
Roles
Stakeholder responsible for verifying that the solution meets requirements and quality standards.

Used in 1 place

Theme
Process & Methodology
A high-level container that groups related epics, features, or backlog items around a common business objective. Used on roadmaps to communicate intent at a strategic level.
Theory of Change
Business & Strategy
A structured articulation of how and why a desired change is expected to occur, mapping inputs → activities → outputs → outcomes → impact, together with the assumptions linking each step. Used in strategy analysis and benefits realisation to make causal logic explicit and testable.
Three Amigos
General BA
Practice of bringing together a business representative, developer, and tester to discuss and clarify a story before development.
Three-Point Estimation
Techniques
Estimation using optimistic, most likely, and pessimistic values to derive a weighted average.
Time Series
Data & Analytics
A sequence of data points indexed in time order, typically at uniform intervals. Visualised with line charts to expose trend, seasonality, and anomalies.
To-Be Process
Process & Methodology
The future-state representation of a process after the planned change, used to drive transition requirements and acceptance criteria.
TOCTheory of Constraints
Process & Methodology
Management paradigm that views any system as limited by a small number of constraints and focuses improvement on identifying and elevating them.

Used in 1 place

TOMTarget Operating Model
Business & Strategy
The desired future-state operating model that supports a strategic change.

Used in 2 places

Transition Requirement
Requirements
Temporary capability needed only to move from current to future state, e.g., data migration, training, or parallel running.
Deep dive · extended definition + exam tip

Components — what each part means

Transition requirements typically fall into five families. A complete cutover plan names at least one in each.

  1. Data

    Migrating, cleansing, reconciling, or archiving data from the current to the future state.

    ExampleMigrate 24 months of historic invoices; reconcile totals to the cent before cutover.

  2. Training

    Equipping users, support staff, and partners to operate the new solution.

    ExampleDeliver role-based training to 220 AP clerks; publish a 1-page change comms 2 weeks before go-live.

  3. Ops Readiness

    Standing up support, runbooks, monitoring, and on-call before the new solution carries production load.

    ExampleL1/L2 runbooks signed off; on-call rota staffed for 2 weeks of hypercare.

  4. Parallel Run

    Running old and new together to validate output and de-risk cutover.

    ExampleRun legacy and new approval engines in parallel for one month-end close; reconcile differences.

  5. Decommission

    Retiring the legacy system, contracts, licences, and data once cutover is proven.

    ExampleDecommission legacy AP servers 90 days post-cutover; export and archive audit data.

How they relate

Data and Parallel Run de-risk the switch; Training and Ops Readiness make it survivable on day one; Decommission closes it out. Skip any family and the project either fails to cut over or carries permanent shadow IT.

How a BA uses it

Open a separate Transition Requirements register at the start of cutover planning. Each item retires once met — explicitly mark it ‘closed’ rather than letting it leak into operational backlog.

Extended

Capabilities the solution must have, and conditions it must meet, to facilitate the transition from current to future state — for example data migration, training, parallel running, or decommissioning. They are temporary by nature: once the transition completes, they're retired.

When used

When planning go-live, cutover, migrations, or rollout. They sit between solution requirements and operational handover.

Common confusions

  • vs. Solution RequirementSolution reqs persist for the life of the solution; transition reqs end at go-live.
  • vs. Project Plan tasksTransition reqs are capabilities the solution must enable; the plan tasks are how the team delivers them.

Exam tip

Anything labeled 'data migration', 'user training', 'parallel run', or 'decommission legacy' = Transition Requirement.

Transition State
General BA
Intermediate state between current and future state during the change.
Trend
Data & Analytics
The general direction in which a measure is moving over time, separated from short-term fluctuation and seasonality. Identified through time-series analysis and used to forecast future performance.

U

9
UATUser Acceptance Testing
Process & Methodology
Final testing performed by end users to validate that the solution meets their business needs.
UIUser Interface
General BA
The visual and interactive elements through which a user interacts with a product.
UMLUnified Modeling Language
Modeling
Standardized general-purpose modeling language used to specify, visualize, and document software systems.
Deep dive · extended definition + exam tip

Extended

Unified Modeling Language is a software-modeling notation maintained by OMG. The diagrams BAs encounter most are use case, activity, class, sequence, and state diagrams.

When used

When specifying solution behavior or structure for a software audience, or to support technical design discussions.

Common confusions

  • vs. BPMNUML models software systems; BPMN models business processes.
  • vs. ERDClass diagrams resemble ERDs but model behavior + data; ERDs only model data.

Exam tip

Use case diagrams = actors + use cases + system boundary. Don't confuse them with use case descriptions (the text).

Underlying Competencies
BABOK Core
Behaviors, characteristics, knowledge, and personal qualities supporting the practice of business analysis (per BABOK v3).
Unit Testing
Process & Methodology
Testing of individual code units in isolation, typically performed by developers.
Use Case Diagram
Modeling
UML diagram that shows actors, use cases, and their relationships within a system boundary.
User Story
Requirements
Short description of functionality from a user's perspective, typically: As a <role>, I want <goal>, so that <benefit>.
Deep dive · extended definition + exam tip

Components — what each part means

A user story has TWO breakdowns to know: the sentence template (Role / Goal / Benefit) and the 3 Cs (Card / Conversation / Confirmation).

  1. Role

    As a <role>

    Who needs this — a specific user persona, not 'the system' or 'the business'. Anchors the story in a real human need.

    ExampleAs a returning customer…

  2. Goal

    I want <goal>

    What they want to do — described as outcome, not solution. Avoid UI verbs like 'click' or 'press'.

    Example…I want to reorder a previous purchase…

  3. Benefit

    So that <benefit>

    Why it matters — the value delivered. If you cannot fill this in, the story may not be valuable enough to build.

    Example…so that I can reorder my usual items in seconds.

  4. C₁

    Card

    The physical or digital token holding the short story text — small on purpose, to force conversation rather than over-specification.

    ExampleIndex card with the story sentence.

  5. C₂

    Conversation

    The shared discussion between PO, team, and stakeholders that turns the card into shared understanding. Where the real requirement lives.

    ExampleRefinement workshop where edge cases surface.

  6. C₃

    Confirmation

    The acceptance criteria that prove the story is done — written before development, verified after.

    ExampleGiven a returning customer with prior orders, when they pick 'reorder', then the basket is pre-filled.

How they relate

The sentence sits on the Card; the Card triggers the Conversation; the Conversation produces the Confirmation. Skip any of the three and the story degrades — to a vague wish, a thrown-over-the-wall spec, or undeliverable work.

How a BA uses it

Write the sentence first, then refine with the team to extract acceptance criteria. Validate the story against INVEST before pulling it into a sprint.

Extended

A user story is a short, user-centred description of a piece of functionality, written in a fixed template and accompanied by acceptance criteria. It is a placeholder for a conversation, not a complete specification.

When used

Across Agile delivery — to capture stakeholder/solution requirements at a size the team can deliver in a single sprint.

Common confusions

  • vs. Use CaseUse cases describe full actor-system interactions step by step; stories are smaller, conversational, and pair with acceptance criteria.
  • vs. EpicAn epic is a large story that doesn't yet fit a sprint; you split it into multiple stories.

Exam tip

ECBA distractors often confuse stories with use cases or with requirements documents — remember: story = format + conversation + confirmation, not a spec.

UXUser Experience
General BA
The overall experience a person has when interacting with a product, system, or service.

V

8
V-Model
Process & Methodology
Variation of waterfall in which each development phase has a corresponding testing phase, drawn as a V.
Validated Requirement
Requirements
A requirement confirmed to deliver business value and meet a stakeholder need (built the right thing).
Value Proposition
Business & Strategy
Clear statement of the benefits a product or service delivers to a customer segment, and why it is better than alternatives.

Used in 1 place

Value Stream
Business & Strategy
End-to-end set of activities that delivers a specific result of value to a stakeholder, used in lean and business architecture.
Velocity
Process & Methodology
Average amount of work (often in story points) a Scrum team completes per sprint, used for forecasting.
Verified Requirement
Requirements
A requirement confirmed to be well-formed, clear, and of high quality (built right).
VoCVoice of the Customer
Business & Strategy
Structured collection of customers' explicit and implicit needs, expectations, and preferences.

Used in 1 place

VSMValue Stream Map
Process & Methodology
Lean visualisation of the steps, lead time, and value-add ratio of an end-to-end process from trigger to value delivered.

W

6
Waterfall
Process & Methodology
Sequential SDLC model where each phase (requirements, design, build, test, deploy) is completed before the next begins.
WBSWork Breakdown Structure
Process & Methodology
Hierarchical decomposition of project work into manageable deliverables and work packages.

Used in 1 place

WIPWork in Progress
Process & Methodology
Items that have been started but not yet completed. Kanban systems impose explicit WIP limits per workflow column to expose bottlenecks, reduce cycle time, and improve flow.
Wireframe
Modeling
Low-fidelity sketch of a user interface layout focused on structure and content placement.
Workaround
General BA
Temporary or alternative method of achieving a task when the standard approach is unavailable or inadequate.

X

1
XORExclusive Gateway
Modeling
BPMN gateway that routes the token down exactly one outgoing path based on a condition; the most common decision shape.