Business Analysts vs Functional Analysts: Roles in the AI Era
Business analyst vs functional analyst: what each actually does, how the two roles split, and what AI changed about both. A practical guide for UK delivery teams.
By Ivan Pylypchuk, CEO of SoftBlues. Has led Claude and automation projects for finance, legal and healthcare teams across the UK and Ireland. Last updated: 29 July 2026.
The two job titles overlap enough that most companies use them interchangeably, and then discover on a project that they hired the same person twice and left a gap. The distinction is simple once you see it: a business analyst decides what problem is worth solving, a functional analyst decides how the system should behave to solve it.
SoftBlues is an AI consultancy at softblues.io, working with regulated mid-market companies across the UK and Ireland. We run this split on our own delivery teams, and AI has changed what each role spends its day doing more than it has changed the division between them.
A business analyst works between the business and the project, gathering requirements, building the case, defining success and managing stakeholders. A functional analyst works between the requirements and the build, turning agreed intent into specific system behaviour: process flows, data models, acceptance criteria, edge cases. On a small project one person does both. On anything complex, splitting them is what stops a team building the wrong thing correctly.
Key facts
What does a business analyst actually do?
The business analyst''s job is to make sure the thing being built is worth building.
That means talking to the people who own the process, understanding what it costs today, and working out what changing it would be worth. It means writing the business case, defining what success looks like in numbers, and holding scope when someone senior wants to add something in week six. It means being the person who can say "that would be nice, and it is not why we funded this".
The output is a decision and a direction: this problem, this value, these constraints, this definition of done.
What does a functional analyst actually do?
The functional analyst''s job is to make sure the thing that gets built matches what was agreed.
That means turning intent into behaviour. What are the states this record can be in? What triggers a transition? What happens on the unhappy path? Which fields are mandatory, and what validates them? Who sees what? What are the acceptance criteria a tester can run?
The output is a specification precise enough that two engineers reading it build the same thing.
Business analyst vs functional analyst, compared
| Business analyst | Functional analyst | |
|---|---|---|
| Owns | The problem and its value | The specification and system behaviour |
| Talks to | Stakeholders, sponsors, process owners | Engineers, testers, architects, the BA |
| Main output | Business case, requirements, success measures | Process flows, data models, acceptance criteria |
| Answers | Should we build this, and what is it worth? | Exactly how should it behave? |
| Fails by | Building something nobody needed | Building the right thing with the wrong rules |
| Needed most | Before funding and at every scope decision | From design through to user acceptance testing |
What AI actually changed about both roles
Less than the job adverts suggest, and more than most teams have adjusted for.
Documentation stopped being the bottleneck. Drafting a requirements document, a process flow or a first-cut set of acceptance criteria used to take days. It now takes an afternoon with a good model and a careful reviewer. The work that remains is the work that was always the valuable part: deciding what is true, what matters and what to leave out.
Discovery got faster and shallower. A model can summarise fifty stakeholder interview transcripts in minutes. It cannot notice that the operations manager went quiet when you asked about the approval step. The analyst who treats the summary as the finding rather than as the starting point is the one who misses the real requirement.
Functional analysis got harder, not easier. This is the part teams underestimate. A deterministic system has a finite set of behaviours you can enumerate. An AI-enabled system has a confidence threshold, a fallback, an escalation path and a human review step, and somebody has to specify all of them. What happens when the model extracts a supplier name it is 60% sure about? Who approves it? What gets logged? That is functional analysis, and skipping it is why pilots stall before production.
A new question joined the business analyst''s list. Not just "is this worth building", but "does this need a model at all". Plenty of processes that get proposed as AI projects are rules problems with bad data underneath. We wrote about that split in AI agents vs RPA for mid-market operations.
Do you need both roles on an AI project?
Depends on size, and on how much judgement the system carries.
One person, both hats, works for a project under about three months with a single stakeholder group and a clear problem. Splitting the role there just adds a handover.
Both roles pay for themselves once you have several stakeholder groups, a regulated process, or a system that makes decisions a person might have to defend. In regulated work the functional analyst is doing something closer to control design than to documentation: defining the approval points, the audit trail and the human review, which is exactly what a regulator will ask about.
The failure mode we see most is a project with a strong business analyst and no functional analyst. Everyone agrees on the goal, nobody has written down what the system does when the input is ambiguous, and the build stalls in user acceptance testing while people argue about behaviour that was never specified. For AI systems specifically, we set out where the human belongs in human-in-the-loop AI workflows.
What to look for when hiring either role in 2026
For a business analyst, the differentiator is no longer requirements-gathering technique, because the documentation load has collapsed. It is judgement: can they tell you what not to build, and will they say so to a sponsor.
For a functional analyst working on AI systems, ask how they specify uncertainty. A candidate who has only specified deterministic systems will write you a beautiful happy path and no confidence thresholds. Ask them to talk you through what their spec says when a model is unsure.
For both, ask how they use AI in their own work and what they check afterwards. The honest answer involves a review step. The answer you do not want is either "I do not use it" or "it writes the requirements".
If you are building this capability rather than buying it in, our view on what an AI-fluent team looks like is at hire AI experts.
Frequently asked questions
What is the main difference between a business analyst and a functional analyst?
A business analyst owns the problem: what should be built, why, and what it is worth. A functional analyst owns the specification: exactly how the system must behave to solve that problem. The handover is the point where a business goal becomes a set of system rules.
Can one person do both roles?
Yes, on smaller projects, and it is often the right call under about three months with one stakeholder group. Beyond that the two jobs pull in different directions, because one is looking outward at the business and the other inward at the system, and doing both well at the same time is rare.
Which role is more senior?
Neither, though business analysts more often sit closer to the sponsor and so appear more senior on an organisation chart. They are different disciplines rather than steps on one ladder, and strong functional analysts are harder to hire.
Has AI made business analysts redundant?
No, though it has removed a large part of what they used to spend time on. Drafting documents, summarising interviews and producing first-cut process flows are all much faster now. Deciding what matters, holding scope and telling a sponsor no are not tasks a model does for you.
Do AI projects need a functional analyst?
More than conventional projects do. An AI system has confidence thresholds, fallbacks, escalation paths and human review steps that all have to be specified, and none of them exist in a deterministic system. At SoftBlues that specification work is where a good part of the design effort goes.
What does a functional analyst produce on an AI project?
Process flows including the unhappy paths, data models, confidence thresholds and what happens below them, escalation and human approval rules, audit and logging requirements, and acceptance criteria a tester can actually run against a probabilistic system.
Should we hire these roles or use a partner?
If you run continuous change, hire. If you need one system live and do not yet have the roles, a partner brings both with the delivery team and you avoid recruiting for a capability you cannot yet assess. SoftBlues includes both functions in a fixed-price build rather than billing them separately.
Getting the split wrong is quiet and expensive: the project agrees on the goal, never agrees on the behaviour, and stalls in testing. If you are scoping an AI project and want a second read on whether the specification is actually specified, book a discovery call. SoftBlues is a registered Anthropic Partner Network member and a Google Cloud Partner, and we put working systems into production in 90 days at a fixed price.
See it in production
Systems we have built and run for clients, with the numbers that came out of them.
Related Articles
How to Choose an AI Consulting Firm in the UK: A 12-Point Buyer's Checklist
Short vs. Full Discovery Phase: Which Suits Your Project?
