# Software Requirements Specification

> The engineering contract. Every requirement here should be verifiable, and every number should
> have been derived from something rather than chosen because it sounded reasonable.
>
> Structure follows the conventional introduction / description / requirements shape; the
> international reference for requirements engineering is ISO/IEC/IEEE 29148.

**System:** _______________  **Version:** ____  **Date:** _______
**Author:** _______________  **Engineering owner:** _______________

## 1. Introduction

**Purpose of this document:** _______________
**System scope:** _______________
**Explicitly excluded:** _______________
**Intended readers:** _______________

## 2. Overall description

**Context** — what this system sits between: _______________

**Users and their characteristics:** _______________

**Operating environment** (platforms, browsers, devices, networks): _______________

### Assumptions

| # | Assumption | Who confirms | Confirmed |
|---|---|---|---|
| A1 | | | |

### Dependencies

| # | Depends on | Owner | Risk if unavailable |
|---|---|---|---|
| D1 | | | |

The assumptions table is where a project's real risk usually sits. "We assume the upstream system
provides a unique identifier" is one line, and a quarter of work when wrong.

## 3. Functional requirements

| ID | The system shall… | Verification method | Priority |
|---|---|---|---|
| SR-001 | | test / demo / inspect / analyse | |

If the verification method for any row is "inspect the code" or "the developer confirms", it will
not be verified. Rewrite it.

## 4. External interfaces

Complete one per integration.

| | |
|---|---|
| Interface name / counterparty | |
| Protocol and format | |
| Authentication | |
| Expected volume (average / peak) | |
| Timeout | |
| Retry policy | |
| **Idempotent — safe to repeat?** | yes / no |
| Error codes and meanings | |
| **Behaviour when the far end is down** | |
| Contact when it misbehaves | |

## 5. Data dictionary

| Field | Type | Range / format | Mandatory | Source of truth | Retention |
|---|---|---|---|---|---|
| | | | | | |

## 6. Non-functional requirements

Each with a number and the condition it applies under. A figure nobody derived is worse than no
figure, because it will be designed to — mark placeholders as such with a date to resolve.

| | Requirement | Derived from |
|---|---|---|
| Performance | ___ operation at p95 under ___ concurrent users | |
| Volume | ___ records today, ___ growth/year, peak ___ | |
| Availability | ___%, measured as ___, excluding ___ | |
| **RPO** (data loss tolerable) | | |
| **RTO** (time to recover) | | |
| Security | authn ___ · authz model ___ · encryption ___ | |
| Audit | what is logged, retained ___ | |
| Accessibility | standard and level (build to WCAG 2.2 AA unless stated otherwise) | |
| Compliance / residency | | |

RPO and RTO shape the architecture more than anything else on this page. Fill them before design
starts, not after.

## 7. Acceptance criteria

| Requirement ID | How acceptance is demonstrated | By whom |
|---|---|---|
| | | |

## 8. Glossary

| Term | Definition in THIS system |
|---|---|
| | |

Most requirement disputes are vocabulary disputes. Two teams using "customer" differently will
agree on every sentence and build incompatible systems.

## 9. Open issues

| # | Issue | Owner | Needed by |
|---|---|---|---|
| | | | |

## 10. Sign-off

| | Name | Date |
|---|---|---|
| Author | | |
| Engineering | | |
| Business owner | | |
| Security | | |