Stop 03 · Requirements Analysis & DocumentationTopics · 3/10

Functional Requirements Document (FRD)

In short

The BRD says what the business needs. Developers and testers need much more: exact rules, inputs, errors. The FRD is where 'customers can use coupons' becomes something a team can build.

A more detailed document describing exactly how a system should behave to meet the business requirements from a BRD — the artifact engineers and QA reference during implementation and testing.

The purple blob in a kitchen holds a small recipe card next to a bowl of curry.

Think of it like this

The menu vs the recipe card

The menu says 'Paneer butter masala'. That's enough for a customer. The cook needs the recipe card: 200 g paneer, two spoons of butter, cook eight minutes, what to do if cream runs out. The FRD is the recipe card.

Watch it happen

Where the FRD fits

BRD

FRD

Design

Build

Test

1/5BR-03 in the BRD: 'Increase repeat orders by offering coupons to returning customers.'

The big ideas

What you need to know

Every requirement gets an ID

IDs like FR-4.1 let developers, testers and the RTM point to the exact requirement being discussed.

Inputs, rules, outputs, errors

A good functional requirement says what goes in, what rules apply, what comes out and what happens when it fails.

Trace back to the BRD

Each FR should link to a business requirement. If it doesn't, ask why it's there.

Agile teams split it up

Many Agile teams use user stories with acceptance criteria instead of one big FRD. The detail is the same, just in smaller pieces.

See it in code

Walk through the code

text

1FR-4.1   Apply a coupon at checkout2Actor:   Logged-in customer3Trigger: Customer taps "Apply" on the cart page.4Input:   Coupon code, 4 to 12 letters or digits.5Rules:6  R1. The code must exist and not be expired.7  R2. Cart total must meet the coupon's minimum value.8  R3. Only one coupon per order.9Output:  New total shown with a discount line.10Errors:  If R1 fails, show "This coupon is invalid or expired."11Source:  BR-03 (increase repeat orders)

1/4An ID, who uses it and what starts it. Anyone can refer to 'FR-4.1' without confusion.

One functional requirement written in a simple, consistent format. Developers build from it and testers test from it.

Save yourself the pain

Common mistakes

Oops

Only writing the happy path where everything works.

Do this instead

Write what happens on bad input, timeouts and missing data. That's where most bugs and arguments come from.

Oops

Copying the BRD wording into the FRD.

Do this instead

Add the detail: exact fields, rules, limits and messages. If it reads like the BRD, it's not detailed enough.

Your mission

Write three FRs

~30 min

Quick check

What is the main audience of an FRD?

Go deeper

1Write an FRD detailing the specific functional requirements from your BRD practice exercise.
2Learn to write requirements specific enough to be testable, not vague or ambiguous.
3Practice tracing each FRD item back to a specific business requirement it supports.