# Requirements Document

**Template, version 2.** How to use it: fill in every section; write "none" rather than leaving blanks. Short is fine, vague is not. This document plus the [done-test](https://mangrove.co.uk/done-test) is what a fixed price is quoted against; the sharper they are, the lower the shaping cost (a fully done-test-ready pack can take it to zero).

## 1. The product in one paragraph

What it is, who it is for, and what changes for them when it exists.

## 2. Goals and non-goals

- **Goals:** the two or three outcomes this build must achieve.
- **Non-goals:** what this build deliberately does not attempt. Non-goals prevent scope drift better than any meeting.

## 3. Users and surfaces

Who uses it (roles, not personas essays) and where (web, mobile, admin, API consumers).

## 4. Scope

| In this build | Out (explicitly) | Later (parked) |
|---|---|---|
| | | |

One row per feature, in plain language. Anything not written here is out.

## 5. Assumptions

List every assumption you are making. Each one moves the price when it turns out false, so surfacing them now is money.

## 6. What you will provide, and by when

| Input (content, access, approvals, third-party sign-offs) | Needed by |
|---|---|
| | |

These become named dependencies in the done-test. Work blocked on a missing input pauses the clock; it does not fail the build.

For AI features, the labelled evaluation set belongs here, with an owner and a date. It is on the critical path: it is what "done" is measured against, and it has to come from real data rather than examples written for the purpose.

## 7. Integrations and data

Systems to connect to, data in and out, who owns each source, and any migration from existing systems.

## 8. Constraints

- **Regulatory and compliance:** GDPR posture, sector rules, audit requirements, data residency.
- **Technical:** required stack, hosting, existing systems that must be respected.
- **Commercial:** budget band, hard dates and what drives them.

## 9. Non-functional requirements

Put a number against every line that applies and write "not required" against the rest. These become the non-functional rows of the done-test, and an omission here is a decision: what is not specified is not built, and not refundable.

| | Requirement |
|---|---|
| Load and concurrency | Expected and peak concurrent users; the operation that will be busiest |
| Response time | The slowest acceptable response for the operations that matter, at p95 |
| Availability | Target uptime, the hours it applies to, and what an outage actually costs you |
| Recovery | How much data you can afford to lose, and how long you can be down |
| Accessibility | Target standard (WCAG 2.2 AA is the usual answer) and whether an audit is required |
| Browsers and devices | The matrix you support, and the oldest thing that must work |
| Observability | Who gets told when it breaks, by what route, and how fast |
| Security posture | Authentication model, roles, and whether a penetration test is in scope |
| Data residency | Where data may be stored and processed |

**Design and brand.** Where the look matters, name the approved frames or design system and say who signs them off. Taste is approved before the build; only compliance with the approved design is testable after it. A done-test cannot hold "looks good", so the approval has to happen upstream.

## 10. Run economics

For anything with a material running cost (AI features, third-party APIs, data volumes): expected volumes and the unit cost that must hold at those volumes. A feature that works but is uneconomic to run is a failed feature; this section is where that gets caught before it is built.

## 11. What success looks like

Two or three measurable statements about the world after launch. These seed the done-test.