Software Requirements Specification
[Project Name]
Prepared for: [Client Organisation]
Prepared by: [Development Partner]
Version: 1.0
Date: [Date]
| Version |
Date |
Author |
Changes |
| 0.1 |
[Date] |
[Name] |
Initial draft |
| 1.0 |
[Date] |
[Name] |
Final approved version |
Table of Contents
1. Project Overview and Objectives
2. Stakeholders and Users
3. Functional Requirements
4. Non-Functional Requirements
5. Integrations and Data
6. Constraints and Assumptions
7. Acceptance Criteria
8. Timeline and Commercial Terms
Appendix A: Glossary
Appendix B: Sign-Off
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: |
|