# Functional Requirements Document

> Numbered requirements, one behaviour each, written so a tester can prove them. If a requirement
> below cannot be verified in one sentence, it is not finished.
>
> Pair with the [BRD template](/templates/brd/) for business intent.

**System / change:** _______________
**Owner:** _______________  **Author:** _______________
**Version:** ____  **Date:** _______  **Status:** draft / review / baselined

## 1. Scope

**In scope:** _______________

**Explicitly out of scope:** _______________

**Related systems affected:** _______________

The out-of-scope list settles more disputes than the in-scope list. Write the things people
actually expect, not the absurd ones.

## 2. Actors and permissions

| Actor | Description | What they may do | What they must not |
|---|---|---|---|
| | | | |

## 3. Functional requirements

One behaviour per row. Never reuse an identifier, even after a requirement is withdrawn.

| ID | Requirement | Actor | Trigger | Expected result | Priority |
|---|---|---|---|---|---|
| FR-001 | | | | | must / should / could |
| FR-002 | | | | | |

**Wording rules:** name the actor and the trigger · state one behaviour · avoid *support*,
*handle*, *manage*, *appropriate*, *user-friendly* · state the negative case separately rather
than as an aside.

## 4. Business rules

Held separately from the flows that use them, because rules change on a different cycle and a rule
described in four places will eventually be described four ways.

| ID | Rule | Applies when | Owner |
|---|---|---|---|
| BR-001 | | | |

## 5. Data

| Field | Type | Mandatory | Validation | Default | Retention |
|---|---|---|---|---|---|
| | | | | | |

**Personal data involved:** yes / no — if yes, classification and lawful basis: _______________

## 6. Interfaces

| Interface | Direction | Trigger | Payload | **Behaviour when unavailable** | **Safe to repeat?** |
|---|---|---|---|---|---|
| | in / out | | | | yes / no |

🔴 The last two columns are the ones usually left blank, and they cause duplicate orders, lost
messages and defects that only appear under load. Fill them.

## 7. Error and edge behaviour

| Condition | Expected behaviour | User sees |
|---|---|---|
| Required input missing | | |
| Invalid input | | |
| Duplicate submission | | |
| Concurrent edit by two users | | |
| Downstream system unavailable | | |
| Session expires mid-transaction | | |
| Permission denied | | |

Most defects live here. An FRD thin in this section produces a delivery team asking questions for
six weeks.

## 8. Non-functional requirements

| Requirement | Target | How measured |
|---|---|---|
| Response time (operation, percentile, load) | | |
| Volume / concurrency | | |
| Availability | | |
| Accessibility standard | | |
| Audit / retention | | |

## 9. Open questions

| # | Question | Owner | Needed by | Resolved |
|---|---|---|---|---|
| | | | | |

Unknowns are normal. Unrecorded unknowns become assumptions nobody agreed to.

## 10. Sign-off

| | Name | Date |
|---|---|---|
| Author | | |
| Business owner | | |
| Delivery lead | | |
| Test lead | | |