Business Analysis Glossary
Business analysis has its own language. Whether you are just starting out in the profession or you have been practising for years, having a solid grasp of the core terminology makes you a more effective communicator, a sharper thinker, and a more credible professional in every stakeholder conversation you have.
This glossary covers 60 essential business analysis terms, organised by category, with plain language definitions and practical examples for each one. Bookmark it, share it with your team, and come back to it whenever you need a quick reference.
Core Concepts
Business analysis The discipline of identifying organisational needs and defining solutions that deliver value to stakeholders. Business analysis 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 business analysis work.
Business need A problem or opportunity significant enough to warrant action at a strategic or operational level. The business need is the starting point for everything a BA does.
Stakeholder Any individual or group with an interest in, or who is affected by, a change, need, or solution. Identifying all your stakeholders early is one of the most important things a BA 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.
Planning
Business case A documented justification for a proposed initiative that compares expected benefits against the costs, risks, and effort involved. 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 they can change, and when they do, 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 common sources of constraint.
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. Prioritisation 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. A RACI matrix 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 in relation to an initiative. 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. Elicitation 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. Requirements workshops are one of the most efficient elicitation techniques available to a BA.
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. Focus groups work well when you need to understand perceptions rather than gather facts.
Observation An elicitation technique where the business analyst watches 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.
Requirements
Business requirement A statement describing what an organisation needs to achieve and how it will measure success, independent of any specific solution. Business requirements answer the question: what problem are we solving?
Stakeholder requirement A statement of what a specific stakeholder or group of stakeholders needs from a solution in order to achieve their goals. Stakeholder requirements bridge the gap between business requirements and solution design.
Solution requirement A requirement that describes what a specific solution component must do or how it must perform in order to meet stakeholder needs.
Functional requirement A requirement that specifies what a system must do, describing a behaviour, function, or capability it must provide. Functional requirements define the features.
Non-functional requirement A requirement that defines the quality, performance, or operational characteristics a solution must have, rather than what it must do. Performance, security, and accessibility are common non-functional requirement categories.
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. Requirements architecture 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 The process of confirming that requirements accurately reflect stakeholder needs and will deliver the expected business value if implemented. Validation answers the question: are we building the right thing?
Requirements verification The process of checking that requirements are correctly written, complete, unambiguous, and of sufficient quality for the development team to act on them. Verification 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 change control, 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. Gap analysis 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. Impact analysis 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 diagram 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. SIPOC is one of the fastest ways to get a 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.
Using this glossary
Business analysis terminology is not just vocabulary. It is a shared language that allows you to communicate precisely with developers, project managers, executives, and subject matter experts. The more fluent you become in this language, the more effectively you can do your job.
If you want to go further than a definition, the terms in this article are all available in Ash, a free virtual BA built specifically for business analysts. On Ash you can browse each term with its definition and a working example, and ask the built-in AI agent follow-up questions in plain language.
Whether you are preparing for an interview, upskilling in a new area, or just trying to make sense of a term you have heard in a meeting, Ash is designed to give you practical, jargon-free answers on demand.
Explore the full glossary and ask Ash a question at ash.businessanalyststoolkit.com
Sam Cordes is a senior business analyst with over 30 years of experience across government, utilities, education, and mining. She is the founder of Ash, a free AI-powered BA knowledge tool for business analysts at every stage of their career.