Business Analyst English Vocabulary: 70 Essential Terms

Business Analysts sit at the intersection of business needs and technical delivery. They write, speak, and present in English constantly — requirements documents, stakeholder workshops, user stories, and process models. This guide covers the 70 terms you need to communicate confidently as a BA.

Requirements Types

Functional Requirement

A functional requirement describes what the system should do — a specific behaviour, feature, or function.

“The system shall allow users to reset their password via email.”

Non-Functional Requirement (NFR)

A non-functional requirement describes how the system should perform — quality attributes like performance, security, scalability, and usability.

“The login page must load in under 2 seconds for 95% of users.”

Business Requirement

A business requirement describes a high-level business need or goal — the why behind the project.

“The business requires a self-service portal to reduce support ticket volume by 30%.”

Constraint

A constraint is a restriction placed on the solution — technical, regulatory, time, or budget limits.

“The solution must comply with GDPR and be deployed on-premise.”

Assumption

An assumption is a statement considered true for planning purposes but not yet verified.

“Assumption: all users will have internet access during the pilot phase.”

Out of Scope

Out of scope explicitly lists what the project will not deliver — prevents scope creep.

“Mobile native apps are out of scope for this release.”

Requirements Documentation

BRD (Business Requirements Document)

A BRD is a formal document that captures the business objectives, stakeholder needs, and high-level requirements for a project. It is typically produced early in a project.

FRS (Functional Requirements Specification)

An FRS (also called SRS — Software Requirements Specification) is a detailed document describing each functional requirement, including inputs, outputs, and system behaviour.

Use Case

A use case describes an interaction between a user (actor) and the system to achieve a specific goal. It has a primary flow (happy path) and alternative flows (exceptions).

“Use Case: Place an Order. Actor: Registered Customer. Main Flow: 1. Customer selects items. 2. Customer proceeds to checkout…”

User Story

A user story is an informal, short description of a feature from the user’s perspective. Standard format: As a [role], I want [capability], so that [business value].

“As a project manager, I want to export reports to PDF, so that I can share them with stakeholders who don’t have system access.”

Acceptance Criteria

Acceptance criteria define the conditions a feature must meet to be accepted by the Product Owner. Often written as Given/When/Then (Gherkin) scenarios.

“Given I am on the login page, When I enter valid credentials, Then I am redirected to the dashboard.”

Business Rules

Business rules are policies or conditions that govern how the business operates and that the system must enforce.

“Business rule: A customer cannot place an order if their account balance is negative.”

Data Dictionary

A data dictionary is a reference document that defines each data field used in the system — its name, type, format, allowed values, and source.

Traceability Matrix

A traceability matrix links requirements to their source (business objectives) and to test cases. It ensures every requirement is tested and every test has a requirement.

Prioritisation Techniques

MoSCoW

MoSCoW is a prioritisation framework. Each requirement is categorised as:

Must have — critical; the project fails without it
Should have — important but not critical
Could have — nice to have if time allows
Won’t have — explicitly deferred to a future phase

“After MoSCoW analysis, the team agreed that two-factor authentication is a should have for the MVP.”

SMART

SMART criteria help write high-quality requirements: Specific, Measurable, Achievable, Relevant, Time-bound.

INVEST

INVEST is used to evaluate user stories: Independent, Negotiable, Valuable, Estimable, Small, Testable.

Process Modelling

BPMN (Business Process Model and Notation)

BPMN is a standardised graphical notation for modelling business processes using flow diagrams.

Key BPMN elements:

Start event — where the process begins (circle)
End event — where the process ends (filled circle)
Task — a unit of work (rounded rectangle)
Gateway — a decision point (diamond)
- Exclusive gateway (XOR) — only one path proceeds
- Parallel gateway (+) — multiple paths proceed simultaneously
- Inclusive gateway (O) — one or more paths based on conditions
Pool — represents an organisation or system
Lane / Swimlane — a subdivision of a pool representing a role or department
Sequence flow — shows the order of activities (solid arrow)
Message flow — shows communication between pools (dashed arrow)

“The approval process has an exclusive gateway — if the amount is over £10,000, it goes to the CFO lane; otherwise it goes directly to the finance lane.”

AS-IS Process

The AS-IS process documents the current state of a business process — how things work today, including pain points and inefficiencies.

TO-BE Process

The TO-BE process documents the future desired state — how the process will work after the solution is implemented.

Gap Analysis

