How to Write a Software Requirements Document (SRD Template)

A Software Requirements Document (SRD) — also called an SRS (Software Requirements Specification) — is the most important document in any software project. It defines what the software should do, how it should perform, and what constraints it must meet. A good SRD prevents scope creep, aligns stakeholders, and gives developers a clear target.

This guide shows you how to write one, complete with a template you can use immediately.

Why You Need a Requirements Document

| Without SRD | With SRD | |-------------|---------| | "That's not what I asked for" | Clear, documented expectations | | Scope creep and budget overruns | Defined scope with change process | | Developers guess at requirements | Developers build to specification | | Testing is ad-hoc | Test cases map to requirements | | Stakeholder conflicts | Aligned understanding |

Projects with clear requirements are 3x more likely to succeed than those without.

SRD Template Structure

1. Introduction

| Section | Content | |---------|---------| | Purpose | What is this document for? What software does it describe? | | Scope | What does the software do and NOT do? | | Definitions and acronyms | Define all technical terms and abbreviations | | References | Link to related documents (business case, design docs) | | Overview | How this document is organized |

Example:

Purpose: This document defines the requirements for the ACME Customer Portal, a web application that allows customers to manage their accounts, track orders, and submit support requests.

Scope: The portal covers customer-facing functionality only. Internal admin features are covered in a separate Admin Portal SRD. The portal does not include payment processing (handled by Stripe integration).

2. Overall Description

| Section | Content | |---------|---------| | Product perspective | How does this fit into the larger system? | | User classes | Who will use the software? What are their roles? | | Operating environment | Where will it run? (browsers, devices, OS) | | Constraints | Budget, timeline, regulatory, technical limitations | | Assumptions | What are you assuming to be true? | | Dependencies | What external systems or services does it depend on? |

User classes example:

| User Class | Description | Access Level | |-----------|------------|-------------| | Customer | End user who manages their account | View/edit own data | | Support Agent | Internal staff handling support tickets | View customer data, manage tickets | | Admin | System administrator | Full access |

3. Functional Requirements

Functional requirements describe what the system does — the features and behaviors.

How to write good functional requirements

Each requirement should be:

• Specific — no ambiguity about what's expected
• Measurable — you can verify whether it's met
• Atomic — one requirement per statement
• Traceable — tagged with a unique ID
• Prioritized — must-have, should-have, or nice-to-have

Template for each requirement

| Field | Example | |-------|---------| | ID | FR-001 | | Title | User Registration | | Description | The system shall allow new users to create an account using email and password | | Priority | Must have | | Acceptance criteria | User can register with valid email, receives confirmation email within 60 seconds, can log in after confirming | | Dependencies | Email service integration (FR-015) |

Example functional requirements

User Authentication:

| ID | Requirement | Priority | |----|------------|----------| | FR-001 | Users shall register with email and password | Must | | FR-002 | Users shall log in with email/password or social login (Google, Apple) | Must | | FR-003 | System shall send password reset email within 60 seconds of request | Must | | FR-004 | System shall lock accounts after 5 failed login attempts for 30 minutes | Must | | FR-005 | Users shall enable two-factor authentication via SMS or authenticator app | Should |

Order Management:

| ID | Requirement | Priority | |----|------------|----------| | FR-020 | Users shall view a list of all their orders, sorted by date (newest first) | Must | | FR-021 | Users shall filter orders by status: pending, shipped, delivered, cancelled | Must | | FR-022 | Users shall view detailed order information including items, quantities, prices, and tracking number | Must | | FR-023 | Users shall cancel orders that have not yet shipped | Must | | FR-024 | System shall send email notification when order status changes | Should |

4. Non-Functional Requirements

Non-functional requirements describe how the system performs — quality attributes and constraints.

Performance requirements

| ID | Requirement | Metric | |----|------------|--------| | NFR-001 | Page load time shall be under 2 seconds for 95th percentile | < 2s (p95) | | NFR-002 | API response time shall be under 500ms for 99th percentile | < 500ms (p99) | | NFR-003 | System shall support 10,000 concurrent users | Load test verified | | NFR-004 | Database queries shall complete within 100ms | < 100ms average |

Security requirements

| ID | Requirement | |----|------------| | NFR-010 | All data in transit shall be encrypted using TLS 1.3 | | NFR-011 | Passwords shall be hashed using bcrypt with minimum 12 rounds | | NFR-012 | Session tokens shall expire after 24 hours of inactivity | | NFR-013 | System shall log all authentication attempts with IP and timestamp | | NFR-014 | System shall comply with GDPR for EU user data |

Reliability requirements

| ID | Requirement | |----|------------| | NFR-020 | System availability shall be 99.9% (excluding planned maintenance) | | NFR-021 | System shall recover from any single-component failure within 5 minutes | | NFR-022 | Data shall be backed up every 6 hours with 30-day retention | | NFR-023 | Recovery Point Objective (RPO) shall be 1 hour |

Scalability requirements

| ID | Requirement | |----|------------| | NFR-030 | Architecture shall support horizontal scaling to 100,000 concurrent users | | NFR-031 | Database shall support 10TB of data with no performance degradation | | NFR-032 | System shall auto-scale during traffic spikes (Black Friday, campaigns) |

Usability requirements

| ID | Requirement | |----|------------| | NFR-040 | New users shall complete core workflow within 3 minutes without documentation | | NFR-041 | Interface shall conform to WCAG 2.1 AA accessibility standards | | NFR-042 | Application shall be fully functional on screens 320px wide and above |

5. External Interface Requirements

| Interface | Description | |-----------|------------| | User interface | Web (responsive), iOS app, Android app | | API interfaces | REST API for third-party integrations | | Hardware interfaces | N/A (cloud-hosted) | | Communication | HTTPS, WebSocket for real-time updates |

6. Data Requirements

| Aspect | Detail | |--------|--------| | Data model | Link to ER diagram or describe key entities | | Data migration | What data migrates from existing systems? | | Data retention | How long is data kept? Archival policy? | | Data privacy | PII handling, GDPR compliance, data deletion |

7. Appendices

• Wireframes or UI mockups
• Glossary
• Change log (version history of this document)
• Sign-off page

Best Practices

Do's

• Involve all stakeholders — developers, designers, product owners, end users
• Use consistent language — "shall" for must-have, "should" for nice-to-have
• Keep it living — update the document as requirements evolve
• Write acceptance criteria — every requirement should have a testable condition
• Version control — track changes and maintain history

Don'ts

• Don't specify implementation — describe what, not how. "System shall store user data" not "System shall use PostgreSQL with JSONB columns"
• Don't use vague language — "fast," "user-friendly," "secure" are not requirements. Use measurable criteria.
• Don't make it too long — a 200-page SRD that nobody reads is worse than a 20-page one everyone references
• Don't treat it as final — requirements change. Have a clear change request process.

Common Mistakes

1. Too vague — "The system should be fast" → "API responses shall be under 500ms at p99"
2. Too technical — writing implementation details instead of requirements
3. Missing non-functionals — forgetting performance, security, and scalability
4. No prioritization — everything marked as "must have" = no prioritization
5. No user involvement — writing requirements without talking to actual users
6. Gold plating — including requirements nobody asked for or needs

Need Help with Requirements?

Writing comprehensive requirements is a skill. Our enterprise software team includes business analysts who work with your stakeholders to define clear, complete requirements documents — ensuring your project starts on the right foundation.

Get a free consultation and we'll help you scope and document your software project.

Related Resources

• Enterprise Software Development Cost
• Enterprise Software Development Process
• Custom Software vs Off-the-Shelf
• Digital Transformation Strategy