Software Requirements Specification Template: How to Write an SRS

A software requirements specification (SRS) is a document that describes what a piece of software must do, who will use it, and the constraints it has to work within. The free software requirements specification template below has 10 sections built on the questions I ask in a discovery phase, so you can fill it in once and send the same document to every developer you want a quote from. It's deliberately lighter than the IEEE-style templates that fill the search results, because most small and mid-sized business projects don't need that much ceremony.

I'm a freelance developer based in Denmark, so I'm usually the one reading these documents. The advice comes from that side of the table: what makes a spec easy to price, and what makes a developer pad the quote.

The short answer: how detailed should your SRS be?

The page counts are my rough estimate, not a rule. For most SME projects the middle column is the right level, and it's what this template is built for. The SRS belongs to the very first phase of a build, and you can see where it fits in my overview of the software development process from idea to launch.

What an SRS is (and what it isn't)

An SRS collects the requirements for a system in one place. They fall into two groups. Functional requirements describe what the software does, for example "a customer can download their invoices". Non-functional requirements describe how it has to behave: how fast, how secure, where the data lives and what happens when something breaks.

If you've searched for an SRS template, you've probably come across IEEE 830. That standard has been superseded by ISO/IEC/IEEE 29148, which covers requirements engineering more broadly, yet plenty of templates online still copy the old structure. Both are written with large engineering organizations in mind. A 20-person company commissioning a customer portal needs the same core ideas in a fraction of the space.

Three things an SRS is not:

• A design. Wireframes and mockups can go in an appendix, but the requirements should make sense without them.
• A technology decision. Specify a framework and you'll get quotes from people who know that framework, not necessarily from the people best placed to solve your problem. Choosing between, say, Laravel and Next.js is usually the developer's call, unless you have a concrete reason such as an existing in-house team.
• A contract. It often becomes an appendix to one, but it doesn't settle price, ownership or liability.

How much detail you need also depends on how you plan to run the project. In an agile setup the document is shorter, because details get settled as you go. I compare the two approaches in agile vs waterfall.

The template: 10 sections

Copy the headings into a blank document and answer the questions under each one. You don't need an answer to everything. An honest "not sure yet" is worth more than a guess, because it shows the developer where to dig.

1. Background and goals

Describe the problem as it is today. This is the section a developer reads first, and it shapes how they read everything else.

• What's the problem, and who feels it?
• What does it cost you now in hours, errors or lost customers? A rough estimate is fine.
• A year from now, how will you know the project worked?

2. Users and roles

Users drive login, permissions and a large share of the cost.

• What types of users are there: customers, staff, admins, partners?
• Roughly how many of each, today and in two years?
• What can each role see, create, edit and delete?
• Are they at a desk or on a phone out in the field? That decides whether you need a web app, a native app or a PWA, which I compare in web app vs native app vs PWA.

3. Current workflow

Walk through how the work gets done now, step by step. This is where hidden requirements live: the email someone always sends, or the spreadsheet only one person understands.

• What do you use today: spreadsheets, email, paper or an older system?
• What does a typical task look like from start to finish?
• What works well and must be kept?

4. Functional requirements, prioritized

Write each requirement as an action: who needs to do what, and why. Number them (R1, R2, R3) so you and the developer can refer to them in quotes and meetings. The format is close to user stories, and one requirement may later be split into several.

For example: "R7, must have: A field technician can mark a job as done on their phone, so the office can invoice the same day."

Then label each one must have, should have or later. That's a simplified version of MoSCoW prioritization, which recommends that must-haves typically take up no more than about 60% of the effort.

5. Data

Data is often the most expensive part to get right, and the easiest part to forget.

• What will the system store: customers, orders, documents, images?
• Is there personal data, and is any of it sensitive? Under GDPR, that affects where it's stored and who can access it.
• Does existing data need to be migrated? How much, from which system, and how messy is it?
• How long must data be kept, and who needs to export it?

6. Integrations

List every system the software needs to talk to. An integration can take anything from a few hours to several weeks, depending on what the other system exposes.

• Which systems: accounting (Xero, Fortnox, QuickBooks), CRM (HubSpot, Salesforce), payments (Stripe), sign-in with Microsoft or Google accounts, inventory?
• Does data flow one way or both ways, and how often?
• Does the system have a documented API, and do you have access to it? If you don't know, write down the product name and plan, and the developer can check.

7. Security, performance and hosting

These are the non-functional requirements. They sound dull, but they can change both the architecture and the price.

• Does data need to stay in the EU because of GDPR, customer contracts or your industry?
• How bad is an hour of downtime? A full day?
• How many people use it at the same time at peak?
• Do you need two-factor login, an audit log of who changed what, or accessibility for users with disabilities? If you sell to consumers online, the European Accessibility Act may apply to you. Check with an adviser if you're unsure.

8. Out of scope

Write down what isn't included this time. No section prevents more arguments later, because everyone can see it was a decision and not an oversight.

• Features pushed to a later phase
• Platforms that aren't included, such as iOS and Android apps
• Work you'll do yourself, such as copywriting, images or data entry

9. Budget, timeline and decision-making

It's tempting to leave the budget out so you don't give anything away. It backfires. Without a range, a developer can't tell whether you want a lean build or a thorough one, and you get quotes that can't be compared. If you have no feel for the level, my guide to what custom software costs gives typical ranges in euros.

• What budget range are you working with?
• Is there a deadline, and what happens if it slips?
• Who makes decisions, and how many hours a week can that person give the project?

10. After launch

Software needs looking after once it's live. Describe what you expect.

• Who handles hosting, updates and backups?
• What support do you expect when something breaks, and how fast?
• Who owns the code, and what documentation do you need at handover? My view is that the client should own the code from day one.

Finally, attach appendices: existing material, sketches, screenshots of the tools you use today and examples of products you like.

How to fill in the template in six steps

1. Start with the goal. Finish section 1 before you write a single requirement. If you can't describe the problem in a few sentences, it's too early to list features.
2. Talk to the people who'll use it. Walk through the workflow with two or three of them, ideally at their screen while they work. They'll mention things management doesn't know exist.
3. Write everything down, then sort. Once the list is complete, give each requirement a priority. If more than half end up as must-haves, you haven't prioritized the list, you've just relabeled it.
4. Make requirements testable. Replace vague words with something you can check, as in the tip above. This is where most misunderstandings get caught.
5. Collect open questions in one place. Anything you don't know should be written as a question, not hidden in confident-sounding wording. The developer can then answer it in the quote instead of guessing.
6. Have an outsider read it. Ask a colleague who isn't involved to explain back what the software should do. Whatever they misunderstand, a developer will too.

Using your SRS to get comparable quotes

The main job of an SRS is to make quotes comparable. That only works if everyone gets the same input and is asked the same things.

• Send the same version to everyone, and share answers to questions with all of them, not just the one who asked.
• Ask for quotes that reference your requirement numbers, so you can see what's in and what's out.
• Ask for one price for the must-haves alone and one for everything. Then you know what it costs to start small.
• Pay attention to the questions. A developer who asks good questions has read the document. One who sends a price within an hour without asking anything has probably guessed or added a buffer.

This matters even more when you compare developers across borders. A Danish freelancer, a Polish agency and a UK contractor all price from different rate levels, so the only fair comparison is against the same document. If prices still vary wildly, the spec can probably be read in more than one way. That's a signal to clarify, not to pick the cheapest.

When you shouldn't write one yourself

The template doesn't fit every situation. Here are three where you're better off without it:

• When you don't understand the problem well enough yet. A paid discovery phase with a developer works better, because their questions expose gaps you can't see yourself. I run fixed-price discovery phases before larger builds myself, and the output is exactly the kind of spec this template points toward.
• When the job is small. For a well-defined task of a few days, an email with the problem, an example and a deadline is enough.
• When off-the-shelf software could cover it. A short list of requirements for comparing existing SaaS tools is more useful than a build spec.

It's also perfectly fine to contact a developer without an SRS. A short description of the problem is enough for a first call.

Next steps

Once the template is filled in, run through this checklist before you send it out.

My pricing page explains how a fixed-price discovery phase leads to a fixed price for the build itself.

Frequently asked questions

Who should write the SRS, the client or the developer?+

Both, but you own the content. You know the business, the users and the problem, while the developer knows which technical questions need answers. The most efficient route is often for you to write a first draft with the template and have the developer complete it in a discovery phase. Make sure your agreement gives you the rights to the result, so you can use it with other developers.

What's the difference between an SRS and a BRD?+

A business requirements document (BRD) describes what the business needs and why, while an SRS describes what the software must do in enough detail to build and price it. Large organizations often keep them separate, written by different people. For a small or mid-sized project one document is enough: sections 1 and 3 of this template cover the business side, and the rest is the SRS.

Is a software requirements specification legally binding?+

Not on its own, but it often becomes binding in practice when it's attached to the contract. It then defines what the developer has agreed to deliver, and changes have to be agreed and priced. That's one more reason to keep requirements concrete and the out-of-scope list explicit. For larger projects, have a lawyer review the contract itself.

Can I use AI to write my SRS?+

Yes for structure and wording, no for the content. An AI assistant doesn't know your workflows, your data or your priorities, and it can fill the document with generic requirements that look thorough but don't fit your business. Use it to find gaps instead, for example by asking it which questions a developer would raise about your draft.