How to write a software requirements document (with template)

A software requirements document is a written description of what your software must do, who it’s for, the limits it must work within and how you’ll know it’s finished. It’s the single biggest factor in getting accurate quotes, because developers can only price the work you describe. It doesn’t need to be long. It needs to be specific.

Send three software companies a two-line brief and you’ll get three prices you can’t compare, each built on different guesses. Send them the same clear requirements document and the quotes start to describe the same product. This guide covers what goes into one, a free template and example user stories you can copy.

What is a software requirements document?

A software requirements document, also called a software requirements specification (SRS), is the agreed written description of what a piece of software must do and how well it must do it. It’s the reference point for design, development, testing and the contract.

A requirement is a single statement of something the software must do, or a quality it must have, written so that someone can test it. “Clients can upload PDF files up to 20 MB” is a requirement. “The portal should be user-friendly” isn’t, because nobody can prove it’s been met.

The current international standard is ISO/IEC/IEEE 29148:2018, Systems and software engineering: Life cycle processes: Requirements engineering, published in November 2018. The older IEEE 830-1998 recommended practice, which many free templates still copy, is marked as superseded by the IEEE and was replaced by ISO/IEC/IEEE 29148 in 2011.

The 2018 edition is now being revised. ISO lists a draft of the next edition at the draft international standard (DIS) ballot stage from 14 September 2026, so check for a newer edition before you cite one in a contract. You don’t need to buy the standard to write a useful document; you need the discipline behind it.

Why does a software requirements document matter for quotes?

A software requirements document matters because a quote only covers the work you describe. Vague descriptions force developers to guess, while clear requirements turn wide, padded ranges into firm prices you can compare line by line.

Every gap gets filled with an assumption. A careful developer adds contingency to cover what they can’t see. A developer keen to win the work assumes the minimum, then charges for the rest later through change requests: priced changes to the agreed scope. Either way, you pay for the missing detail.

The document matters under either pricing model. A fixed-price contract sets one price for an agreed scope, so it depends on that scope being written down. A time-and-materials contract bills the hours worked, so clear requirements still control the cost by cutting rework.

If you already have a draft, send it to us and we’ll point out the gaps before we price it.

Say a 12-person accounting firm in Leeds (a hypothetical example) asks three companies to quote for “a client portal where clients can upload documents”. One quotes £9,000, assuming uploads and nothing else. Another quotes £38,000, assuming e-signatures, a Xero integration and a mobile app. The third offers a day rate and no total.

None of them is wrong: they’ve priced three different products. With a requirements document listing the users, the 15 Must have stories, the Xero sync and the data to migrate, all three quote for the same thing. The comparison becomes about price, approach and team. Our guide on how to choose a software development company covers what to compare once the quotes arrive.

What should a software requirements document include?

A software requirements document should cover ten things: purpose and goals, users and roles, scope, user stories, functional requirements, non-functional requirements, integrations, data, constraints and acceptance criteria. Shorter templates often stop after non-functional requirements, and the sections they skip are where quotes go wrong.

What is the difference between functional and non-functional requirements?

Functional requirements say what the system does: calculations, workflows, notifications and business rules. Non-functional requirements say how well it does it: speed, security, accessibility, reliability and similar qualities. Both need numbers. “Search returns results in under 1 second for 95% of queries” can be tested; “search is fast” can’t.

For a checklist of qualities, the international product quality model ISO/IEC 25010:2023 groups them into nine characteristics, including performance efficiency, security and reliability. For accessibility, name a level: the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA is the usual target, and our website accessibility guide explains what it covers.

What should the data section say?

The data section lists every type of information the system stores, where it comes from, who can see it and how long you keep it. Personal data deserves the most care, because privacy law shapes the design and differs by country.

In the UK, that means the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018. In Australia, it’s the Privacy Act 1988, which exempts some small businesses, so check whether it covers you. In India, plan for the Digital Personal Data Protection Act 2023: its rules were notified on 13 November 2025, and the main obligations take effect on 13 May 2027, according to AZB & Partners. The US has no general federal privacy law, so list the sector rules and state laws that apply to your customers, such as HIPAA for health data or California’s privacy law.

Software requirements document template

A usable software requirements document template has 13 parts, from document control and goals to acceptance criteria and open questions. Answer each prompt in plain language: a short, specific answer beats a long, vague one, and “not decided yet” is fine as long as you say so.

