BRD, FRD, and TRD

Three documents, one chain

A project moves from an idea someone can justify to a system someone can build, and it usually passes through three documents on the way. Each one answers a single question, written for a different reader, at a different level of detail: why, then what, then how.

The BRD is a business case. The FRD is a contract about behaviour. The TRD is a plan for construction.- the one-line version

The order matters more than the format. Each document narrows the one above it: the BRD sets the boundary of what is worth doing, the FRD defines observable behaviour inside that boundary, and the TRD chooses the technology that produces that behaviour. Skip a level and you get the two classic failures - a beautifully engineered system nobody asked for, or a business goal that quietly turns into whatever the first available engineer felt like building.

BRD - the business case

The Business Requirements Document is written first, usually by a business analyst or product owner working with the sponsor who controls the budget. It exists to answer one question honestly: is this problem worth solving, and what does solving it look like?

A usable BRD contains:

• Problem statement. What is broken or missing today, described in business terms and, where possible, with a number attached.
• Objectives and success metrics. The measurable outcome - a conversion rate, a cost, a cycle time - not a feature list.
• Stakeholders. Who is affected, who decides, who pays.
• Scope and out of scope. The second half is the important one; it is the sentence you point at eight weeks later.
• Constraints and assumptions. Budget, deadline, regulation, existing contracts, what you are taking on faith.
• High-level requirements. Numbered business needs - BR-1, BR-2 - that everything downstream will refer back to.

The discipline of a BRD is what it leaves out. No screens, no field names, no database choices. If a sentence could only be written by someone who already knows the solution, it belongs in a later document.

FRD - the behaviour

The Functional Requirements Document translates each business need into behaviour the system must exhibit. It is still solution-agnostic about technology, but it is completely specific about outcomes. The test for a good functional requirement is simple: can a tester read this line and write a test case from it without asking a question?

An FRD typically carries:

• Actors and roles. Who interacts with the system and what each role is permitted to do.
• Use cases or user stories with their main flow and their alternate and error flows.
• Numbered functional requirements. FR-1, FR-2 - each one atomic, testable, and traceable to a BR.
• Business rules. Validation, calculations, thresholds, state transitions.
• Data requirements. The fields, their meaning, their required-ness - not their column types.
• Screens and UI mockups. A wireframe or mockup for every screen the use cases touch, labelled with the FR numbers it illustrates - the layout, the states, and the fields on it, not the code that will draw it.
• Acceptance criteria. The conditions under which the requirement is considered met.

That last-but-one item answers a question teams argue about more than they should: the UI mockups belong to the FRD. The BRD is not allowed screens, and the TRD arrives too late to invent them - so wireframes and mockups are produced alongside the FRD by the product designer and attached to it, as an appendix or a linked design file the FRD references by version. Each mockup carries the FR numbers it shows, and each requirement with a visible surface points back at its mockup, so a reviewer can hold the two side by side and check they describe the same behaviour. A field on a mockup that no requirement asks for is a scope change in disguise. The mockups are signed off with the FRD, not separately; the TRD may cite them when it picks a front-end framework or a component library, but it does not redraw them. Wireframes, mockups, prototypes covers which level of fidelity belongs at which point.

The most common defect in an FRD is a requirement that describes an implementation. "The system stores the session in Redis" is not a functional requirement - "a signed-in user stays signed in for 30 days across devices" is, and Redis is one of several ways to satisfy it. Keeping that line clean is what leaves the engineering team room to make a good technical decision in the next document.

TRD - the build

The Technical Requirements Document is written by engineers - a tech lead or architect - and it is the first document allowed to name technology. It takes the behaviour in the FRD and specifies the system that produces it.

A TRD usually covers:

• Architecture. Components, their responsibilities, and how requests flow between them.
• Technology stack. Languages, frameworks, datastores, cloud services, with the reasoning for the notable choices.
• Interfaces and contracts. API endpoints, payloads, events, third-party integrations, authentication.
• Data model. Schemas, keys, indexes, retention, migration plan.
• Non-functional requirements. Performance targets, availability, scale, security posture, observability, backup and recovery.
• Environments and delivery. How it is built, tested, deployed, and rolled back.

