How to write a software requirements specification: Complete guide for UK businesses
· Ihor Havrysh
A software requirements specification (SRS) is a document that describes what software needs to do and how it should perform. It acts as a contract between you and your development partner, ensuring everyone agrees on what will be built before coding begins. Like blueprints for a house, it defines every room and feature - so there are no surprises when the building is complete.
If you're commissioning bespoke software for your UK business, getting the requirements right is the single most important factor in project success. Yet most guides on this topic are written for developers, not for the business owners who actually need to communicate their needs.
This guide is different. It's written for non-technical business owners who need to work effectively with development partners. You'll learn what to include, how to gather requirements from your team, common mistakes that derail projects, and you'll get a practical template you can download and use.
The evidence is clear: Projects with documented requirements are 97% more likely to succeed. Yet 70% of project failures are attributed to poor requirements gathering. Investing time in this phase isn't optional - it's the single biggest factor in project success.
What is a software requirements specification?
A software requirements specification (often called an SRS, or sometimes a software requirements document) is a detailed description of what your software needs to do. It covers:
- What problems it solves - the business challenges driving the project
- Who will use it - different types of users and their needs
- What it does - the features and functions (functional requirements)
- How it should perform - speed, security, reliability (non-functional requirements)
- What it connects to - integrations with existing systems
- What success looks like - acceptance criteria for each feature
Why is it called a "specification"?
The word "specification" is deliberate. Like an engineering specification for a manufactured product, an SRS defines precise requirements that can be tested. A requirement like "the system should be fast" is vague. A specification like "search results must load within 2 seconds for 95% of queries" is testable.
Both parties agree on what will be delivered. No "I thought you meant..." discussions later.
Development partners can provide fixed-price quotes when requirements are clear.
Acceptance criteria make it clear when each feature is complete and working correctly.
If disputes arise, the SRS is the reference point for what was agreed.
Why clear requirements matter
Poor requirements are the leading cause of software project failure. According to the Standish Group's CHAOS Report, only 31% of IT projects end successfully. Research consistently shows that fixing a requirement error during development costs 5-10 times more than catching it during the requirements phase. Fixing it after deployment can cost 100 times more.
UK context: A 2025 Gearset study found that 82% of UK IT teams report software delays as standard, with deployment cycles significantly below industry benchmarks. UK enterprises face average annual costs of £107,000 per organisation due to these delays alone.
The hidden costs of unclear requirements
Beyond direct project costs, unclear requirements cause:
- Scope creep - features keep being added because the original scope wasn't clear
- Rework - features built to the wrong specification must be rebuilt
- Delays - unclear requirements cause development to pause for clarification
- Relationship breakdown - disagreements over what was agreed damage working relationships
- Unusable software - in extreme cases, the delivered software doesn't meet business needs
When you need an SRS (and when you might not)
Not every project needs a 50-page specification document. The level of formality should match the project's size, complexity, and risk.
You definitely need a formal SRS when:
- The project budget exceeds £20,000
- Multiple stakeholders have input into requirements
- The software will be used by external customers
- You're working with a new development partner for the first time
- The project has regulatory compliance requirements (GDPR, FCA, healthcare)
- The software will integrate with multiple existing systems
- You want a fixed-price contract rather than time-and-materials
You might need a lighter approach when:
- The project is under £10,000
- You have an established relationship with your development partner
- The project is an extension of existing software they built
- Requirements are genuinely simple and unlikely to change
- You're using an agile approach with ongoing involvement in sprints
Even for smaller projects, document your requirements in writing. A detailed email or short brief is better than verbal agreements. You can always scale up to a full SRS if the project grows.
Not sure what you need? If you're unsure whether your project needs a formal SRS or a lighter approach, we can help. Get in touch for an honest assessment - we'll tell you what level of documentation makes sense for your situation.
The 8 essential sections of an SRS
While SRS formats vary, most effective documents include these core sections. We'll explain each in plain English with examples.
This section explains why you're building the software. It should clearly state:
- The business problem you're solving
- The objectives and success criteria
- The scope - what's included and explicitly what's not
- Any constraints (budget, timeline, technology restrictions)
"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 - reducing processing time to under 15 minutes daily with near-zero errors."
Identify everyone who will use or be affected by the software. Different user types often have different needs:
- Primary users - people who use the system daily
- Occasional users - people who use it periodically
- Administrators - people who manage users, permissions, settings
- External users - customers, suppliers, partners
For each user type, describe their technical ability, what they need to accomplish, and how often they'll use the system.
Functional requirements describe what the software does - the features and capabilities. Each requirement should be specific, testable, and include acceptance criteria.
"The system should allow users to manage customers."
"The system shall allow authorised users to: (a) create new customer records with company name, contact details, and billing address; (b) edit existing customer records; (c) mark customers as inactive without deleting their data; (d) search for customers by name, email, or postcode. Acceptance criteria: User can find any customer record within 3 clicks from the dashboard."
Non-functional requirements describe how the software should perform - its qualities rather than its features:
- Performance - page load times, concurrent users, response times
- Security - authentication, data encryption, access controls
- Reliability - uptime targets, backup requirements
- Usability - accessibility standards, mobile responsiveness
- Scalability - ability to handle growth in users or data
"Performance: Dashboard pages must load within 3 seconds on a standard broadband connection. The system must support 50 concurrent users without degradation. Security: All data must be encrypted at rest and in transit (TLS 1.3). The system must comply with GDPR requirements including right to deletion."
Document every system your software needs to connect to:
- Existing systems - CRM, accounting, ERP, email
- Third-party services - payment processors, shipping APIs
- Data migration - existing data that needs importing
- Data flows - which data goes where, how often, who's the source of truth
Include API documentation links where available, and clarify who's responsible for providing access credentials and technical support for each integration.
Be explicit about the boundaries and assumptions underlying the project:
- Budget constraints - if budget is fixed, say so
- Timeline constraints - any hard deadlines (regulatory, seasonal)
- Technology constraints - must use specific platforms or avoid others
- Assumptions - e.g., "we assume Xero's API will remain stable"
Documenting assumptions protects both parties. If an assumption proves wrong, it's clear that scope needs revisiting.
Acceptance criteria define how you'll know when each requirement is complete. They should be specific enough that anyone could test them:
- Given a logged-in admin user, when they click "Add Customer", they see a form with fields for company name (required), contact name, email, phone, and billing address
- When the form is submitted with valid data, a new customer record is created and the user sees a confirmation message
- When the form is submitted with missing required fields, validation errors are displayed without losing entered data
While often covered in a separate contract, the SRS should reference:
- Delivery milestones - key dates and what's delivered at each
- Payment schedule - how payments align with milestones
- Change control process - how requirement changes are handled
- Warranties and support - what happens after delivery
How to gather requirements
Requirements gathering is a collaborative process. Here are practical techniques for working with your team to capture what the software needs to do.
Step 1: Document your current process
Before thinking about software, map out how things work today. Create a simple flowchart showing each step in your process, who does it, what inputs are needed, and what outputs are produced. This reveals pain points and ensures you don't lose important steps in the new system.
Step 2: Identify pain points with the right questions
Use structured questions to extract useful information from your team:
- How questions: How do you currently do this? How will you know it's complete?
- Where questions: Where does the process start? Where do errors typically occur?
- When questions: When is this task most critical? When does it fail?
- What questions: What takes too long? What workarounds have you created?
Step 3: Write requirements as user stories
Express requirements from the user's perspective using this format:
"As a [specific user type], I want to [action/capability], so that [business benefit]."
Example: "As a warehouse manager, I want to see low-stock alerts on my dashboard, so that I can reorder before items run out."
This format ensures you capture who needs the feature, what they need to do, and why it matters to the business.
Step 4: Involve actual users in discovery workshops
The people who'll use the system daily often know requirements that managers miss. Run structured workshops that include:
- Brief icebreaker and context setting (15 minutes)
- Discussion of current pain points using brainstorming (30-40 minutes)
- Definition of requirements using user stories (40-50 minutes)
- Documentation and action items (20 minutes)
Step 5: Prioritise ruthlessly using MoSCoW
You'll always want more features than budget allows. Prioritise using the MoSCoW method (see next section) to ensure the most valuable features are built first.
Tip: Focus on problems, not solutions. "Reduce order processing time from 2 hours to 15 minutes" is better than "build an automated email parser". Let your development partner propose the technical approach.
Prioritising requirements (MoSCoW method)
Not all requirements are equally important. The MoSCoW method helps you categorise requirements so the most valuable features are built first, and you can make informed decisions if budget or timeline constraints require cuts.
| Priority | Meaning | Example | Guidance |
|---|---|---|---|
| Must have | Essential for launch. Without these, the software doesn't solve the core problem. | User login, core data entry, essential reports | If any "must have" is cut, reconsider whether to proceed at all. |
| Should have | Important but not critical. Significant value, but you could launch without them. | Email notifications, dashboard widgets, export to Excel | Plan to include these, but they can slip to phase 2 if needed. |
| Could have | Nice to have. Would improve the experience but not essential. | Dark mode, keyboard shortcuts, advanced filters | Include if time and budget permit. Good candidates for future releases. |
| Won't have | Explicitly out of scope. Agreed exclusions to manage expectations. | Mobile app (web only), multi-language support | Documenting what's excluded is as important as what's included. |
Tip: A good rule of thumb is that "must haves" should be no more than 60% of your total requirements. If everything is a "must have", you haven't prioritised properly - and you're setting yourself up for scope creep.
Need help prioritising? We run structured discovery workshops that help you identify what really matters. Book a free consultation to discuss your project.
Good vs poor requirements (examples)
The difference between good and poor requirements often comes down to specificity. Here are examples showing common patterns.
Example 1: Search functionality
"The system should have a good search feature."
What's "good"? What can be searched? How should results display?"Users can search orders by customer name, order number, or date range. Results display within 2 seconds, show order status, customer name, total value, and order date, sorted by most recent first. Maximum 50 results per page with pagination."
Example 2: User permissions
"Different users should have different access levels."
What levels? What can each level do? Who assigns them?"Three user roles: Admin (full access including user management and settings), Manager (can create and edit orders, view reports), Staff (can create orders, view own orders only). Admins can assign roles when creating or editing users."
Example 3: Integration
"The system should integrate with Xero."
What data? Which direction? How often? What if it fails?"When an order is marked complete, the system automatically creates a sales invoice in Xero with: customer name (matched by email), line items, and payment terms from customer record. Sync runs every 5 minutes. Failed syncs are logged and admins receive email notification."
Common mistakes to avoid
These mistakes derail projects regularly. Being aware of them helps you avoid them - and the UK has some costly examples of what happens when requirements go wrong.
Vague requirements
"The system should be user-friendly" means different things to different people. Be specific: "First-time users should be able to create an order without training."
Assumed knowledge
Don't assume the development team knows your industry. Explain acronyms, describe processes, define terms. Better to over-explain than leave gaps.
Solution-focused instead of problem-focused
"Build a dashboard with 6 charts" is solution-focused. "Enable managers to see daily sales, top products, and stock levels at a glance" is problem-focused and gives developers flexibility to design the best solution.
Not involving end users
Managers often describe what they think staff need. The people who'll use the system daily often have different priorities. Include them in discovery.
Scope creep through verbal agreements
"Oh, and it should also do X" in a meeting isn't documented. Requirement changes should go through a formal change process and be reflected in the SRS.
Ignoring non-functional requirements
Focusing only on features while ignoring performance, security, or accessibility leads to software that works but can't be used effectively in production.
Lessons from UK project failures
The UK has seen some of the most expensive software project failures in the world, many directly caused by poor requirements. These aren't ancient history - they offer valuable lessons for any business commissioning software today.
Post Office Horizon Scandal
Cost: Over £1 billion in compensation (still accumulating)
A system repurposed from a failed project without proper requirements reassessment. Known bugs were not communicated to users, and 12,000-15,000 monthly technical support calls were dismissed rather than treated as a requirements problem.
NHS National Programme for IT
Cost: £9.8 billion spent, minimal sustainable benefits
A centralised system imposed on 46 diverse NHS trusts without involving clinical staff in requirements. Managers reported feeling "ignored" and "done unto". The "replace all" strategy was driven by technology, not clinical needs.
TSB Bank Migration (2018)
Cost: £330 million loss, 80,000 customers lost, CEO resigned
Migration designed around a business deadline rather than technical requirements. Pre-production testing was eliminated. Only 1 of 2 data centres was tested before go-live. The 24-month timeline was "unprecedented" for the complexity involved.
GOV.UK Verify
Cost: £154 million invested, 73% shortfall on targets
Unrealistic goals were set without departmental buy-in. HMRC developed their own system (Government Gateway) because Verify was "inadequate for their department's needs". Only 6.7 million users vs 25 million target.
Warning signs your requirements are inadequate
Before development begins, watch for these red flags that suggest requirements need more work:
- Vague terms like "good performance" without specific metrics
- Requirements that cannot be mapped to test cases
- Missing non-functional requirements (security, performance, accessibility)
- Timelines based on business preference, not technical assessment
- No formal change control process defined
- Key stakeholder groups not engaged in discovery
- No formal sign-off or approval documented
- Requirements don't trace back to business objectives
- Requirements specify implementation details rather than problems to solve
- Legacy system integration not explicitly addressed
Research shows that 80% of software rework traces back to requirements defects. Fixing a defect in the requirements phase costs 1x. In the design phase, it costs 3-6x. During development, 10-20x. During testing, 50-100x. And in production? 100-1,000x. The case is clear: invest in requirements upfront.
Template and examples
We've created a practical SRS template designed for UK SMEs commissioning bespoke software. It includes all 8 sections discussed above with guidance notes and examples to help you get started.
How to use the template
- Download the Word version to edit directly, or the HTML version to view in your browser
- Replace the placeholder text with your project details
- Delete the guidance boxes before sending to your development partner
- Use the template as a starting point for discussions, not a finished document
Tip: Don't try to complete the template alone. Share it with your development partner early - they can help you elaborate technical requirements and ensure nothing is missed.
Ready to discuss your project? Whether you have a completed brief or just an idea, we're happy to talk through your requirements. Get in touch for a free, no-obligation conversation about what you're trying to achieve.
Working with your development partner
The SRS is a collaborative document. Here's how the process typically works with a professional development agency:
You provide a high-level overview of what you need - 1-3 pages covering your problem, goals, and rough budget.
The agency runs workshops, interviews stakeholders, reviews existing systems, and gathers detailed requirements. This typically takes 2-6 weeks.
The agency produces the SRS document based on discovery findings. They translate your business needs into technical specifications.
You review the SRS, ask questions, and request changes. Expect 2-3 rounds of revision. This is normal and valuable.
Both parties agree the SRS is complete. This typically precedes final quoting and contract signing for the development phase.
Tip: Some agencies charge for discovery as a separate phase, others include it in the overall project cost. A paid discovery phase often produces better results because the agency can invest proper time without rushing to get to billable development work.
Looking for a development partner? We specialise in bespoke software for UK businesses. Our discovery process produces clear, testable requirements that set projects up for success. Learn more about our approach or get in touch to discuss your project.
Legal and IP considerations
While this isn't legal advice, here are important considerations for UK businesses commissioning software. Getting these right upfront prevents costly disputes later.
The SRS as a contractual document
Under English law, your requirements specification typically becomes part of your software development contract - either explicitly incorporated or attached as a schedule. This means the documented requirements establish legally binding obligations. If the development team delivers software that doesn't meet the documented requirements, this may constitute breach of contract.
Important: Courts interpret ambiguous requirements against the drafter - usually the development team. This incentivises clarity, but you shouldn't rely on judicial interpretation to resolve ambiguities that should be clarified during development.
Who owns the SRS?
Under UK copyright law, the default position is that the creator of a document owns the copyright. If a business analyst employed by your development partner writes the SRS, they (or their employer) technically own it unless your contract specifies otherwise.
Standard practice is for the client to own intellectual property in requirements developed specifically for their project. The development agency may retain ownership of reusable methodologies, tools, or templates. Ensure your contract explicitly addresses this - it matters if you later want to get quotes from other suppliers, maintain the documentation yourself, or bring development in-house.
For investors and acquirers: IP ownership chains face intense scrutiny during due diligence. Unclear ownership of requirements documentation or software code can derail transactions or substantially reduce valuations. Maintain written evidence of all IP assignments from day one.
Confidentiality
The SRS contains detailed information about your business processes, competitive positioning, and strategic plans. Even without explicit provisions, English law recognises implied confidentiality obligations when information is shared in circumstances where a reasonable person would understand it to be confidential. However, relying on implied obligations is risky - always have a non-disclosure agreement in place before sharing sensitive information during discovery.
Liability for defective requirements
Who bears liability if requirements are wrong? The answer depends on how your contract allocates responsibility:
- If you (the client) provide inaccurate requirements - you typically bear the liability if software is built as documented but doesn't meet your actual needs
- If the development team elaborates your requirements and the resulting specification is defective - they may bear liability
- Most contracts establish shared responsibility: you provide accurate business context; they translate it accurately; both validate before development
Most software contracts include limitation of liability clauses that cap damages. These are enforceable under UK law if clearly stated and genuinely agreed. However, you cannot exclude liability for gross negligence or intentional misconduct.
GDPR considerations
If your software processes personal data, your requirements should address GDPR compliance: data retention, deletion rights, consent management, and data portability. See the ICO's guidance for details.
Related reading
For more on software project contracts and IP, see our guides on what is bespoke software and bespoke software costs in the UK.
