The Complete Business Analysis Glossary

Contents hide

1 Core Concepts

2 Planning

11 Frequently asked questions

12 Try Ash, Your Virtual BA

13 Further reading

When you are mid-project and a stakeholder drops a term that everyone in the room seems to understand except you, or when you need to explain something precisely to a developer or an executive who has no BA background, what you need is a solid business analysis glossary you can reach for without hesitation. This one covers 60 terms organised by category. Every definition is written for someone who is actively doing BA work, not studying for a certification exam. Use it as a reference, share it with your team, and come back to it whenever a term needs to be pinned down quickly.

I have worked across government, utilities, health, education, and enterprise environments for over 25 years. The terms below are the ones that come up constantly in workshops, stakeholder meetings, requirements reviews, and delivery conversations. Some of them are simple. Some of them look simple but cause real confusion when teams use them differently. I have flagged those ones.

Core Concepts

Business analysis: The discipline of identifying organisational needs and defining solutions that deliver value to stakeholders. It is not just about writing requirements; it is about understanding the problem before reaching for a solution.
Business analyst: Anyone who performs business analysis work, regardless of job title or industry. You do not need the words “business analyst” on your business card to be doing this work.
Business need: A problem or opportunity significant enough to warrant action at a strategic or operational level. This is the starting point for everything.
Stakeholder: Any individual or group with an interest in, or who is affected by, a change, need, or solution. Identifying all stakeholders early is one of the most important things you can do on any initiative.
Scope: The defined boundary of what is included and excluded from an initiative, solution, or area of analysis. Unclear scope is one of the leading causes of project failure, and managing it is a skill in itself. If scope creep is something you are actively dealing with, the Business Analyst Scope Creep and Governance guide covers the governance approaches that actually help.

Planning

Business case: A documented justification for a proposed initiative that compares expected benefits against costs, risks, and effort. A well-written business case gives decision makers everything they need to say yes or no with confidence.
Assumption: A condition believed to be true for planning purposes but not yet verified. Assumptions need to be documented and monitored because when they change, your plans may need to change with them.
Constraint: A limitation that restricts the range of possible solutions or approaches and cannot be changed within the scope of the initiative. Budget, time, and technology are the most common sources.
Risk: An uncertain event or condition that, if it occurs, may affect the ability of an initiative to deliver its intended value. Risk management is a core BA skill, not just a project management one.
Prioritisation: The process of ranking requirements, features, or tasks by their relative importance so that the most valuable work is addressed first. This is where business value meets practical delivery.
RACI matrix: A responsibility assignment tool that defines whether each stakeholder or role is responsible, accountable, consulted, or informed for each activity or deliverable. It saves hours of confusion about who owns what.
Stakeholder analysis: The process of identifying all stakeholders and assessing their level of interest, influence, and expectations. Good stakeholder analysis prevents nasty surprises later in the project.

Elicitation

Elicitation: The process of drawing out, discovering, and capturing information about needs, requirements, and constraints from stakeholders and other sources. It is not the same as simply asking people what they want.
Interview: A structured or semi-structured conversation with one or more stakeholders used to elicit information, requirements, or opinions. One-on-one interviews often surface things that group sessions do not.
Workshop: A structured, time-limited collaborative session attended by selected stakeholders to achieve a specific goal such as defining requirements, resolving issues, or making decisions.
Requirements workshop: A structured, facilitated session that brings together key stakeholders to collaboratively define, refine, or prioritise requirements. It is one of the most efficient elicitation techniques available.
Brainstorming: A facilitated group technique for generating a wide range of ideas quickly, without immediate evaluation or criticism. The goal is quantity first, quality second.
Focus group: A guided discussion with a selected group of stakeholders designed to surface opinions, attitudes, and needs about a specific topic. It works well when you need to understand perceptions rather than gather facts.
Observation: An elicitation technique where you watch stakeholders perform their work in order to understand current processes and uncover unstated requirements. What people do and what people say they do are often very different things.
Facilitation: The skill of guiding a group through a structured process to help them reach a shared outcome efficiently and collaboratively. Great facilitation is what separates a productive workshop from an expensive meeting. For a practical look at how to apply this skill, the Business Analyst Facilitation Skills article goes into the specifics.

Requirements