1. Document control: project name, version, date, author and who approves changes.
2. Purpose and goals: the problem, who has it, and two or three measurable goals with dates.
3. Background: today’s process and tools, and what’s wrong with them.
4. Users and roles: each type of user, roughly how many, and what each can see and do.
5. Scope: what’s in this phase, what’s out, and ideas parked for later phases.
6. User stories: one per need, in the form “As a [user], I need [action], so that [outcome]”, each marked Must, Should, Could or Won’t.
7. Functional requirements: numbered statements (FR-01, FR-02) for business rules, calculations and anything the stories leave unclear.
8. Non-functional requirements: performance, security, accessibility, availability, supported browsers and devices, languages and backups, each with a number.
9. Integrations: each external system, the data exchanged, its direction and frequency, and who owns the account.
10. Data: the main records, their volumes, migration from existing systems, retention periods and the privacy laws that apply.
11. Constraints and assumptions: budget range, deadline, hosting location, required technologies and anything you’re assuming but haven’t confirmed.
12. Acceptance criteria and sign-off: how each Must have will be tested, who signs off, and how defects found after launch are handled.
13. Open questions: decisions still pending, each with an owner and a date.

How do you write user stories and acceptance criteria?

Write each user story as “As a [user], I need [action], so that [outcome]”, then add acceptance criteria that state exactly when it’s done. The UK Government’s service manual uses this format and describes acceptance criteria as a checklist of outcomes, often written as “it’s done when”.

A user story is a short description of a need from the user’s point of view. Acceptance criteria are the testable conditions that prove the story works. Many teams write them in the Given, When, Then format from behaviour-driven development: given a starting situation, when the user does something, then a specific result happens.

Here are three examples for the hypothetical accounting portal.

Story 1. As a client, I need to upload receipts from my phone, so that I don’t have to post paper copies.

• It accepts PDF, JPG and PNG files up to 20 MB each.
• Given I’m logged in on a phone, when I upload a file, then it appears in my document list within 5 seconds.
• The assigned accountant gets an email within 5 minutes of the upload.

Story 2. As an accountant, I need to see which clients haven’t sent their year-end documents, so that I can chase them before the deadline.

• The dashboard lists clients with missing documents, sorted by deadline.
• Given a client uploads every required document, when I refresh the dashboard, then that client no longer appears.

Story 3. As a practice admin, I need to remove a former employee’s access, so that client data stays secure.

• Given I deactivate a user, when they try to log in, then access is refused.
• Every deactivation appears in the audit log with the date, time and admin’s name.

Each story names a user, a need and a reason, and each criterion is something a tester can pass or fail in minutes. That’s what lets a developer estimate the story, and what lets you accept it without argument.

How is a software requirements document different from a project brief?

A project brief is a one or two-page summary of the problem, goals, budget and timeline that starts a conversation. A software requirements document is the detailed, testable description that a fixed quote and a contract can rest on.

You’ll also see two related terms. A business requirements document (BRD) describes the business need and outcomes without much detail about the software. A product requirements document (PRD) is the product-team version of an SRS, common at software companies.

A practical route for most small businesses is to write the brief yourself, then pay for a short discovery phase in which the developer helps turn it into a requirements document. That’s how our own projects begin: discover and plan come before design and build, and you review the plan before any code is written. If you’re building something new and want to keep phase one small, our MVP development guide shows how to scope it.

What are the most common software requirements mistakes?

The most common mistakes are describing solutions instead of needs, leaving qualities like speed and security unmeasured, and forgetting data, integrations and acceptance criteria. Each one shows up later as a change request or a dispute.

• Unmeasured qualities. “Fast”, “secure” and “easy to use” can’t be tested. Give each one a number or a standard.
• Solutions instead of needs. “Add a dropdown” locks in a design. “Let the accountant pick a client in two clicks” leaves room for a better one.
• No roles or permissions. Who can see, edit and delete each record drives a surprising share of the build.
• Forgotten data. Migrating 4,000 messy records from spreadsheets can take as long as building a feature.
• A hidden budget. Sharing a range lets developers propose the right scope instead of guessing.
• Everything in phase one. Without a Must, Should, Could and Won’t split, nothing can be cut when time runs short.
• An outdated template. Templates built on IEEE 830 still work as a starting point, but they predate modern privacy laws such as GDPR and say nothing about user stories.

What to do next

Start with the brief: one page on the problem, the users, the goals, the budget range and the deadline. Then work through the template above, beginning with user stories and acceptance criteria for your Must haves. You’ll find that half the questions a developer would ask are already answered.

Whether you’re comparing custom software against an off-the-shelf product (our custom software vs off-the-shelf guide helps there) or you’re ready to build, a clear software requirements document is the best money-saving step you can take. Inwentions builds web apps, mobile apps and custom software for clients in the USA, UK, Australia and India. Request a quote with your brief or your draft requirements, and we’ll come back with questions, an estimate and a plan you can review.