Software Requirements Specification Template
A fill-in SRS, context and assumptions, interfaces at field level, a data dictionary, non-functional requirements with derived numbers, acceptance criteria and a glossary.
Markdown. No sign-up, no email.
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 |