This is the category where imprecise language causes the most downstream pain. I worked on a large government project, Project X, where the team was using “business requirement” and “functional requirement” interchangeably. When the development team delivered to what they understood, and the business signed off on something different, we spent three weeks in rework. The distinction below matters in practice, not just in theory.

Requirement Type	What It Describes	Who Cares Most
Business requirement	What the organisation needs to achieve and how it will measure success, independent of any solution	Executives, sponsors, project owners
Stakeholder requirement	What a specific stakeholder or group needs from a solution to achieve their goals	Subject matter experts, end users
Functional requirement	What a system must do: a specific behaviour, function, or capability it must provide	Developers, testers, solution architects
Non-functional requirement	How a system must perform: quality, security, performance, accessibility characteristics	Architects, operations teams, testers
Solution requirement	What a specific solution component must do or how it must perform to meet stakeholder needs	Delivery teams, solution designers

On Project X, the friction point came when the operations lead pushed back on the functional requirements we had documented, arguing that nobody had consulted her team about performance thresholds. She was right. We had captured functional requirements without capturing the non-functional ones alongside them, and the operations perspective had been missed entirely. We had to go back, run a second round of elicitation specifically targeting non-functional requirements, and revise the requirements architecture. The delay was avoidable. It would not have happened if we had been using these terms consistently from the start.

Acceptance criteria: Conditions that a solution, requirement, or deliverable must satisfy before a stakeholder will formally approve it. Without clear acceptance criteria, everyone has a different definition of done.
Requirements architecture: The structure that defines how requirements relate to and depend on each other across different levels and types within an initiative. It helps you see the whole picture, not just individual pieces.
Requirements management: The ongoing process of planning, tracking, and controlling requirements throughout the life of an initiative to ensure they remain accurate, complete, and aligned with business goals.
Requirements traceability: The ability to track each requirement from its origin through design, development, and testing to confirm it has been correctly implemented. Traceability is what allows you to assess the impact of a change.
Requirements validation: Confirming that requirements accurately reflect stakeholder needs and will deliver the expected business value if implemented. It answers the question: are we building the right thing?
Requirements verification: Checking that requirements are correctly written, complete, unambiguous, and of sufficient quality for the development team to act on them. It answers the question: are we building it right?
Business rule: A specific, testable directive that governs how the business makes decisions or carries out activities, and that is within the organisation’s control. Business rules are often hiding in people’s heads rather than documented anywhere.
Change control: A process for managing proposed changes to requirements or designs by assessing their impact before approval and implementation. Without it, scope creep becomes inevitable.

Analysis

Gap analysis: A comparison between the current state of a process, system, or capability and the desired future state, used to identify what needs to change. This is where you define the work.
Impact analysis: An assessment of the effects a proposed change will have on existing systems, processes, stakeholders, or project plans. This is what you do before you say yes to a change request.
Feasibility study: An assessment of whether a proposed solution or initiative is achievable within the technical, organisational, and financial constraints of the organisation.
Cost-benefit analysis: A technique that weighs the total expected costs of a proposed action against the total expected benefits to determine whether it is worthwhile.
Decision analysis: A technique for evaluating options and their potential outcomes to support sound decision-making under conditions of uncertainty.
Root cause analysis: A structured investigation used to identify the underlying cause of a problem, rather than addressing only its visible symptoms. Fixing symptoms without addressing root causes is one of the most common and costly mistakes in business improvement.
Decomposition: A technique that breaks a complex problem, system, or requirement into smaller, more manageable parts to aid understanding and analysis.
Benchmarking: A structured comparison of an organisation’s processes, products, or performance against recognised peers or industry standards to identify improvement opportunities.

Modelling

Process model: A visual or documented representation of the steps, decisions, inputs, and outputs that make up a business process. Process models make the invisible visible.
Use case: A description of how an actor interacts with a system to achieve a specific goal, including the main success path and any alternative or exception flows.
Use case diagram: A UML diagram that shows the actors involved in a system and the use cases they participate in, providing a high-level view of system functionality.
Actor: A person, device, or external system that interacts with a solution in a defined role. Identifying all your actors is the first step in use case modelling.
User story: A short description of a feature or capability written from the perspective of a user, typically following the format: as a role, I want to action so that benefit. User stories are the currency of agile delivery.
Prototype: A preliminary model of a solution, built to explore requirements or validate design decisions before full development begins. A prototype can save months of rework.
CRUD matrix: A table that maps user roles or processes against data entities, showing which roles can create, read, update, or delete each entity.
Fishbone diagram: A visual tool used in root cause analysis that organises potential causes of a problem into categories branching from a central issue. Also known as an Ishikawa or cause-and-effect diagram.

