Software requirements specification (SRS) template
The standard structure in a copy-ready template, examples of functional and non-functional requirements, and the qualities a good SRS is checked against.
Where this comes from
The section structure follows IEEE 830-1998 and its successor ISO/IEC/IEEE 29148, simplified; the quality list is the one those standards give. Template wording and examples are ours. Nothing here is a measurement.
What an SRS is
A software requirements specification describes what a system must do and the constraints it must do it under, in enough detail that it can be built and tested without the author in the room. Where a BRD says why and a PRD says what for the user, the SRS says exactly how the system must behave, including the non-functional requirements both of those usually leave out.
The template
# Software Requirements Specification: <system name>
Version <x.y> — <date>
## 1. Introduction
### 1.1 Purpose
What this document specifies and who it is for.
### 1.2 Scope
The system, what it does, and what it does not do.
### 1.3 Definitions and abbreviations
### 1.4 References
## 2. Overall description
### 2.1 Product perspective
Where the system sits: what it replaces, what it connects to.
### 2.2 User classes
| User class | Description | Frequency of use |
### 2.3 Operating environment
### 2.4 Constraints
Regulation, mandated technology, hardware, deadlines.
### 2.5 Assumptions and dependencies
## 3. Functional requirements
### 3.1 <feature or area>
FR-001 The system shall <verifiable behaviour>.
Priority: must | should | could
Source: <story, stakeholder or BR-xxx>
Acceptance: <check that returns yes or no>
## 4. External interface requirements
### 4.1 User interfaces
### 4.2 APIs and software interfaces
### 4.3 Hardware interfaces
### 4.4 Communication interfaces
## 5. Non-functional requirements
NFR-001 Performance: <metric, threshold, conditions>.
NFR-002 Security: <rule>.
NFR-003 Availability: <target and measurement window>.
NFR-004 Accessibility: <standard and level>.
## 6. Open issues
## Appendix: traceability (FR/NFR → source → test)Writing the requirements themselves
| Weak | Strong |
|---|---|
| The system should be fast. | NFR-001 The order search shall return results within 500 ms at the 95th percentile for 200 concurrent users. |
| Users can manage their data. | FR-014 The system shall let a user export all their records as CSV. |
| The system shall be secure and reliable. | NFR-002 The system shall lock an account for 15 minutes after 5 failed sign-ins within 10 minutes. |
| Support all browsers. | NFR-006 The web client shall support the two latest versions of Chrome, Firefox, Safari and Edge. |
"Shall" marks a binding requirement, "should" a recommended one. One requirement per statement: a sentence with "and" in it is usually two requirements, and they will be tested and changed separately. A structured form for the conditions ("When X, the system shall Y") keeps these consistent across authors.
The qualities an SRS is checked against
- Correct: every requirement is something the system actually needs.
- Unambiguous: one interpretation only.
- Complete: all significant requirements, and responses to every input, including invalid ones.
- Consistent: no two requirements contradict each other.
- Ranked: each has a priority or stability rating.
- Verifiable: each can be checked by a finite, cost-effective process.
- Modifiable: structured so a change lands in one place.
- Traceable: each has a source and can be referenced by ID.
An SRS your coding agent can read
A long SRS document is hard to keep current and hard to hand to an AI coding agent: it is too large for one prompt, and the agent can't tell which section governs the change it is making. The qualities above (unambiguous, verifiable, traceable, ranked) are exactly what an agent needs, but they survive best as structured records, not prose.
Entalpa stores each requirement with its ID, statement, priority, acceptance criteria and status, linked to the story and stakeholder it came from. Its Spec score checks the set for gaps a reviewer would flag (missing acceptance criteria, ambiguous wording, unanswered open questions), and a locked requirement can't be rewritten by the model. The agent reads it over MCP; the document version exports as ReqIF, Markdown or CSV.
Questions this raises
What is an SRS document?
A software requirements specification: a document describing what a software system must do and the constraints it must meet, detailed enough to build and test it. It covers functional requirements, non-functional requirements and interfaces.
What is the standard format for an SRS?
IEEE 830-1998 defined the classic structure (introduction, overall description, specific requirements). It has been superseded by ISO/IEC/IEEE 29148, which keeps a very similar layout.
What is the difference between functional and non-functional requirements?
Functional requirements describe what the system does: behaviours, features, responses to input. Non-functional requirements describe how well it does it: performance, security, availability, usability and similar qualities.
Is an SRS still used in agile teams?
Less often as a single upfront document, but its content still exists: as stories, acceptance criteria and non-functional requirements. Regulated projects and contracts often still require a formal SRS.
Entalpa gives your agent one locked source of truth
Structured, traceable requirements your agent reads over MCP — so it works from a curated spec instead of reconstructing your project every session. Free to start, no card, and reading or writing your project over MCP never spends credits.
Other guides