FRD
A functional requirements document that is specific enough to build and test from: every rule stated as behaviour, the unhappy paths given the same attention as the happy one, and each requirement numbered so a test and a ticket can point at it.
- Asks for
- An approved PRD, or the idea and its agreed scope
- Any rules that already exist — validation, limits, what the system does today
- Which integrations or systems are involved
- Gives back
- Numbered requirements written as behaviour: given, when, then
- The unhappy paths — empty, duplicate, out of range, interrupted, failed
- Validation rules and limits stated as values rather than adjectives
- What is still undecided, named, with an owner
- Plan
- Pro and Max
- Use next
- PRD, Document to tickets, Epic, User story
What it gives you
FR-14 Import — a row with no effort value Given a CSV row where effort is empty or not a number, When the file is imported, Then the row is kept, excluded from the ranking, and listed under "needs a value" with the row number. The import does not fail. FR-15 Import — the same file twice Given a file whose rows match an existing import exactly, When it is imported again, Then nothing is duplicated and the person is told it matched import #N.
How it works
The happy path is the easy half, and it is the half most specs stop at. What makes an FRD worth writing is everything else: the empty state, the duplicate, the value out of range, the request that arrives twice, the user who closes the tab halfway through. Those are where the arguments happen in code review, and settling them in a document costs a tenth of settling them in a pull request.
So each requirement is written as behaviour with a trigger and an outcome — given this, when that, then this — and numbered. Numbering sounds clerical and is the thing that makes the document usable: a test names a requirement, a ticket names a requirement, and a change request names the one line it changes rather than the whole document.
It works best from an approved PRD, because then the scope is already settled and the FRD can spend its length on behaviour rather than re-arguing what is in. From a bare idea it still works, and it will be louder about what has not been decided.
Who it is for
A PM or engineer who has to write a spec precise enough that QA can test it without asking questions, and does not want to discover the edge cases in review.
Where it stops
It specifies behaviour, not architecture: what the system does, not which service does it or how the data is stored. It is also only as exact as what you tell it — where a rule has never been decided, it writes an open decision rather than a limit, and a document full of those is a signal that the PRD is not finished.
Questions people ask
How detailed should an FRD be?
Detailed enough that a tester who was not in any of the meetings can write test cases from it and an engineer can build without guessing. The practical test is the unhappy paths: if the document says what happens when the input is empty, duplicated, out of range or interrupted, it is detailed enough. If it only describes the path where everything works, it is a summary of the PRD with more pages.
Why are requirements numbered?
So that everything else can point at them. A test case names FR-14, a ticket names FR-14, a change request changes FR-14 and nothing else, and six weeks later an argument about behaviour is settled by reading one line rather than re-reading a document. Unnumbered requirements are the reason specs get replaced by meetings: there is no way to refer to one precisely, so people describe them from memory.
Should I write an FRD if I already have a PRD?
Only when the behaviour is complicated enough that getting it wrong is expensive — payments, permissions, imports, anything with external systems or money in it. For a small, obvious feature the PRD plus the tickets is usually enough, and an FRD is ceremony. The signal that you need one is an engineer asking a question whose answer nobody in the room agrees on.
Run it on your own work
FRD needs an account, because it writes against what you give it and remembers what you have told it before. It is part of Pro and Max. Or see what the plans cost first.