Process

Business process: A sequence of activities that transforms inputs into outputs to deliver value in response to a triggering event. Every organisation runs on business processes, whether they are documented or not.
SIPOC: A high-level process summary tool that captures the suppliers, inputs, process steps, outputs, and customers for a given process. It is one of the fastest ways to get shared understanding of a process in a room full of stakeholders.
Value stream mapping: A lean technique that visualises all the steps in a process from start to finish, including the time and resources consumed at each step, to identify waste and improvement opportunities.

Architecture

Business architecture: A structured description of an organisation’s current and future state, covering its goals, capabilities, processes, and the relationships between them.
Enterprise architecture: A comprehensive description of an organisation’s business processes, information systems, technology, people, and the relationships between them, used to guide strategic planning and change.
Capability: Something an organisation can do, combining its people, processes, technology, and information to achieve a purpose. Capability-based thinking shifts the conversation from systems to outcomes.

Agile

Adaptive approach: A delivery method where requirements and solutions evolve through iterative cycles, with decisions deferred until they are needed. The adaptive approach embraces change rather than trying to prevent it.
Iteration: A fixed, repeating cycle of work within which a defined set of activities is planned, executed, and reviewed. Iterations create a rhythm of delivery and regular opportunities to inspect and adapt.
Product backlog: An ordered list of work items, features, and requirements representing everything the team might build for a product, managed and prioritised by the product owner.

Testing

UAT (User Acceptance Testing): A testing phase in which end users verify that a solution meets their needs and satisfies the agreed acceptance criteria before it goes live. UAT is the final quality gate before a solution reaches production.

The terms in this glossary are not academic. Every one of them represents a conversation you will have, a document you will write, or a decision you will be asked to support on a real project. The more consistently you and your stakeholders use this language, the less time you spend untangling misunderstandings and the more time you spend doing actual analysis. If you are building out your broader BA knowledge, the Business Analyst Core Skills article is a good companion to this one for understanding where each of these terms fits into the work you are actually accountable for.

Frequently asked questions

What is a business analysis glossary?

A business analysis glossary is a structured reference of terms used in the business analysis profession, covering concepts across requirements, elicitation, modelling, planning, and delivery. It gives practitioners and their stakeholders a shared, precise language. Using consistent terminology reduces miscommunication and speeds up project work.

What are the most important business analysis terms to know?

The most foundational terms are business need, stakeholder, scope, elicitation, business requirement, functional requirement, acceptance criteria, and requirements traceability. These come up in virtually every BA engagement regardless of industry or methodology. Getting these right before you start a project saves significant rework later.

What is the difference between a business requirement and a functional requirement?

A business requirement describes what an organisation needs to achieve and how it will measure success, independent of any specific solution. A functional requirement describes what a system must do to meet those needs. Confusing the two is one of the most common causes of misaligned delivery between business teams and development teams.

What is requirements traceability in business analysis?

Requirements traceability is the ability to track each requirement from its origin through to design, development, and testing to confirm it has been correctly implemented. It allows you to assess the impact of any proposed change to a requirement. A requirements traceability matrix is the most common tool used to maintain this record.

What is elicitation in business analysis?

Elicitation is the process of drawing out, discovering, and capturing information about needs, requirements, and constraints from stakeholders and other sources. It goes beyond simply asking people what they want and includes techniques such as interviews, workshops, observation, and document analysis. Effective elicitation is one of the most critical skills a business analyst can develop.

Try Ash, Your Virtual BA

Every term in this glossary has a deeper story behind it: how it is applied in practice, how it connects to other concepts, and what it looks like in a real project context. Ash, the free virtual BA built specifically for business analysts, lets you explore any of these terms further, ask follow-up questions in plain language, and get answers grounded in real BA practice rather than textbook definitions. Whether you have just encountered a term in a meeting, need to explain one to a stakeholder, or want to understand how it applies to the work in front of you right now, Ash is built for exactly that. Try Ash Virtual BA.