Functional Requirements Document Template

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 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#

3. Functional requirements#

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

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.

5. Data#

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

6. Interfaces#

🔴 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#

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

8. Non-functional requirements#

9. Open questions#

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

10. Sign-off#

Back to FRD