BRD vs FRS vs User Stories: When to Use Each
Ask three teams what goes in a BRD and you'll get three answers. Ask where the FRS ends and user stories begin and you'll get more. Here's how the three differ, when each one earns its place, and how they fit together on a real project.
01The short answer
A BRD says what the business needs and why. An FRS says exactly what the system must do to meet that need. User stories break the work into small pieces a delivery team can build and test one at a time.
They aren't competitors. On most projects in banking, fintech and the public sector you'll use at least two of them, and each level should trace to the next.
| BRD | FRS | User stories | |
|---|---|---|---|
| Answers | What does the business need, and why? | What exactly must the system do? | What's the next small piece of value? |
| Written for | Sponsors, process owners, compliance | Developers, testers, vendors | The delivery team |
| Level of detail | Business outcomes and scope | Rules, data, workflows, exceptions | One behaviour, with acceptance criteria |
| Approved by | Business sponsor and process owners | Business owners and the delivery lead | Product owner, story by story |
| Changes | Rarely, through change control | Through change control | Constantly, as the backlog is refined |
02The BRD: the business case for the requirements
The business requirements document sets out the problem, the objectives and how success will be measured, the scope, the stakeholders, the current and future process, and the requirements the business needs met. It's written so a sponsor who has never seen the system can read it and say "yes, that's what we need".
Its real job is agreement. A signed BRD is the record that the people who fund and use the solution agreed on what it's for before anyone built it. My guide to writing a BRD covers the structure section by section.
03The FRS: the detail a system is built and tested from
The functional requirements specification takes each business need and says precisely how the system must behave. A good FRS covers:
- Functional requirements, numbered and traced back to the business requirement they serve
- Business rules and data validation: limits, calculations, mandatory fields, formats
- Workflows and approvals: who does what, in what order, and what each status means
- Exception handling: what happens when data is wrong, late or missing
- Interfaces, reports and notifications, plus the non-functional needs such as audit, security and performance
On the ₦351 billion rights issue digitisation at Access Bank, I wrote the FRS for the digital platform. It covered shareholder data ingestion, validation rules for KYC, subscription limits and allotment calculations, approval workflows, exception handling and the audit trail the regulators needed. That level of detail was the right call: the exercise was large and regulated, and it couldn't afford reconciliation errors.
A note on names: FRS and FRD (functional requirements document) mean the same thing in most organisations. An SRS (software requirements specification) is usually a more technical cousin written for engineering teams.
04User stories: requirements in deliverable slices
A user story describes one thing a user needs, in their words, with the reason:
As a customer, I want to see my treasury bill's maturity date on my dashboard, so that I can plan when the money comes back.
The story itself is short on purpose. The detail lives in its acceptance criteria and in the conversation between the BA, the product owner and the developers. That's what makes stories good for teams that build in short cycles: each one can be estimated, built, tested and shown in a sprint.
What stories don't do well on their own is hold the whole picture: the scope, the end-to-end process, the regulatory rules that cut across dozens of stories. That's why many teams keep a short BRD or product brief alongside the backlog. User stories and acceptance criteria has worked fintech examples.
05When to use which
| Situation | What to write |
|---|---|
| Regulated change with audit or regulator scrutiny | BRD and FRS, traced to UAT test cases |
| Buying or configuring a vendor system | BRD for the business need, FRS to evaluate vendors and hold them to it |
| Agile product team building in sprints | A short BRD or product brief, then user stories in the backlog |
| A small change to an existing system | User stories or a change request, linked to the original requirements |
| Robotic process automation | A bot specification, which is an FRS for a bot: trigger, inputs, rules, exceptions, outputs |
A common pattern in Nigerian banks is a hybrid: a BRD signed off for governance, then the build managed as user stories in Jira. That works well, as long as every story can be traced back to a signed requirement. For automation work, choosing processes for RPA covers what a bot specification needs.
06How they fit together: traceability
The three documents are levels of the same thinking, and each level should point to the one above it. Here's an example thread for a treasury bill product:
| Level | Example |
|---|---|
| Business requirement | BR-03: The investment amount must be held on the customer's account as soon as the request is submitted. |
| Functional requirement | FR-11: On submission, the system places a hold for the investment amount plus charges. If the hold fails, the request is rejected and the customer sees the reason. |
| User story | As a customer, I want my funds reserved when I submit, so that my bid isn't rejected later for insufficient balance. |
| UAT test case | Submit a request with sufficient balance; confirm the hold appears on the account with the correct amount. |
Keep that chain in a requirements traceability matrix. When UAT comes, it's how you prove every requirement was built and tested, and it's how you find the requirement nobody tested before a regulator does.
07Common mistakes
- Copying the BRD into the FRS. If the FRS repeats business goals without adding rules, data and exceptions, developers will fill the gaps with guesses.
- Designing in the BRD. Screen layouts and database fields in a BRD lock in decisions before the business need is agreed.
- Treating stories as the whole picture. A backlog of 200 stories with no end-to-end view hides the gaps between them.
- No traceability. Without it you can't show coverage at UAT, or assess the impact of a change request.
- Different names for the same thing. Agree at kickoff which documents the project will use and what each must contain.
08Common questions
Is an FRD the same as an FRS?
In most organisations, yes. Both describe the functional requirements: what the system must do, with its rules, data, workflows and exceptions. Use whichever name your organisation's templates use.
Do agile teams still need a BRD?
Often a short one helps. It holds the problem, scope, stakeholders and cross-cutting rules that individual user stories can't, and gives sponsors something to sign off.
Who writes the FRS?
Usually the business analyst, working with process owners for the business rules and with developers and architects to check that each requirement can be built and tested.
Can user stories replace an FRS?
On small or low-risk work, yes. In regulated projects, teams usually keep a specification or detailed acceptance criteria as well, so there is an auditable record of what the system must do.