What does a fractional business analyst actually deliver?

Ask five people what a business analyst does and you will get five answers, most of them vague. That vagueness is a real commercial problem: it is hard to justify paying for a role nobody can describe in concrete terms.

So here is the concrete version. A business analyst turns intent into specifications precise enough to build from and to verify against. Everything below is an artefact you can hold someone to.

The actual deliverables

Business requirements document (BRD)

What the business needs and why, in terms a non-technical stakeholder can approve. Its job is to capture the problem and the constraints — not the solution. A good BRD makes it obvious when a proposed feature does not serve the stated need.

Product requirements document (PRD)

What gets built. Scope, behaviour, edge cases, what is explicitly out of scope. The test of a PRD is whether an engineer who was not in any of the meetings could build the right thing from it without asking clarifying questions.

User story map

The whole user journey laid out end to end, with the work needed at each step. This is the artefact that surfaces the steps everyone forgot — password reset, empty states, what happens when the payment fails. Those omissions are what turn a two-week estimate into six.

Acceptance criteria

Objective, testable conditions for each story. Not "the search should be fast" but "results return within 500ms for a catalogue of 10,000 items". Without these, "done" is an opinion, and QA has nothing to verify against.

Process models

Current-state and target-state workflows, documented and agreed. Most valuable when replacing an existing system, where the current process lives entirely in the heads of people who have done it for years.

Traceability

The mapping from business need to requirement to story to test. This is what lets you answer "why are we building this?" months later, and what stops half-finished initiatives lingering in the backlog forever.

Why this is not just "writing tickets"

Tickets describe tasks. Requirements describe intent and constraints. The difference shows up when something unexpected happens mid-build.

With only a ticket, an engineer hitting an edge case makes a judgement call with whatever context they have. Sometimes right, sometimes not, and nobody finds out until review. With requirements, the intent is written down, so the correct decision is usually derivable — and where it is not, it is visibly a question worth escalating.

Most rework is not an engineering failure. It is a decision made mid-build by someone who did not have the context to make it.

Do you need one?

A reasonable test: think about the last three things your team built that had to be substantially reworked. For each, ask whether the rework happened because the code was wrong, or because what was built did not match what was wanted.

If it is mostly the second, you have a requirements problem. Adding engineers will produce more rework, faster.

Why fractional works for this role

Business analysis is unusually well suited to fractional engagement, because the work is front-loaded. The heavy lifting happens before and early in a build — defining, mapping, specifying. Once standards are established and the team has templates and examples, ongoing effort drops considerably.

A permanent BA hired for that peak is underused afterwards. A fractional engagement matches the shape of the work: intensive during definition, lighter during steady state, and available again when the next major initiative starts.