What business analysts do
The International Institute of Business Analysis defines the BA role as "enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders." That sentence is worth unpacking, because it contains three things that are often misunderstood: the BA enables change rather than executes it; they define needs rather than solutions; and the yardstick is value to stakeholders, not delivery to schedule.
By the end of this section- Describe the BA role in your own words.
- Explain what distinguishes the BA from a project manager and from a developer.
The BA sits in the middle
Every organisation runs projects and programmes that are meant to change something — a process, a system, a product, a way of working. Most of those efforts founder at the same point: nobody has a clear, shared understanding of what the problem actually is before people start designing the solution. That gap is where the BA lives.
In practical terms, the BA is the person who stands between a business problem and a working solution, ensuring that the solution addresses the real problem and not the assumed one. They translate between the people who understand the business context and the people who build or configure the solution. They hold the requirements, manage their evolution, and validate that what gets built actually delivers what was asked for.
Problems, not solutions
A BA who leads with solutions has failed at the first step. The discipline starts with thorough understanding of the current state — what is happening, why it is happening, what the business needs to be able to do differently — before any solution space is opened. This is harder than it sounds, because stakeholders typically come to a BA with a solution already in mind. The skill is to receive that input, acknowledge it, and then work backwards to the underlying need it is trying to address.
When a stakeholder says "we need X", ask "what would X allow you to do that you can't do now?" The answer to that question is the requirement. X may or may not be the right solution for it.
The six BABOK knowledge areas
The BABOK Guide — the Business Analysis Body of Knowledge, published by IIBA — organises BA work into six knowledge areas. A knowledge area is a cluster of related tasks and techniques, not a sequential stage. You move between them throughout an engagement.
The six knowledge areas- Business Analysis Planning and Monitoring
- Elicitation and Collaboration
- Requirements Life Cycle Management
- Strategy Analysis
- Requirements Analysis and Design Definition (RADD)
- Solution Evaluation
Business Analysis Planning and Monitoring
Plans the analysis work itself. Who are the stakeholders? What approaches and techniques will be used? How will requirements be traced and approved? This is the meta-work that makes everything else coherent.
Elicitation and Collaboration
Draws out needs from stakeholders through interviews, workshops, observation, document analysis and other techniques. The collaboration aspect is as important as the information-gathering — requirements that stakeholders haven't engaged with are requirements that will be contested later.
Requirements Life Cycle Management
Traces requirements from origin to implementation, manages changes, resolves conflicts, and ensures requirements are approved at the right points. Keeps the relationship between requirements and the delivered solution visible throughout.
Strategy Analysis
Examines the current state, defines the desired future state, identifies risks and constraints, and develops a change strategy. This is the knowledge area that connects BA work to organisational purpose.
Requirements Analysis and Design Definition (RADD)
Models, specifies, validates and verifies requirements. Translates stakeholder needs into the precise, actionable requirements that development teams can build from and testers can verify against.
Solution Evaluation
Assesses how well the delivered solution achieves the desired outcome. Did it actually deliver the value that was expected? This closes the loop — and is the knowledge area most often skipped.
Of the six knowledge areas, which one gets the least attention on projects you have been part of? What does that cost the organisation?
Knowledge areas are not stages
It is tempting to read the list above as a sequence — plan first, then elicit, then manage, and so on. BABOK is explicit that this is not how the work functions. A BA doing elicitation may discover information that requires revisiting the strategy analysis. A change to scope may trigger re-planning. Requirements life cycle management runs continuously throughout. The six knowledge areas are a taxonomy of work, not a Gantt chart.
BABOK perspectives
On top of the six knowledge areas, BABOK v3 introduces five perspectives. A perspective is a lens that shifts the emphasis of BA work depending on the context — but it does not replace the six knowledge areas. A BA working in an agile context still does strategy analysis and requirements life cycle management. They just do them differently.
Agile
Business Intelligence
Information Technology
Business Architecture
Business Process Management
Engagements focused on AI adoption typically draw most heavily on the Business Architecture and Business Process Management perspectives. The capability map tells you what the organisation does; process analysis tells you where AI can be applied and where it will create risk if applied carelessly.
What the BA is not
The BA role is frequently confused with adjacent roles. This matters because misaligned expectations lead to gaps — things nobody owns — or conflicts — two people trying to own the same thing. Being clear about the boundary is not about protecting territory; it is about ensuring the work gets done by the right person.
The problem definition. The BA owns the documented understanding of what the business needs and why.
Requirements. Elicitation, specification, traceability, change management, approval.
Acceptance criteria. The conditions under which a delivered solution will be accepted as fit for purpose.
Stakeholder relationships. Ongoing engagement with the people who have a stake in the outcome.
Solution validation. Verifying that what was built meets the requirements and delivers value.
The schedule. That belongs to the project manager. The BA feeds into it but does not own it.
The budget. Also the project manager's domain, informed by BA estimates of analysis effort.
The code or build. The developer owns the technical implementation.
Testing. The BA writes acceptance criteria; the QA function owns test execution. These are different activities.
The product roadmap. In product-led organisations, the product manager owns prioritisation decisions across releases. The line is blurred, but the distinction matters.
The BA vs the project manager
The project manager is accountable for delivering a piece of work within scope, time, and budget. They own the plan, the risks log, the team's capacity, and the stakeholder communications about progress. The BA is accountable for the quality of the requirements and the validity of the solution against those requirements. These are different accountability structures. On small projects, one person sometimes holds both — which is fine as long as they understand they are wearing two hats, not one.
The BA vs the developer
The developer owns the technical solution. A BA who drifts into specifying technical solutions is overstepping — their job is to specify what the solution must achieve, not how it should achieve it. Conversely, a developer who is allowed to define their own requirements has lost an important check. The separation exists for good reason.
The line with product management
In product-led organisations — software products developed iteratively, typically with a SaaS or platform model — the product manager often absorbs functions that would traditionally sit with a BA: customer discovery, requirements prioritisation, acceptance criteria. The BA function still happens; it is often just called something else. Understanding this helps BAs work effectively in product contexts rather than treating them as hostile territory.
Unit review
Two questions to check what you've taken from this unit, followed by a reflection prompt.
According to BABOK v3, which knowledge area assesses whether a delivered solution achieved the expected business value?
A project manager tells the BA to stop producing requirements documentation and focus on writing test cases. What is the most accurate response?
Think about a change initiative you have been involved in — as a participant, a stakeholder, or someone affected by it. Which part of the BA function was absent or under-resourced? What were the consequences?
End of Course 01
You should now be able to describe the BA role, place it within the BABOK knowledge area structure, and explain clearly what distinguishes it from the PM, developer, and QA functions. Continue with Course 02: Strategy and Architecture.