Software requirements document template (free SRS you can copy)

How to fill in this software requirements document template

1. Copy the section headingsPaste the eight numbered headings below into a shared doc. Keep the numbering so people can point to “section 4, FR-012” in conversations.
2. Write purpose and scope firstAgree on why the software exists and what is out of bounds before anyone writes a single requirement.
3. List users, then their requirementsWrite functional requirements from each user’s point of view. Every requirement should belong to a role from section 3.
4. Add numbers to the quality sectionNon-functional requirements only help if they can be measured, so write “loads in under 2 seconds”, not “fast”.
5. Review it with the people who will use itWalk through the document with real users and the developer. Questions they ask are gaps you need to fill.
6. Version it and keep it currentPut a version number and date at the top. When something changes, update the document rather than deciding it in chat.

1. Purpose

One or two short paragraphs on why this software is being built. Anyone who reads only this section should understand the problem and the outcome you want.

• The problem in plain words, and who has it today.
• What will be different once the software exists.
• The document version, date and owner.
• Example: “This document describes a booking and invoicing app for Harbor Pool Service. Today, jobs are scheduled by phone and tracked in a spreadsheet, and invoices go out late. The app will let customers book online and send invoices automatically when a job is marked done.”

2. Scope

Scope draws the boundary. The “out of scope” list matters as much as the “in scope” list, because it prevents arguments later.

• In scope: the main features or modules in this version.
• Out of scope: things people might assume are included but are not.
• Phases: what is planned for a later version.
• Platforms: web, iPhone, Android, desktop, or a mix.
• Example: “In scope: online booking, technician schedule, invoices and card payments. Out of scope: payroll, inventory. Later phase: customer mobile app.”

3. Users and roles

List every type of person who will log in or be affected, and what each one is allowed to do. This section drives permissions, screens and testing.

• Role name and a one-line description.
• What each role can see, create, edit and delete.
• Roughly how many people hold each role, now and in a year.
• Example: “Office manager: sees all jobs, edits schedules, issues refunds. Technician: sees only their own jobs for the day, marks jobs done, adds photos. Customer: books, pays and sees their own history.”

4. Functional requirements

This is the core of the software specification template: what the system must do. Give each requirement an ID, a priority and a test. Use this format for every one:

• ID: FR-012
• Role: Technician
• Requirement: The technician can mark a job as done from a phone, add up to 10 photos and a note.
• Rules: A job cannot be marked done without at least one photo. The time is recorded automatically.
• Priority: Must have (other options: Should have, Nice to have).
• How we will check it: Mark a test job done with no photo and confirm it is blocked; add one photo and confirm it saves and triggers the invoice in FR-020.
• Tip: group requirements by area (Booking, Scheduling, Invoicing) and write one behavior per requirement. If a sentence has “and also”, split it.

5. Non-functional requirements

How well the software must work. Developers use this section to choose hosting, architecture and security measures, so be specific.

• Performance: “Pages load in under 2 seconds on a normal 4G connection.”
• Availability: “Booking must be available around the clock; planned maintenance happens overnight with notice.”
• Security: “Staff logins use two-factor authentication. Card details are handled by the payment provider and never stored by us.”
• Compliance: any rules that apply, such as HIPAA for health data or PCI for card payments.
• Usability and accessibility: “Technician screens work one-handed on a phone. Customer pages meet WCAG 2.1 AA.”
• Scale: expected users, records and growth.
• Backups: “Data is backed up daily and can be restored within one business day.”

6. Integrations

Every other system the software talks to. Integrations are where projects most often grow in cost, so name them early.

• System name and what it is used for.
• Direction: does data flow in, out, or both?
• Trigger and frequency: real time, every hour, nightly.
• Who owns the account and API keys.
• Example: “QuickBooks Online: paid invoices sync out within 5 minutes. Google Calendar: technician jobs sync one way to their personal calendars.”

7. Data

What information the system stores, where it comes from and how long it is kept.

• Main records and their key fields (customer, job, invoice, technician).
• Existing data to import, its source and rough size.
• Retention and deletion rules.
• Reports and exports people need.
• Example: “Import about 2,400 customers and 3 years of job history from the current spreadsheet. Keep invoices for 7 years. Office manager can export any list to CSV.”

8. Acceptance criteria

How you will decide the software is finished and ready to launch. Agree on this before the build starts.

• All “Must have” requirements pass their checks from section 4.
• Non-functional targets from section 5 are met in testing.
• Who signs off, and how long they have to test each round.
• What counts as a launch-blocking bug versus one that can be fixed after launch.
• Example: “Launch when the office manager and two technicians have run one full week of real jobs in the app with no blocking bugs.”

Common mistakes in software requirements documents

• Describing screens instead of needs. Write what the user must accomplish and let the designer propose the screen.
• Vague words with no number: fast, easy, secure, scalable.
• No “out of scope” list, so every assumption becomes a dispute.
• Requirements with no owner or role attached.
• Hiding business rules in people’s heads. If the office “always” does something, write it down.
• Treating the document as finished. It should change as you learn, with each change dated.
• Writing 80 pages before talking to a developer. A short, clear SRS reviewed early beats a long one written alone.