What goes in a BRD versus an FRD versus a user story, and how do you decide which to produce?

Define each artefact by the decision it supports

The three documents are not three levels of detail on one spectrum. Each exists because a different group of people needs to commit to something, and the artefact is the shape that commitment takes.

A business requirements document exists to support the investment decision. It answers why the organisation should spend money at all: the problem, the measurable business outcome, the scope boundary, the assumptions, the affected processes and the cost of doing nothing. Its audience is the sponsor and whoever governs the budget, and their signature means "this is worth funding and this is the outcome we will be held to". Nothing in a BRD should mention a screen or a field.

A functional requirements document exists to support the build-and-accept decision. It answers what the system must do to deliver that outcome: behaviours, rules, validations, states, interfaces, error handling. Its audience is delivery — architects, developers, testers — and increasingly a supplier. Signature here means "we can build this, and we agree this is what acceptance will be measured against". This is the artefact whose existence a fixed-price contract usually depends on.

A user story exists to support the next-sprint decision. It is one vertically sliced, independently valuable, testable piece of behaviour, with acceptance criteria that define done. Its audience is the team, and it is not signed off in any contractual sense at all — it is accepted by a product owner at review and then largely stops mattering, because the working software has replaced it.

The same requirement in all three forms

Artefact	How it reads	Who signs it
BRD	Expense reimbursement currently takes an average of eleven working days, which drives the largest category of finance helpdesk contacts. Reduce median approval time to under two working days by Q3 without increasing the rate of incorrectly approved claims.	Finance director as sponsor
FRD	On submission, a claim under the delegated limit routes automatically to the line manager; over the limit it routes to the manager and then to Finance. If the approver takes no action within 48 hours the claim escalates to their manager. Rejections require a reason code, and any change to a submitted claim resets the approval chain.	Delivery lead and test lead
User story	As a claimant I want to see where my claim is in the approval chain so that I do not have to chase Finance. Acceptance criteria: a submitted claim shows the current approver and the time waiting; an escalated claim shows both the original and current approver; a rejected claim shows the reason code.	Product owner, at review

Read down that column and the relationship is clear. The story is not a compressed FRD. It is one thin slice through a business objective, and the FRD's routing rules will surface across several such slices as acceptance criteria.

What actually happens in agile

In an agile delivery the honest position is that most BRD content survives and the FRD largely disappears. The BRD's substance — the problem, the measurable outcome, the scope boundary — becomes the product goal, the roadmap and the business case, because a team still cannot prioritise without knowing what outcome it is buying. The document form may go; the content does not.

The FRD is the artefact that genuinely dissolves. Its rules end up distributed across acceptance criteria, examples in refinement conversations, and automated tests. That is often an improvement, because a rule expressed as an executing test cannot drift out of date the way a rule in a Word document can. Say this plainly. Candidates who defend the FRD as a document rather than as content sound like process administrators, and candidates who dismiss it entirely have usually never been on a project that was audited or disputed with a supplier.

Traceability is the real loss

The capability that disappears is not detail. It is the ability to answer a backwards question: given this behaviour in production, which requirement caused it, whose objective did it serve, and who approved it. A requirements traceability matrix links objective to requirement to design to test to change request, and it is what lets you assess an impact, prove test coverage against agreed scope, and satisfy an auditor in a regulated domain.

A backlog gives you forward flow but poor backward reach. Stories are closed and archived, epics are reorganised, and six months later the rule about resetting the approval chain exists only in code and in one closed ticket nobody can find. You can rebuild most of this cheaply — persistent epics or a feature register that survives the sprint, story-to-test links maintained in the tooling, and a decision log for rules with a business rationale — but only if you decide to, because nothing in the process produces it for you.

What falls through the cracks

Non-functional requirements are the systematic gap. Performance under peak load, retention periods, accessibility, availability targets, auditability, data residency, security posture — none of these belong to a single user story, so in a story-only process they belong to nobody. They surface at the worst possible moment, in penetration testing, in a performance test the week before go-live, or in a compliance review.

The workable fixes are a definition of done that carries the cross-cutting ones, explicit stories or enablers for the rest with real acceptance criteria, and a short living document for the ones that are genuinely constraints rather than work items. Cross-process concerns are another version of the same problem: end-to-end flows spanning several teams have no owner in a backlog, which is why a process model or journey map earns its keep even where an FRD does not.

The trap

The trap is answering with template contents. Most candidates can list the sections of a BRD, and that listing is worth almost nothing because it is in every textbook. The distinguishing answer names the audience and the decision for each artefact, then commits to a position: in agile, keep the BRD's content and let the FRD become acceptance criteria, but deliberately reintroduce traceability and a home for non-functional requirements, because those are the two things the story format silently drops. A candidate who states which artefact they would drop and what they would rebuild to compensate is demonstrating judgement rather than recall.

Choose artefacts by the decision each one has to support and the person who has to sign it, then be explicit about what you are giving up: dropping formal documents costs you traceability and a home for non-functional requirements, and neither comes back by itself.