Software Requirements Document Template (with Examples)

Requirements documents rarely fail by being too short. They fail by being vague. “The system shall be user-friendly and fast” appears in countless specs, and not one tester on earth can check it. That vagueness turns expensive at the end of a project, when the client says the software isn’t finished and the vendor says it is.

The international reference here is ISO/IEC/IEEE 29148, which replaced the older IEEE 830 standard for software requirements specifications. You don’t need to cite a standard to run a mid-sized project. The underlying idea is worth keeping, though: the requirements document says what the system must do and under which conditions. How it gets built belongs to the design, which the development team owns.

SRS, PRD, BRD: which document do you need?

Terminology varies by company and country, which causes real confusion when a US product team works with a European agency. Here is how the common documents usually split:

Criterion	BRD	PRD	SRS
Typical author	Business sponsor	Product manager	Product owner or analyst
Main question	Why invest?	What problem, for whom?	What exactly must the system do?
Testable requirements		partly
Non-functional targets		partly
Basis for a fixed-price quote		partly

For most projects under a year in length, one document that blends the PRD’s context with the SRS’s testable requirements works best. That is what the template below does. The German equivalent, by the way, is the Lastenheft, written by the client, answered by the vendor’s Pflichtenheft.

Template: 11 sections for a software requirements document

Copy this structure and delete what doesn’t apply.

1. Background. How does the process work today? Which systems, how many users, which problems, with numbers (“invoice approval takes nine days on average”).
2. Goals. Two to four measurable goals with dates, plus one sentence on what is explicitly not a goal.
3. Users and roles. Who uses the system, how often, on which device, with which permissions?
4. Functional requirements. Numbered, one sentence each, each with an acceptance criterion. Grouped by process step.
5. Non-functional requirements. Response times, availability, concurrent users, accessibility level, languages, supported browsers and devices.
6. Data and integrations. Which data must be migrated? Which systems must be connected, and where is their API documentation?
7. Security and privacy. Personal data involved, role model, hosting region, retention and deletion rules (GDPR applies if you handle EU residents’ data).
8. Constraints. Budget range, deadlines, existing infrastructure, mandated technologies.
9. Acceptance criteria. How will the system be tested, by whom, with what test data?
10. Out of scope. What is not included, even if someone might assume it is?
11. Open questions. An honest list of what is still undecided.

Sections 10 and 11 are missing from most templates you’ll find online. They prevent more disputes than the other nine combined.

How to phrase requirements so they can be tested

The gap between a useful spec and a useless one lives in the sentences. Each requirement should be something a tester can tick off with yes or no.

Two conventions make this easier. The first comes from the IETF: RFC 2119 defines MUST, SHOULD and MAY as distinct levels of obligation, and many teams borrow those words for priority. The second is EARS (Easy Approach to Requirements Syntax), developed at Rolls-Royce, which uses fixed sentence patterns:

• Ubiquitous: “The system shall log every failed login attempt.”
• Event-driven: “When a payment fails, the system shall email the customer within five minutes.”
• State-driven: “While the account is locked, the system shall reject all login attempts.”
• Unwanted behaviour: “If the upload exceeds 20 MB, then the system shall show an error and keep the form data.”

These patterns feel stiff. They force you to name the trigger, the actor and the response, which is exactly what vague requirements leave out.

Prefer a user-centred format? The same requirement can be written as a user story with acceptance criteria; our guide on how to write user stories shows how.

Why the document matters when things go wrong

Most custom software contracts attach the requirements, or a statement of work derived from them, as a schedule. When acceptance is disputed, the question becomes simple: does the delivered system meet what the schedule says? If a requirement is missing, it is hard to demand. If it is ambiguous, it will be interpreted, and not necessarily in your favour.

That is also why acceptance criteria belong in the requirements document and not in an email thread three weeks before launch. Our user acceptance testing checklist builds directly on section 9 of the template.

The five most expensive mistakes

Solutions disguised as requirements

“A dropdown listing all customers” is a solution. The requirement is: “A clerk finds a customer among 12,000 records in under ten seconds.” Search with autocomplete might be the better answer, and you’ve just ruled it out.

Missing non-functional requirements

How many concurrent users? Which browsers? Leave this out and you get an app that runs nicely in a demo with three people and falls over on Monday morning with 200.

Forgetting legacy data

Migrating data from an old system can eat a large share of the total effort. If migration is missing from the spec, it is missing from every quote too.

Everything has the same priority

Without priorities, either everything gets built or nothing ships. Tag every requirement as must, should, could or won’t, as explained in our guide to MoSCoW prioritization.

The business doesn’t write it

When IT writes the spec alone, it describes how IT imagines the process. The people doing the work spot the gaps only at acceptance, which is the most expensive moment to find them.

How much documentation does a small project need?

For a web application with a budget of roughly $35k to $90k, 10 to 15 pages usually suffice. Goals, out-of-scope items and acceptance criteria matter more than page count. The rest can be refined during delivery if you work iteratively.

A clear spec is also the only basis for comparable quotes. Without one, each vendor prices a different project in their head. Our breakdown of custom software development cost shows what drives those numbers.

If you want a second pair of eyes on integrations and non-functional targets before you send the document out, a studio like OnlineBuilders, which builds custom software, offers a free initial technical consultation.

Next step: take the template, fill in only sections 2, 10 and 11 first, and show them to two people who will use the system. Their questions become your table of contents for the rest.

Questions people ask

What is the difference between an SRS and a PRD?

A product requirements document (PRD) is usually written by product management and focuses on the problem, users and desired outcomes. A software requirements specification (SRS) goes further into testable functional and non-functional requirements. Small teams often merge both into one document, which is fine as long as the requirements stay testable.

Is IEEE 830 still the standard for SRS documents?

IEEE 830 was superseded by ISO/IEC/IEEE 29148, which covers requirements engineering processes and document contents. You do not need to follow it to the letter, but its section structure is a solid reference for larger or regulated projects.

How long should a requirements document be?

For a mid-sized business application, 10 to 30 pages is realistic. Nobody reads a 100-page specification end to end, and a document nobody reads gives you no protection when a dispute starts.

Who should write the requirements document?

The client or product owner owns it, with input from the people who will use the software daily. A development partner can help draft it, but the business must confirm every requirement, because the document defines what you are paying for.