SRS document template: the sections, with an example

An SRS document template gives you a fixed set of headings to fill in before anyone writes code, so that what you want built is on paper in one place. It is for the person about to ask developers for a quote, or about to start a build with their own team. Below are the sections and what goes under each, a plain outline you can paste into any editor, and one vague requirement rewritten until it can be tested.

What is an SRS document?

SRS stands for software requirements specification. It describes what a piece of software has to do, how well it has to do it and the limits it has to work within. The first part is the functional requirements: a user can book an appointment, a manager can cancel one. The second is the non-functional requirements, such as speed, security and availability. The limits are the constraints, like a system it must connect to or a date it must be ready by.

For years the reference outline was IEEE 830, a recommended practice from 1998. It was replaced in 2011 by the international standard ISO/IEC/IEEE 29148, which was revised in 2018. An SRS says what the software must do. How the code is organized to do it belongs in a separate design document.

The sections of an SRS, with a line from each

The example lines below come from one made-up product, a booking tool for a hair salon with two locations. It is an illustration, not a client.

Section	What it holds	Example line
Purpose	Why the software is being built and who the document is for	Let clients book, move and cancel appointments online, so staff stop taking bookings by phone
Scope	What is in this version, and what is not	In: booking, reminders, staff calendars. Out: payments and a mobile app, until a later version
Users and roles	Each kind of person who signs in, and what they may do	Client, stylist, salon manager. Only a manager can change opening hours
Definitions	Words that could be read two ways	"Appointment" means one service with one stylist in one time slot
Assumptions and constraints	What is taken as given, and the limits the build must respect	The salon keeps its current website; the booking pages sit under it
Functional requirements	Each thing the software does, one per line, numbered	FR-3: A client can cancel an appointment up to 24 hours before it starts
Non-functional requirements	How well it must work: speed, security, availability, accessibility	NFR-1: Available times load in under two seconds on a phone over a 4G connection
External interfaces	Other systems it connects to, and how	Sends reminder texts through the salon's existing SMS provider
Data	What is stored, for how long, and who can see it	Client name, phone and booking history, visible to managers only
Acceptance criteria	How each requirement will be checked before it counts as done	FR-3 passes when a cancellation 25 hours ahead goes through and one 23 hours ahead is refused with a clear message

Not every project needs every row. A first version with one kind of user can fold roles into the purpose. A tool that connects to nothing can leave out interfaces. What should never go missing is scope: the line between what is in and what is out is what both sides will point to later.

A template you can copy

Copy the outline into a document and replace each prompt with your own answer. Where you do not know an answer yet, write the question down instead of leaving the heading empty. An open question on paper is worth more than a guess.

1. Purpose. What problem does this software solve, and for whom?
2. Scope. What is in this version? What is deliberately left out?
3. Users and roles. Who signs in, and what may each role do?
4. Definitions. Which words need one agreed meaning?
5. Assumptions and constraints. What existing systems, dates, budgets or rules must the build fit?
6. Functional requirements. Number each one: FR-1, FR-2. One behavior per line.
7. Non-functional requirements. Speed, security, availability and accessibility, each with a measure.
8. External interfaces. Which other systems does it send data to or read data from?
9. Data. What is stored, for how long, and who can see it?
10. Acceptance criteria. For each requirement, the check that proves it works.
11. Open questions. Everything still undecided, with who will decide it.

How do you write a requirement someone can test?

ISO/IEC/IEEE 29148 lists the qualities of a well-written requirement. Among them: necessary, unambiguous, complete, singular, feasible and verifiable. Two of those do most of the work in practice, and one example shows both.

Start with a line found in many first drafts: “The booking page should be fast and easy to use.” It fails twice. It is not singular, because it holds two requirements. It is not verifiable, because nobody can say when “fast” or “easy” has been reached.

Split it first. “The booking page should be fast” becomes one requirement and “easy to use” becomes another. Then give each a measure that a tester can check:

• NFR-1 — Available times load in under two seconds on a phone over a 4G connection.
• NFR-2 — In a usability test with five first-time clients, all five complete a booking without help.

The numbers belong to the salon example. Yours come from what your users need, and where you do not know, that is an open question for the list.

SRS, BRD or user stories: which do you need?

A business requirements document (BRD) explains why the project exists: the business goal, the problem and what success looks like for the organization. An SRS explains what the software must do and how well. User stories carry the functional part of that detail, cut into small pieces a team can build and demo one at a time, each with its own acceptance criteria. Agile teams commonly work from stories rather than one long document.

They are not rivals. For a first version, a short SRS covering purpose, scope, roles, constraints and the non-functional requirements, with the functional detail written as stories, is often enough. How long the document runs should follow how much could go wrong, not a page count.

Who writes it, and what happens to it next?

The person who owns the product writes the first draft, because only they know what the business needs. The developers then question it until every line is clear enough to price. At Devrisen that is what Scope week is for: working sessions that turn an idea or a draft into a written spec, ending in a fixed quote. You can arrive with a spec you have already tested or with an idea and a deadline. See how our MVP scoping works, or read how a quote is built from the spec, part by part. After the build starts, adding a new idea means taking out something just as large, or agreeing a new quote and date together.

The full service behind this post: MVP Development Services for Startups.