Software requirements specification (SRS) template
A software requirements specification (SRS) describes everything a piece of software must do and every condition it must meet — its functions, interfaces, performance, constraints and quality attributes — so that it can be built, tested and agreed against. Below is a free template following the IEEE 830 outline, example requirements, where the standards stand today, and how an SRS differs from a PRD and a functional specification.
IEEE 830 and ISO/IEC/IEEE 29148
IEEE 830-1998, “IEEE Recommended Practice for Software Requirements Specifications”, describes “The content and qualities of a good software requirements specification (SRS)” and presents sample outlines. IEEE lists it as superseded by ISO/IEC/IEEE 29148:2011, which replaced IEEE 830 together with two other standards — and which was itself superseded by the 2018 edition (IEEE 830, ISO/IEC/IEEE 29148:2011).
The IEEE 830 outline is still taught in course material, and the template below follows it. If your contract or your regulator names ISO/IEC/IEEE 29148, use that standard’s own outline — the documents are sold by ISO and IEEE, and this page does not reproduce them.
The SRS outline
The IEEE 830 outline, as summarised in University of Ottawa course notes:
| Section | What goes in it |
|---|---|
| 1. Introduction | Purpose; scope; definitions, acronyms and abbreviations; references; overview |
| 2. Overall description | Product perspective; product functions; user characteristics; constraints; assumptions and dependencies |
| 3. Specific requirements | External interfaces; functions; performance requirements; logical database requirements; design constraints; software system quality attributes; object-oriented models |
| Appendices and index | Supporting material |
Section 3 is where the requirements themselves live; the first two sections are the context a reader needs to understand them.
The template
Copy it into Word, Google Docs or Confluence. Everything in square brackets is yours to fill in.
SOFTWARE REQUIREMENTS SPECIFICATION
Product: [product name]
Version: [x.y]
Status: [draft / in review / signed
off]
Authors: [names, roles]
Approved by: [names, roles, dates]
1. INTRODUCTION
1.1 Purpose
[What this document is for, and who
reads it.]
1.2 Scope
[The product, what it will and will
not do, and the benefit to its users.]
1.3 Definitions, acronyms and
abbreviations
1.4 References
[Business requirements, contracts,
standards, with versions.]
1.5 Overview
[How the rest of this document is
organised.]
2. OVERALL DESCRIPTION
2.1 Product perspective
[Where it fits: other systems,
interfaces, what it replaces.]
2.2 Product functions
[A summary of the main functions.]
2.3 User characteristics
[Who uses it, how often, with what
experience.]
2.4 Constraints
[Regulations, hardware, required
technologies.]
2.5 Assumptions and dependencies
3. SPECIFIC REQUIREMENTS
3.1 External interfaces
User interfaces: [ ]
Hardware interfaces: [ ]
Software interfaces: [system, data,
protocol]
3.2 Functional requirements
ID: FR-[nnn]
Requirement: The system shall
[one behaviour].
Source: [business requirement it
answers to]
Priority: [must / should / could]
Verified by: [test / inspection /
demonstration / analysis]
Acceptance criteria:
Given [ ] When [ ] Then [ ]
3.3 Performance requirements
NFR-[nnn]: [a measurable target]
3.4 Logical database requirements
[Data the system keeps, how long, who
may see it.]
3.5 Design constraints
3.6 Software system quality attributes
Reliability, availability, security,
maintainability, portability:
[measurable targets]
APPENDICES
A. Traceability: requirement -> source ->
tests
B. Change history: version, date, change,
approved by
SRS example requirements
A functional and a non-functional requirement from a customer portal, filled in:
ID: FR-014
Requirement: The system shall let a
signed-in customer pay any
open invoice of their company
by card.
Source: BR-03: shorten the time
invoices stay unpaid
Priority: Must
Verified by: Test
Acceptance criteria:
Given an open invoice
When the customer pays it by card and
the bank approves the payment
Then the invoice shows "Paid" with
today's date
ID: NFR-007
Requirement: The payment page shall
respond within 2 seconds for
95% of requests, with 500
customers using the portal at
once.
Source: BR-03
Priority: Should
Verified by: Load test
SRS vs PRD, BRD and functional specification
| Document | What it covers | Usually written by |
|---|---|---|
| Business requirements (BRD) | Why the business needs it, and what outcome counts | A business analyst, with the sponsor |
| Product requirements (PRD) | Which problem, for which users, and how success is measured | A product manager |
| Functional specification (FSD or FRS) | What the software does: features, screens, rules, data | A business analyst or product manager |
| Software requirements specification (SRS) | Everything the software must do and meet: functions, interfaces, performance, constraints, quality attributes | A business analyst, systems analyst or requirements engineer |
An SRS contains what a functional specification does, and adds the non-functional requirements, interfaces and constraints (the types of requirements page has one example of each). For a lighter document focused on features and sign-off, see the functional specification template.
Who writes the SRS?
It depends on the contract:
The name SRS for a “software requirements specification” is well established and depending on how it’s understood it could be written by the customer or written by the supplier. … What matters is to have a common understanding and work together.
— Hacker News, 2023
Whoever writes it, the people who will accept the software review it and sign off a version — the requirements sign-off template has the wording.
How to write a software requirements specification
- Start from the business requirements, and give every software requirement a source.
- One requirement, one behaviour, one ID. “The system shall …”, one sentence.
- Make every requirement verifiable, and say how: test, inspection, demonstration or analysis. The requirements review checklist has the other checks.
- Put numbers on non-functional requirements. “Fast” and “secure” cannot be tested — see non-functional requirement examples.
- Write acceptance criteria for each functional requirement — see the acceptance criteria template.
- Keep a traceability appendix: requirement, source, tests. The requirements traceability matrix is the spreadsheet version.
- Version it, get it signed off, and change it only through change requests. The signed version is your requirements baseline.
SRS and spec-driven development
Spec-driven development tools are, in one commenter’s description, a guided SRS: “All they do is walk you through the SRS process using a set of system prompts to generate a set of documents featuring usecases, functional requirements, and refined tasks in the form of an actionable plan” (Hacker News, April 2026). The reply: “I’m not criticizing spec-driven development frameworks, but how battle-tested are they? Does it remove the inherent ambiguity in natural language?” (Hacker News).
The questions an SRS has always had to answer remain: who agreed it, which version, and what happens when it changes. See the spec template for spec-driven development and who reviews the spec.
Where Specroot fits
This is the problem Specroot works on: a requirements specification that stays one agreed, versioned whole — from business requirements down to work items — after the work starts, instead of a document that falls behind it. Specroot for agencies and consultancies.
Read next
- Functional specification template for software — A free functional specification (FSD) template for software, a filled-in example, functional requirement examples, and FSD vs BRD, PRD and technical spec.
- Requirements traceability matrix (RTM): template and example — A free requirements traceability matrix template for Excel or Google Sheets, a filled-in example, forward and backward traceability, and RTMs in Jira and agile.
- Requirements baseline: what it is, with an example — A requirements baseline is the agreed version of the requirements every later change is measured against. Definition, example, scope baseline, re-baselining.