FRD Explained: Turning Business Needs Into System Behaviour

A BRD says the business needs to stop losing orders at checkout. An FRD says what the system does about it: which validations run, in what order, what the user sees when card authorisation is declined, what happens to the basket when the session expires mid-payment.

That shift — from outcome to behaviour — is the entire job of a Functional Requirements Document. It is written for the people who will build and test the system, and its quality is measured by a single question: could two competent teams read this and build the same thing?

Where it sits between the BRD and the SRS#

The three documents are frequently conflated, and the conflation is the source of most arguments about which one is "wrong".

Not every project needs all three. A small change with a clear owner needs one document, and insisting on the full set is how governance earns its reputation. What matters is that somewhere, in writing, the business intent and the system behaviour both exist — and that you can tell which is which.

What belongs in it#

Scope, and explicitly what is out of scope. The out-of-scope list prevents more disputes than the scope list, because disagreement almost always concerns something nobody wrote down.

Actors and roles. Who uses this, with what permissions. Authorisation rules stated once here save an enormous amount of ambiguity later.

Functional requirements, each with an identifier, stated as observable behaviour.

Business rules — calculations, thresholds, eligibility conditions — separated from the flows that use them. Rules change on a different cycle from the interface, and separating them means one edit rather than eight.

Data: what is captured, what is mandatory, what is validated and how, what is retained.

Interfaces: what this system sends to and receives from others, and what happens when the other end is unavailable.

Error and edge behaviour. This is where FRDs are usually thin, and it is where delivery teams lose the most time asking questions.

Non-functional requirements, or a pointer to where they live: performance, volume, availability, accessibility, retention.

Writing a requirement that can be tested#

The test is mechanical. Read the requirement and ask: what would I do to prove this is met? If you cannot answer in one sentence, rewrite it.

Weak: The system should handle failed payments gracefully.

Testable: When card authorisation is declined, the system keeps the basket intact, displays the issuer's decline reason where one is supplied, and allows a different payment method without re-entering delivery details.

Three habits produce most of the improvement:

One requirement, one behaviour. Requirements containing "and" usually contain two requirements, one of which will be missed by whoever implements it.

Name the actor and the trigger. "When a returning customer applies an expired promotional code at checkout" is a scenario. "The system validates codes" is a topic heading.

State the negative case. Most defects live in what happens when something is absent, invalid, duplicated, or arrives twice. If the FRD is silent, the behaviour will be whatever the implementation happened to do.

Avoid the words support, handle, manage, appropriate and user-friendly in a requirement. Each of them sounds like a specification and commits to nothing.

Numbering and traceability#

Give every requirement a stable identifier, and never reuse one. FR-014 must mean the same thing in a year, or the traceability matrix and every test referencing it become misleading.

That identifier is what connects business need to system behaviour to test case in the RTM. Requirements without identifiers cannot be traced, which means at the end of a project nobody can answer "was this actually delivered" without a meeting.

Why FRDs fail#

They describe features and skip the boundaries. The happy path is easy to write and easy to build. Timeouts, partial failures, concurrent edits, duplicate submissions and the third-party system returning something unexpected are where the effort goes, and they are usually a sentence each in the FRD when they appear at all.

They are written once and never updated. Delivery makes decisions daily; if they are not reflected, the document becomes a historical curiosity within weeks, and the test team is working from something that no longer describes the system.

They specify the interface instead of the behaviour. An FRD that dictates screen layout constrains design without adding clarity. State what must be achievable and what rules apply; let design decide the arrangement.

They are approved by people who did not read them. A sixty-page document circulated with a three-day deadline gets signed, not reviewed. Circulating sections to the people who care about each one gets actual scrutiny, and it is faster.

Business rules are scattered through the flows. The same calculation described in four places will eventually be described four different ways, and nobody will know which is correct.

Making it usable#

Write it in a form that can be reviewed in pieces and updated without ceremony. A long document that requires a formal change request for a clarification will simply stop being updated.

Keep a decision log alongside it. Half the value of requirements work is the record of what was considered and rejected — otherwise the same question is reopened every few months by someone new.

Involve the test team while it is being written, not after it is approved. They will ask "how would I prove that" about statements everyone else read straight past, and it is far cheaper to answer then than during a test cycle.

A realistic starting point#

For a first FRD on a medium change: scope and out-of-scope, actors, a numbered list of functional requirements grouped by area, a separate business rules table, a data table, an interface table with failure behaviour, and an open questions list with owners and dates.

The open questions list is the part teams skip and the part that most reliably prevents surprises. Unknowns are not a sign of a weak document; unrecorded unknowns are.

FAQ#

Do we need a BRD, FRD and SRS on every project?#

No. Use what the risk justifies. Many projects are well served by one document that covers business intent and system behaviour, with engineering detail in the technical design. The rule worth keeping is that intent and behaviour must both be written somewhere, and it must be obvious which is which.

Who writes the FRD?#

Usually a business analyst, working with delivery. Written entirely by the business it tends to omit system behaviour; written entirely by engineering it tends to encode the current implementation rather than the requirement. It needs both perspectives and one owner.

How detailed should it be?#

Detailed enough that two teams would build the same thing, and no more. Detail beyond that ages badly and consumes review attention that the ambiguous parts need. Spend the effort where getting it wrong is expensive.

How does an FRD work with agile delivery?#

Perfectly well, if you stop treating it as a gate. Use it as the durable statement of behaviour and rules; use stories for the increments of work. Stories are ephemeral and get closed. In six months nobody reads a closed story, but somebody will need to know what the eligibility rule is.

What about non-functional requirements?#

They belong somewhere explicit, whether in the FRD or referenced from it. Performance, volume, availability, accessibility and retention are requirements that get discovered late and cost the most to retrofit. Silence on them is a decision to find out in production.

How do we handle changes after approval?#

Through a light, recorded process: what changed, why, what it affects, who agreed. The alternative — informal changes that never reach the document — is how the FRD, the tests and the system end up describing three different products.

Is it worth writing an FRD for a small change?#

Often not as a document. But the thinking still applies: what exactly changes, what rules apply, what happens at the edges, how will we know it worked. Answer those in the ticket and you have the value of an FRD without the ceremony.

Related Articles#

Start from the BRD for business intent, continue to the SRS for the engineering contract, use the RTM to trace requirements to tests, and prove fitness for purpose with UAT.

What else is coming for FRD