A Software Requirements Specification (SRS) is the contract between what the business needs and what developers or vendors deliver. A good one prevents most disputes and change requests.
A practical SRS outline
- Purpose, goals and scope (what's in and out)
- Users and roles
- Current and future process flows
- Functional requirements, numbered and prioritised
- Business rules and exceptions
- Reports and dashboards
- Integrations and data exchange
- Data migration needs
- Non-functional requirements: speed, availability, security, languages
- Acceptance criteria for each key requirement
Write requirements people can test
Each requirement should be clear, single and testable. “The system should be user-friendly” can't be tested. “A cashier can complete a three-item sale in under 30 seconds” can.
Capture the exceptions
Normal flows are easy; exceptions cost money. For every process ask: what about returns, cancellations, partial quantities, approvals above a limit, and different branches?
Use the MoSCoW priorities
Mark each requirement Must, Should, Could or Won't (this time). It focuses the budget and makes vendor comparisons fair.
Get the right sign-off
Each department owner should approve the sections that affect them. Sign-off turns the SRS into the baseline for testing and change control.
Key takeaway
If a requirement can't be tested, rewrite it. If an exception isn't written down, assume it won't be built.
