Ask ten people what a Business Analyst does and you get ten answers: writes user stories, runs workshops, draws process diagrams, manages the backlog, tests the release. All of those happen. None of them is the job.
The job is narrower and harder than any of that. A Business Analyst converts what people want into something a team can build, test, and prove it has delivered. Everything else is a technique in service of that conversion.
The gap the role exists to close
A stakeholder says: "we need better reporting for the finance team."
That sentence is not wrong. It is simply not yet anything. A developer cannot build it. A tester cannot verify it. A delivery manager cannot tell you whether it is done. It has no boundary, no acceptance, and no way to fail.
Somebody has to sit between that sentence and the sprint board and produce the missing precision: which finance team, which decisions the report supports, which numbers must reconcile with which source, what happens when the data is incomplete, and how anyone will know the result is correct. That person is the Business Analyst.
A Business Analyst is accountable for the requirement being right, not for the software being built. Those are different jobs, and confusing them is the most common way the role goes wrong.
What the role is accountable for
Eliciting intent, not collecting requests
Stakeholders bring solutions. "Add a dropdown for region." Underneath is a need: someone is filtering by region manually and losing an hour a week. The dropdown may be the answer. It may not be.
Good elicitation moves backwards from the requested solution to the underlying problem, then forwards again to a solution the team can evaluate against alternatives. Workshops, interviews, and process mapping are the tools. The output is understanding, not a list.
Making the requirement testable
A requirement that cannot fail is not a requirement. If nobody can write a test that the system could plausibly not pass, the statement is a preference.
Compare these two:
| Statement | Testable? |
|---|---|
| The report should load quickly | No. Quickly is unbounded. |
| The report returns within 3 seconds for up to 50,000 rows | Yes. There is a number, a scope, and a way to fail. |
This is where most rework originates. A requirement that reaches a developer with the ambiguity intact does not stay ambiguous: it gets resolved silently, by whoever happens to be writing the code, according to whatever they assumed at the time. The assumption surfaces in testing, or in production, and the cost of the fix is now ten times what a five-minute conversation would have cost.
Defining acceptance before the work starts
Acceptance criteria are the contract. They say, in advance, what must be true for this requirement to be considered delivered. Written before development, they align four people. Written afterwards, they are a description of whatever got built.
Key takeaways
- A requirement that cannot fail a test is a preference, not a requirement.
- Acceptance criteria written after development are documentation, not agreement.
- Ambiguity does not survive to production, it gets resolved silently by whoever writes the code.
- The Business Analyst owns the requirement being right, not the software being built.
Holding the scope boundary
Scope does not usually collapse. It erodes, one reasonable addition at a time, each of which is genuinely sensible in isolation. The Business Analyst is often the only person positioned to see the aggregate, because they are the only one holding every requirement at once.
This is not a gatekeeping function. It is an information function: making the cost of an addition visible at the moment somebody proposes it, so the Product Owner can make a real decision rather than a default one.
Keeping the thread from intent to release
When a requirement changes in week six, someone has to answer: which stories does this touch, which tests are now wrong, which defects were raised against the old behaviour. That thread is traceability, and maintaining it is a Business Analyst responsibility even when a tool does the mechanical part.
Where it sits next to the other three roles
The four roles on a delivery team are not a hierarchy, and the handoffs between them are where most delivery problems actually live.
- Product Owner decides what is worth building and in what order. The Business Analyst makes it specific enough to act on.
- QA Engineer designs coverage that proves the requirement. If the requirement is vague, the coverage is guesswork.
- Delivery Manager needs to know what is in scope, what is covered, and what is ready. All three answers trace back to requirement quality.
- Business Analyst is the connective tissue: every other role consumes what this role produces.
That last point is why requirement quality is not a documentation concern. It is a delivery concern. A vague requirement does not cost you a bad document. It costs you a wrong build, a wrong test, and a release date nobody can defend.
The artefacts, and what each is for
- Business requirements. The problem, the affected users, the measurable outcome. Written in the language of the business, not the system.
- Functional requirements or user stories. Discrete units of behaviour, each independently valuable and small enough to finish.
- Acceptance criteria. The pass or fail conditions, agreed before development starts.
- Use cases or process flows. The paths through the system, including the ones nobody wants to think about: the failures, the timeouts, the partial data.
- Traceability links. Which requirement each story serves, which tests cover it, which defects relate to it.
Note what is absent from that list: volume. A forty page specification that nobody reads is worse than four pages that everybody does, because it creates the appearance of rigour without the substance.
The three common failure modes
Becoming a scribe. Writing down what stakeholders say, verbatim, and passing it along. This adds a delay and no precision. If the requirement arriving at the team is as ambiguous as the request that produced it, the role added nothing.
Becoming a designer. Deciding the solution, then writing requirements that describe it. This forecloses better options and, more damagingly, hides the actual need, so when the solution turns out to be wrong nobody can reconstruct what was really being asked for.
Losing the thread. Producing excellent requirements at the start and never revisiting them. By week eight the code, the tests, and the document describe three different systems, and the document is the one everyone stops trusting first.
Where to go next
If you are new to the role, the highest-leverage skill is not elicitation or modelling. It is writing acceptance criteria that a QA Engineer can turn into coverage without asking you a single clarifying question. Everything else compounds from there.