Free SRS Template | Software Requirements Specification

What this template includes

We've created a practical SRS template designed specifically for UK SMEs commissioning bespoke software. Unlike the bare-bones templates you'll find elsewhere, ours includes:

8 essential sections covering everything from business context to technical constraints
Guidance boxes in every section explaining what to include and why
Practical examples showing how to describe requirements clearly
UK-specific considerations including GDPR and accessibility guidance
MoSCoW prioritisation framework for ranking requirements

Free download, no signup required. Available in Word and HTML formats.

Infographic showing clear requirements bridging the gap between business vision and developer understanding — Clear requirements bridge the gap between what you envision and what gets built

Which format should you use?

Word format (.docx)

Best for:

Editing and customising the template
Adding your project-specific content
Sharing with development partners for quotes
Collaborative refinement with stakeholders

HTML format

Best for:

Viewing the template structure before downloading
Reference while working in other tools
Printing a clean, formatted copy
Teams that prefer online documents

The 8 essential sections

A well-structured SRS follows a logical flow from high-level business context through to detailed technical requirements. Our template includes all 8 sections:

1Introduction and scope

Project overview, objectives, and boundaries. What's included and explicitly excluded.

2Business context

The business problem, current situation, and desired outcomes with measurable success criteria.

3Users and personas

Who will use the system, their roles, goals, and technical capabilities.

4Functional requirements

What the system must do. Features, user stories, and acceptance criteria.

5Non-functional requirements

How the system should perform. Includes security (GDPR compliance), performance, accessibility (WCAG for public sector), and reliability.

6Integration requirements

Systems to connect with, data flows, and API requirements.

7Data requirements

Data sources, structures, migration needs, and governance requirements.

8Constraints and assumptions

Budget, timeline, technical limitations, and assumptions made during requirements gathering.

How to use the template

Download the Word version to edit directly, or view the HTML version first to understand the structure
Focus on business needs - describe what you want to achieve, not how it should be built technically
Involve all stakeholders - gather input from everyone who will use the system, not just one person
Be specific and measurable - instead of "fast", say "loads within 2 seconds"
Prioritise using MoSCoW - mark each requirement as Must Have, Should Have, Could Have, or Won't Have
Delete guidance boxes before sending to development partners

Tip: Don't try to complete the template alone. The most successful SRS documents result from collaboration:

Draft initial requirements based on your business knowledge
Share early with your development partner for feedback
Refine together through discussion - they'll help identify gaps
Review with all stakeholders before finalising

Common pitfalls to avoid

Research shows that 37% of software projects fail due to unclear requirements. Avoid these common mistakes:

Vague language

Avoid words like "user-friendly", "fast", or "easy". Instead, specify measurable targets: "Page loads within 2 seconds" or "Users complete checkout in under 3 minutes".

Scope creep

Document a clear change process upfront. New requirements that emerge during development should be formally assessed for impact on timeline and budget.

Missing stakeholders

Don't assume one person knows all requirements. Involve representatives from each user group and department that will use the system.

Ignoring non-functional requirements

Security, performance, and accessibility are just as important as features. 48% of projects have issues because these were treated as afterthoughts.

When to use this template

Starting a new project - Create a comprehensive brief before approaching development partners
Getting quotes - Provide consistent, detailed requirements to multiple agencies for accurate comparisons
Discovery phase - Structure your findings after stakeholder workshops and interviews
Internal alignment - Ensure all stakeholders agree on requirements before development begins

Before you send: quick checklist

Use this checklist to ensure your SRS document is ready to share with development partners:

Scope and context

Business problem clearly explained
Project objectives defined
What's in-scope AND out-of-scope stated
All user types identified

Requirements