A gap analysis compares the AS-IS and TO-BE states to identify what changes are needed.

“The gap analysis revealed three manual hand-offs that can be automated in the TO-BE process.”

Swimlane Diagram

A swimlane diagram organises process steps into horizontal or vertical lanes by role or department. It makes responsibility clear at a glance.

Elicitation Techniques

Elicitation

Elicitation is the process of gathering requirements from stakeholders. It is not passive — a skilled BA draws out unstated needs, resolves conflicts, and clarifies ambiguity.

Common elicitation techniques:

Interview — one-on-one structured or semi-structured conversation
Workshop / JAD session — collaborative group session (Joint Application Development)
Observation — watching users perform their tasks (job shadowing)
Questionnaire / Survey — gathering input from a large group
Document analysis — reviewing existing reports, forms, and procedures
Prototyping — using wireframes or mockups to surface requirements visually

Pain Point

A pain point is a specific problem or frustration experienced by users or the business with the current process.

“A key pain point was that approvers had to log into three separate systems to complete a single approval.”

Bottleneck

A bottleneck is a step in a process that restricts throughput — work piles up waiting for it to complete.

Workaround

A workaround is an unofficial fix or manual step that users do to compensate for a missing system feature. Workarounds are important to document — they reveal unmet needs.

Stakeholder Management

Stakeholder Register

A stakeholder register is a document listing all stakeholders, their roles, interests, influence level, and communication preferences.

RACI Matrix

A RACI matrix assigns responsibility for each task or decision:

Responsible — does the work
Accountable — ultimately answerable
Consulted — provides input
Informed — kept in the loop

SME (Subject Matter Expert)

An SME is a person with deep knowledge of a specific business area or process. BAs rely on SMEs during elicitation.

Sign-off

Sign-off means formal approval — a stakeholder reviews and formally accepts a document, requirement, or deliverable.

“We need sign-off from the legal team before we can finalise the data retention requirements.”

Scope Creep

Scope creep is the uncontrolled growth of project scope when new requirements are added without assessing the impact on time, cost, and resources.

“Adding the dashboard feature mid-sprint is scope creep — it wasn’t in the agreed backlog.”

Agile BA Vocabulary

Product Backlog

The product backlog is a prioritised list of all user stories, features, and bug fixes for a product. Owned by the Product Owner, refined regularly.

Epic

An epic is a large user story that cannot be completed in a single sprint. It is broken down into smaller stories.

“The ‘User Account Management’ epic was split into six user stories for the first two sprints.”

Story Mapping

Story mapping is a visual technique for arranging user stories along two dimensions: user journey (horizontal) and priority/detail (vertical). It helps teams understand the full product scope.

Definition of Done (DoD)

The Definition of Done is a checklist of criteria that must be met before a work item can be called complete. Example criteria: code reviewed, tests written, documentation updated, deployed to staging.

MVP (Minimum Viable Product)

An MVP is the smallest version of a product that delivers enough value to satisfy early users and validate assumptions.

Velocity

Velocity is the average number of story points a team completes per sprint. Used for forecasting.

Data Analysis Vocabulary

Data Flow Diagram (DFD)

A DFD shows how data moves through a system — sources, processes, data stores, and outputs. Useful for understanding integration points.

ERD (Entity-Relationship Diagram)

An ERD shows the entities in a system and the relationships between them. Used during data modelling.

Data Migration

Data migration is the process of moving data from one system to another — typically during a system replacement or upgrade. Requires data mapping, cleansing, and validation.

Data Validation Rule

A data validation rule constrains what data can be entered into a system — e.g., date format, allowed values, mandatory fields.

Useful Phrases for Business Analysts

In workshops:

“Could you walk me through the current process step by step?”
“What happens when X goes wrong?”
“Who is responsible for this step?”
“Is this always the case, or does it depend on Y?”

In requirements reviews:

“This requirement is ambiguous — can we make it measurable?”
“Is this a must-have or a should-have for the first release?”
“This conflicts with the constraint in section 4 — how should we resolve it?”

On sign-off:

“We need your sign-off on this requirements document by Friday.”
“Are there any open questions before we baseline these requirements?”

Practice

Ready to practise BA vocabulary? Try the Business Analyst Vocabulary exercise set — 5 exercises covering requirements terminology, BPMN, and elicitation phrases.

Explore the full Business Analyst learning path for exercises, interview prep, and recommended reading.