Non-functional requirements are where the TRD earns its keep. The FRD says the report must be exportable; the TRD says it must render a 50,000-row export in under 20 seconds at the 95th percentile, which is the sentence that actually determines the architecture.

Side by side

The same project, seen from three angles. When a team argues about "where does this belong", this is usually the table that settles it.

Read the last row from the bottom up. Technical decisions are meant to be the cheap ones to change; business requirements are the expensive ones. Teams that write the TRD first invert that, and end up renegotiating the business case every time the architecture moves.

One need, three documents

The relationship between the three is traceability: every functional requirement points up to a business requirement, and every technical requirement points up to a functional one. Numbering them is what makes that link checkable rather than rhetorical.

A worked example - one business need, illustrative numbers, traced through all three documents:

Read it upward and the chain does its second job. If someone proposes dropping guest checkout, TR-1.2a is not just a task in a backlog - it is the 15% abandonment target in BR-1, which is the number the project was funded on. That is the whole argument for keeping the documents linked: it turns "an engineer removed a feature" into "the business is choosing to give up a measurable outcome".

A single business requirement usually fans out into several functional ones, and each of those into several technical ones. Big projects keep this in a traceability matrix - one row per requirement, columns for its parent, its owner, its test cases, its status. On a small project a numbered heading and a "traces to" line does the same work.

Who owns each document

Every document has one author who is accountable for it, a set of contributors who supply the content, reviewers who check it, and exactly one role that signs it off. Naming those four up front is what stops the common failure - a document that circulates for three weeks because nobody knows whose approval ends the discussion.

Two rules make the table work in practice. The author and the approver are never the same person - if the tech lead writes the TRD and also signs it, the review was theatre. And the approver of one document is a named contributor to the next: the sponsor who signed the BRD reviews the FRD's scope, and the product owner who signed the FRD reviews the TRD's cost and timeline. That overlap is what keeps the chain from breaking between levels.

After sign-off, changes go through change control rather than a hallway conversation: a documented request, an impact assessment walked up the traceability chain, and re-approval by the same role that signed the affected document. A change to TR-1.2a that alters FR-1.2 needs the product owner back at the table, not just the tech lead.

On a small team one person legitimately holds several of these roles - a founder may be sponsor and product owner at once. That is fine as long as the roles stay distinct on paper, so it is clear which hat is being worn when a decision is made. In an agile team the gates are lighter and more frequent - a BRD may be a one-page brief, the FRD may live as epics with acceptance criteria - but the approvals do not disappear. Someone still owns the money, someone still owns the behaviour, and someone still owns the build.

Where PRD, SRS, and ADR fit

These three are not the only acronyms in the room, and much of the confusion in practice comes from teams using two names for the same document.

• PRD - Product Requirements Document. The product world's equivalent of the BRD and FRD merged: the problem, the users, the solution, and the feature behaviour in one document. Common where a product manager owns both the case and the detail. If you have a PRD, you usually do not also need a separate BRD and FRD.
• SRS - Software Requirements Specification. The formal engineering specification, covering functional and non-functional requirements together - roughly an FRD and the requirements half of a TRD, written to a standard. It is the shape you meet in regulated, defence, and safety-critical work, where the standard itself is a deliverable.
• ADR - Architecture Decision Record. Not a requirements document at all. A short, dated note recording one decision, its context, the alternatives, and the consequences. ADRs live in the repository next to the code and accumulate over the life of the system, capturing the decisions a TRD froze at one moment and everything that changed after it.

The practical rule: BRD, FRD, and TRD are three levels of one chain. PRD and SRS are alternative packagings of the same content. ADRs run alongside all of them, in the codebase, forever.

How much of this you need

Full three-document sets belong to projects where the cost of a misunderstanding is high: long delivery cycles, external vendors, regulated industries, or a budget approved by people who will never attend a stand-up. There, the documents are how agreement survives staff turnover.

On a small internal product, the same three questions still have to be answered - but a page each is often enough, and the artefacts might be a funding brief, a set of stories with acceptance criteria, and a design doc with ADRs beside it. What does not scale down is the chain itself. Whatever you call the documents, someone should be able to pick any line in the build and walk it back to a business reason - and, going the other way, point at a business goal and see what was actually shipped for it.