Each requirement has a unique ID
Requirements are measurable (no vague language)
Priority assigned (Must/Should/Could/Won't)
Acceptance criteria included

Non-functional requirements

Performance expectations specified
Security requirements documented
Accessibility needs considered
Integration points identified

Ready to share

Budget/timeline constraints stated
Assumptions documented
All stakeholders have reviewed
Guidance boxes removed

Frequently asked questions

There's no fixed length - it depends on project complexity. A simple project might need 10-15 pages, while complex systems could require 50+. Focus on completeness rather than page count. The key question is: "Have we documented everything the development team needs to understand what we want built?" Our template guides you through all essential sections, so complete each one thoroughly and you'll have the right level of detail.

No. Business owners are best placed to describe what the software should do - you know your processes, users, and objectives better than anyone. Leave the how (technical implementation) to your development partner. Focus on describing business needs, user workflows, and measurable outcomes. This template includes guidance boxes to help you articulate requirements without technical jargon.

A brief is typically a short summary of what you want - useful for initial conversations. An SRS is comprehensive documentation covering every aspect of the system: users, features, performance, security, integrations, and constraints. Development partners need an SRS (or equivalent detail) to provide accurate quotes and ensure they build exactly what you need. Think of a brief as the starting point, and the SRS as the complete specification.

Changes are normal and expected - the SRS provides a baseline, not a straitjacket. A good development partner will have a formal change control process: you submit a change request, they assess the impact on timeline and budget, and you decide whether to proceed. Document your initial requirements thoroughly to minimise costly surprises, but expect some evolution as you see the software take shape.

Yes, but as a constraint rather than a detailed budget breakdown. In the Constraints section, state your budget range and timeline expectations. This helps development partners scope their proposals appropriately and identify which requirements fit within your constraints. Detailed budgeting belongs in a separate Statement of Work or project plan once you've selected a partner.

Include representatives from all user groups - not just the project sponsor. Sales staff, operations, customer service, and management may all have different needs. Each group should confirm that their workflows and requirements are accurately captured. Missing a stakeholder group often leads to discovering requirements late in development, which is costly to address.

Full template preview

Read the complete template below, or download it in HTML or Word format.

1. Project Overview and Objectives

1.1 Purpose

Guidance: Explain why this software is being built. What business problem does it solve? What pain points are you addressing?

[Describe the business problem this software will solve. Be specific about current pain points and their impact on the business.]

Example: "The current order processing system requires staff to manually enter customer details from emails into our CRM, then separately into our accounting system. This takes approximately 2 hours per day and results in an estimated 5% error rate. The new system will automatically capture order details from incoming emails, create CRM records, and generate invoices."

1.2 Objectives

Guidance: List 3-5 specific, measurable objectives for the project. These should be outcomes, not features.

ID	Objective	Success Metric
OBJ-1	[Objective description]	[How will you measure success?]
OBJ-2	[Objective description]	[How will you measure success?]
OBJ-3	[Objective description]	[How will you measure success?]

1.3 Scope

1.3.1 In Scope

Guidance: List what IS included in this project. Be specific.

[Feature or capability included]
[Feature or capability included]
[Feature or capability included]

1.3.2 Out of Scope

Guidance: Explicitly list what is NOT included. This prevents scope creep and manages expectations.

[Feature or capability explicitly excluded]
[Feature or capability explicitly excluded]

2. Stakeholders and Users

2.1 Project Stakeholders

Name	Role	Responsibilities	Contact
[Name]	Project Sponsor	Final approval, budget authority	[Email]
[Name]	Business Owner	Requirements sign-off, acceptance testing	[Email]
[Name]	Project Manager	Day-to-day coordination	[Email]

2.2 User Types

Guidance: Identify all types of people who will use the system. Different users often have different needs.

User Type 1: [e.g., Administrator]

Attribute	Description
Description	[Who are they? What is their role?]
Technical Ability	[High / Medium / Low]
Frequency of Use	[Daily / Weekly / Monthly]
Primary Goals	[What do they need to accomplish?]

User Type 2: [e.g., Standard User]

Attribute	Description
Description	[Who are they? What is their role?]
Technical Ability	[High / Medium / Low]
Frequency of Use	[Daily / Weekly / Monthly]
Primary Goals	[What do they need to accomplish?]

3. Functional Requirements

Guidance: Functional requirements describe what the software does. Each requirement should be specific, testable, and include acceptance criteria. Use the priority levels: Must Have, Should Have, Could Have, Won't Have (MoSCoW method).

3.1 Feature Group: [e.g., User Management]

ID	Priority	Requirement	Acceptance Criteria
FR-1.1	Must Have	[The system shall...]	[Given... When... Then...]
FR-1.2	Should Have	[The system shall...]	[Given... When... Then...]
FR-1.3	Could Have	[The system shall...]	[Given... When... Then...]

3.2 Feature Group: [e.g., Order Processing]

ID	Priority	Requirement	Acceptance Criteria
FR-2.1	Must Have	[The system shall...]	[Given... When... Then...]
FR-2.2	Must Have	[The system shall...]	[Given... When... Then...]

Example requirement:
ID: FR-2.1
Priority: Must Have
Requirement: The system shall allow authorised users to create new customer records with company name (required), contact name, email, phone number, and billing address.
Acceptance Criteria: Given an authorised user is on the customers page, when they click "Add Customer" and complete the required fields, then a new customer record is created and a confirmation message is displayed.

4. Non-Functional Requirements

Guidance: Non-functional requirements describe how the system should perform - its qualities rather than its features. Be specific with measurable criteria.

4.1 Performance

ID	Requirement	Measurement
NFR-P1	Page load time	[e.g., All pages shall load within 3 seconds on standard broadband]
NFR-P2	Concurrent users	[e.g., System shall support 50 concurrent users without degradation]
NFR-P3	Search response time	[e.g., Search results shall return within 2 seconds]

4.2 Security

ID	Requirement	Measurement
NFR-S1	Authentication	[e.g., Users shall authenticate via username/password with MFA option]
NFR-S2	Data encryption	[e.g., All data shall be encrypted at rest and in transit using TLS 1.3]
NFR-S3	GDPR compliance	[e.g., System shall support data export and deletion requests]

4.3 Reliability

ID	Requirement	Measurement
NFR-R1	Uptime	[e.g., 99.5% availability during business hours (Mon-Fri, 8am-6pm)]
NFR-R2	Backup	[e.g., Daily automated backups with 30-day retention]
NFR-R3	Recovery	[e.g., Full system restore achievable within 4 hours]

4.4 Usability

ID	Requirement	Measurement
NFR-U1	Accessibility	[e.g., WCAG 2.1 Level AA compliance]
NFR-U2	Mobile responsiveness	[e.g., Fully functional on tablets; read-only on mobile phones]
NFR-U3	Browser support	[e.g., Latest versions of Chrome, Firefox, Edge, Safari]

5. Integrations and Data

5.1 External Integrations

Guidance: Document every system the software needs to connect to. Be specific about what data flows where.

System	Integration Type	Data Exchanged	Frequency	Owner
[e.g., Xero]	[API / File / Manual]	[e.g., Invoices, customers]	[Real-time / Hourly / Daily]	[Who provides access?]
[e.g., Salesforce]	[API / File / Manual]	[e.g., Contacts, opportunities]	[Real-time / Hourly / Daily]	[Who provides access?]

5.2 Data Migration

Guidance: Document any existing data that needs to be imported into the new system.

Data Type	Source	Volume	Format	Notes
[e.g., Customer records]	[e.g., Excel spreadsheet]	[e.g., ~5,000 records]	[e.g., CSV]	[Any data quality issues?]

6. Constraints and Assumptions

6.1 Constraints

Guidance: List any fixed boundaries the project must work within.

Type	Constraint	Impact
Budget	[e.g., Fixed budget of £X]	[How does this affect scope?]
Timeline	[e.g., Must launch before March 2026]	[Why is this date important?]
Technology	[e.g., Must integrate with existing Azure infrastructure]	[Any technical implications?]

6.2 Assumptions

Guidance: Document assumptions that, if proven wrong, would affect the project scope or timeline.

ID	Assumption	Risk if Wrong
A1	[e.g., Xero API will remain stable during development]	[Integration rework required]
A2	[e.g., Client will provide test data by Week 4]	[Testing delayed]
A3	[e.g., Existing customer data is clean and complete]	[Data cleansing effort required]

7. Acceptance Criteria

7.1 Definition of Done

Guidance: Define what "complete" means for this project.

The software will be considered complete when:

All "Must Have" requirements have been implemented and tested
All "Should Have" requirements have been implemented or formally deferred
User acceptance testing has been completed with sign-off from [stakeholder name]
Documentation has been provided including [list documentation deliverables]
Training has been delivered to [number] users
[Add additional criteria as needed]

7.2 User Acceptance Testing

Test Scenario	Description	Expected Outcome	Tester
UAT-1	[e.g., Create new customer and order]	[e.g., Customer and order appear in system and sync to Xero]	[Name]
UAT-2	[Test scenario description]	[Expected outcome]	[Name]

8. Timeline and Commercial Terms

8.1 Project Milestones

Milestone	Deliverables	Target Date	Payment
Discovery Complete	Approved SRS document	[Date]	[Amount or %]
Development Complete	Working software in test environment	[Date]	[Amount or %]
UAT Complete	Signed-off user acceptance testing	[Date]	[Amount or %]
Go-Live	Production deployment and training	[Date]	[Amount or %]

8.2 Change Control

Changes to requirements after sign-off will be managed as follows:

Change requests must be submitted in writing
Development partner will assess impact on timeline and cost within [X] business days
Changes require written approval from [stakeholder name]
Approved changes will be documented as an addendum to this SRS

Appendix A: Glossary

Term	Definition
[Term 1]	[Definition - explain any business-specific or technical terms]
[Term 2]	[Definition]
[Term 3]	[Definition]

Appendix B: Sign-Off

By signing below, the parties confirm that they have reviewed this Software Requirements Specification and agree that it accurately represents the software to be developed.

Client Sign-Off

Name:
Role:
Signature:
Date:

Development Partner Sign-Off

Name:
Role:
Signature:
Date:

Related tools

Infographic showing software cost components: Discovery and Planning, Core Development, Features and Integrations, and Testing and Launch

Bespoke software cost estimator

Get a ballpark cost for your bespoke software project. Answer a few questions about your requirements and get an instant estimate.

2 minutes Estimate now

Infographic showing how technical debt drains productivity across different system age brackets

Technical debt calculator

Calculate how much legacy code is costing your business annually. Build a business case for modernisation with hard numbers.

2 minutes Calculate now