How to write a software requirements specification
Complete guide for UK businesses with practical examples and common mistakes to avoid.
Read article
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.
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.
