If you have a software requirement specification to write and you are not sure where to start, the first thing to accept is that the document is not the point. The point is alignment. The SRS is the mechanism through which you get developers, testers, stakeholders, and delivery leads working from the same understanding of what the software must do, how it must behave, and what constraints apply. Get that alignment wrong and the document becomes a liability rather than an asset.
I have written or reviewed SRS documents across government, utilities, health, and enterprise environments over the past 25 years. The ones that caused the most damage on projects were not the ones written badly in terms of prose. They were the ones that looked complete but contained untested assumptions, missing non-functionals, and requirements that different readers interpreted in completely different ways. The ones that worked were specific, structured, and had been challenged before they were signed off.
What Belongs in a Software Requirement Specification
There is no single mandatory format for an SRS, but the sections below represent the structure I return to most often because they give readers a logical path through the document without forcing them to hunt for information.
- Project overview and scope: This sets out why the software is needed, who it serves, and what is explicitly out of scope. Defining the boundary here prevents scope creep later and gives reviewers an early reference point.
- Functional requirements: These describe what the system must do. Each requirement should describe a specific behaviour, interaction, or process outcome. Vague statements like “the system should be user-friendly” are not functional requirements.
- Non-functional requirements: These define how the system must perform. Response times, availability targets, security classifications, accessibility standards, and data retention rules all live here. They are frequently under-specified and frequently the source of late-stage disputes.
- Assumptions and dependencies: Document what you are taking for granted and what the project depends on that is outside your control. If an integration relies on a third-party API that has not yet been confirmed, say so here.
- Constraints: Technology choices already made, regulatory requirements, legacy system limitations, and budget ceilings all constrain what is possible. Recording these protects you when someone later asks why a more elegant solution was not pursued.
- Acceptance criteria: For each significant requirement, there should be a statement of what constitutes satisfactory delivery. If you cannot describe how you would test it, you have not written it clearly enough.
Functional vs Non-Functional Requirements: The Distinction That Actually Matters
Most BAs understand the theory of this distinction. In practice, it gets blurred regularly. Here is how I keep them separated when writing an SRS.
| Requirement Type | What It Describes | Example | Tested By |
|---|---|---|---|
| Functional | What the system does | The system shall allow a registered user to reset their password via email verification | Functional test case |
| Non-Functional | How the system performs | The password reset process shall complete within 3 seconds under normal load | Performance test |
| Functional | What the system does | The system shall generate a monthly usage report in PDF format | Output validation test |
| Non-Functional | How the system performs | The system shall be available 99.5% of the time between 07:00 and 23:00 | Availability monitoring |
Non-functional requirements are particularly important to nail down early because they drive architectural decisions. If you discover six weeks into development that the system needs to support 50,000 concurrent users, you are not tweaking a few requirements; you are potentially rearchitecting the solution. I have seen this happen. It is expensive and demoralising for everyone involved. If you want to go deeper on NFRs, the Non-Functional Requirements Template on this site is worth reviewing before you write that section of your SRS.
A Worked Example: When the Scope Looked Fixed but Was Not
On Project X, I was brought in mid-way through the requirements phase for a case management system being built for a regulatory body (Organisation B). The development team had already started on the basis of a high-level requirements list that the client had signed off at the start of the engagement. When I reviewed what had been captured, I found that the functional requirements covered the core workflow reasonably well, but the non-functional requirements section contained just three lines: the system should be secure, it should be fast, and it should be easy to use. That was it.
I ran a requirements workshop to close the gap. Within two hours, it became clear that Organisation B had an implied requirement that the system must comply with a specific government security framework that mandated data classification, audit logging to a defined standard, and encrypted storage at rest. None of this had been documented. The lead developer, when I raised it, pushed back hard. His position was that the original sign-off document said nothing about this framework and that adding it now would affect the timeline and cost. He was right that it would. But the alternative was delivering a system that the client could not legally use in production.
The friction here was real. The project manager was caught between the client’s legal obligations and the developer’s legitimate concern about scope change. We resolved it by running a formal change request that documented the new requirements, repriced the affected components, and got sign-off from both sides before any additional work started. The SRS was updated to include a dedicated compliance section, and the non-functionals were expanded to 14 specific, testable requirements. The project delivered four weeks later than originally planned but was accepted into production on first pass. Without that conversation, it would either have failed security assurance or been reworked at far greater cost after delivery.
This is why the SRS matters. It is not a formality. It is the place where those conversations get forced to happen at the right time.
How to Gather Requirements Before You Write a Single Line
The quality of your SRS is entirely dependent on the quality of your elicitation. Writing the document is the easier part. Getting the right information out of the right people, in a form that is complete and consistent, is where the real work happens.
- One-to-one interviews with key stakeholders: These surface needs and constraints that people will not share in a group setting. The senior manager who says everything is fine in a workshop will often tell you something very different in a private conversation.
- Collaborative requirements workshops: These are where you identify contradictions between stakeholder groups and work through prioritisation. Conflicts that surface here are far cheaper to resolve than conflicts that surface in UAT. The facilitation skills you bring to these sessions make a measurable difference to what you get out of them.
- Document review and desktop analysis: Existing process documentation, previous system specifications, and regulatory guidance often contain requirements that no one thinks to mention because they assume you already know. Read everything available before your first elicitation session.
- Surveys and structured questionnaires: Useful when you have a large or distributed user base and need to understand patterns in need or priority across a population that you cannot interview individually.
Using more than one technique gives you a cross-check. When what someone told you in an interview contradicts what came out of the workshop, that tension is a signal worth investigating before it becomes a requirement dispute after go-live.
Writing Requirements That Are Testable and Unambiguous
Every requirement in your SRS should pass a simple test: can someone write a test case for it right now, without asking you any further questions? If the answer is no, the requirement is not done yet.
Avoid modal verbs that introduce ambiguity. “The system should allow” is weaker than “the system shall allow.” In many SRS conventions, “shall” denotes a mandatory requirement and “should” denotes a preference. If you use them interchangeably, your development team will resolve the ambiguity themselves, which means they will make the call that you were supposed to make.
Prioritising your requirements using a framework like MoSCoW (Must have, Should have, Could have, Won’t have this time) gives the development team a defensible basis for decisions when time or budget pressure forces trade-offs. Without prioritisation, every requirement looks equally important until something has to be cut, at which point the conversation becomes political rather than analytical. You can read more about how to approach this in the article on Requirements Prioritisation.
Reviewing and Getting Sign-Off on the SRS
An SRS that has not been reviewed is a draft. An SRS that has not been signed off is an opinion. The review and approval process is not a formality to rush through; it is the last opportunity to catch gaps before they cost money.
Run an internal review first. Check for completeness, consistency, and testability. Look for requirements that contradict each other and for sections where the level of detail drops suddenly, which usually indicates a gap in your understanding rather than a gap in the document.
Then take it to stakeholders. Give them structured review guidance rather than asking them to read through and comment generally. Ask them specific questions: are there any scenarios this does not cover? Are there any constraints we have not documented? Are there any requirements here that you would remove as out of scope? Structured review produces better feedback than an open-ended read-through.
Once signed off, the SRS becomes your reference document for scope decisions, change requests, and testing. It does not need to be a long document. It needs to be a clear one. If you are also producing a broader functional specification alongside your SRS, the comparison at Business Requirements Document vs Functional Requirements Document is worth a read to ensure you are not duplicating effort or creating conflicting documents.
The discipline of writing a clear, specific, and signed-off software requirement specification is not about following a process for its own sake. It is about having a document that you and every other person on the project can point to when a decision needs to be made, a dispute needs to be resolved, or a piece of scope needs to be defended. Every hour you put into the SRS at the front of the project is worth at least five hours of rework avoided at the back of it.
Frequently asked questions
What is a software requirement specification?
A software requirement specification (SRS) is a document that describes what a software system must do, how it must perform, and the constraints it must operate within. It covers functional requirements, non-functional requirements, assumptions, and acceptance criteria. It serves as the agreed reference point for development, testing, and change management throughout the project.
What is the difference between functional and non-functional requirements in an SRS?
Functional requirements describe what the system must do, such as specific behaviours, processes, and user interactions. Non-functional requirements describe how the system must perform, covering areas like response times, availability, security, and accessibility. Both types belong in the SRS, and missing non-functionals is one of the most common and costly gaps in software projects.
How long should a software requirement specification be?
There is no fixed length for an SRS; it should be as long as it needs to be to cover all requirements clearly and without ambiguity. A small internal tool might need 10 pages while a complex enterprise system might need 80. The measure of a good SRS is not length but whether every requirement is specific, testable, and understood by all parties.
Who approves a software requirement specification?
Sign-off on an SRS typically involves the project sponsor or client representative, key business stakeholders, and the technical lead or solution architect. Each party confirms that the document accurately reflects what is required and is feasible within the agreed constraints. Without formal approval, the SRS cannot be used as a baseline for scope management or change control.
What are the most common mistakes when writing an SRS?
The most common mistakes are writing requirements that are too vague to test, omitting non-functional requirements entirely, and failing to get formal stakeholder sign-off before development begins. Ambiguous language like ‘user-friendly’ or ‘fast’ creates interpretation gaps that get resolved by developers rather than by the business. A requirement is not complete until someone can write a test case for it without asking any further questions.
Try Ash, Your Virtual BA
If you are working on a software requirement specification right now, Ash can help you structure it, draft functional and non-functional requirements, and check for the gaps that tend to cause problems later in the project. Rather than starting from a blank template, you can work through the document section by section with a BA-trained assistant that understands what good requirements look like in practice. Try Ash Virtual BA and get your SRS moving today.
Further reading
- Recommendation system for agile software development
- Method and system for generating stateflow models from software requirements
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.