How to Write a Software Requirements Specification: Template

The most expensive sentence in a software project is "that's not how we understood it". Proposals obtained without a specification cannot be compared, because every vendor prices a different scope; and once the project starts, the scope debate continues until it ends the project. A good specification doesn't have to be a thirty-page document; ten sections of testable sentences on ten pages is enough for most enterprise projects.

This article shares those ten sections, the rules for writing requirements, a user-story and acceptance-criteria example, and the checklist to run before going out for proposals. The aim is a template an organization can fill in on its own.

What a specification is, and what it isn't

A specification describes what the software must do and why; it does not describe how. Database schema, framework choice and screen design are the bidder's job. The organization only writes its constraints: "must integrate with the existing SAP", "our data stays in-country", "corporate sign-in through Active Directory". Writing the technical solution into the specification prevents the vendor from proposing a better one and shifts responsibility for a wrong solution onto the organization.

The ten-section template

#	Section	Must contain	Common mistake
1	Purpose and business goal	A measurable target: "order approval time from 2 days to 2 hours"	Unmeasurable phrases like "digitalize", "efficiency"
2	Scope and out of scope	Which processes, departments, locations; and explicitly what is left out	No out-of-scope list
3	Stakeholders and roles	User roles and counts, decision maker, product owner	No product owner assigned
4	Process flows	Current and target flow, exceptions (returns, cancellations, partial deliveries)	Only the happy path is drawn
5	Functional requirements	Numbered, one-sentence, testable; MoSCoW priority	Vague words like "etc.", "when needed", "fast"
6	Data and integration	Master data objects, owning system, data direction, migration of existing data	Integration reduced to one line: "will talk to the ERP"
7	Non-functional requirements	Performance, security, privacy, accessibility, mobile, language	Not written at all; "of course we expected that" later
8	Constraints	Technology, infrastructure, budget range, critical dates	An unjustified "end of year" deadline
9	Acceptance criteria and testing	How each requirement is verified, who owns acceptance testing, test data	Acceptance meaning "if we like it"
10	Deliverables, maintenance and ownership	Source code, documentation, training, warranty period, maintenance scope, code ownership	Not stating who owns the source code

Rules for writing requirements

A requirement is a single sentence that two people cannot understand differently and that can be verified by a test. Four rules:

One sentence, one requirement. Two requests joined by "and" are two requirements.
Be measurable. Not "fast", but "a 500-row list opens in under 2 seconds".
Who, what, why. "The warehouse supervisor, to see stock shortages before shipping, sees missing lines as a warning while approving the order."
Prioritize. Must, Should, Could, Won't (not in this phase). A specification where everything is "Must" has no priorities.

Weak	Strong
The system should support reporting.	The sales manager can export monthly revenue by dealer and product group to Excel. (Must)
It should be user-friendly.	A new user completes the order-creation flow without help after a 30-minute training. (Should)
It will integrate with the ERP.	An approved order is created as a sales order in SAP within 5 minutes; on failure the operations team receives an e-mail. (Must)
It should be secure.	Corporate users sign in with Active Directory; access to customer data is role-based and every access is logged. (Must)

User story and acceptance criteria example

Story US-014 (Must)
As a dealer manager, I want orders exceeding the credit limit to go to approval,
so that orders carrying collection risk are not shipped without control.

Acceptance criteria
1. If order amount + open balance exceeds the dealer's credit limit, the order moves to "Awaiting Approval".
2. When the regional manager approves, the order returns to the normal flow; on rejection the dealer receives a notification with the reason.
3. The credit limit is pulled from SAP daily; if SAP is unreachable, the last known limit is used with an "outdated" warning.
4. Orders awaiting approval that are not handled within 48 hours trigger a reminder to the regional manager.

This format lets the vendor derive the pricing, the developer the design and the test team the scenario from the same text. Acceptance testing becomes ticking the criteria one by one; the "we like it / we don't" debate disappears.

The minimum list of non-functional requirements

Performance: concurrent users, response-time targets for critical screens, data volume (record counts, annual growth).
Security and identity: authentication method, role model, password/session policy, penetration-testing expectations.
Privacy and compliance: personal data inventory, retention periods, deletion/anonymization, access logs, data residency.
Accessibility and devices: supported browsers, mobile use, offline needs.
Continuity: backups, acceptable downtime, maintenance window.
Language and localization: interface languages, currency, date formats.

Six common mistakes

Writing the solution: "In a microservice architecture, with React" — unless these are constraints, they don't belong.
Describing the current screen: "Make it like the current program" inherits the old system's mistakes too.
Not writing what's out of scope: If accounting integration is out, say so; otherwise the proposal assumes it's in.
Forgetting data migration: Moving old data is a separate requirement and usually the most laborious part of the project.
Not writing acceptance criteria: A project with undefined acceptance has undefined delivery.
One person writing it: The specification is not complete until the users who live the process have read it.

Checklist before going out for proposals

The business goal is written as one measurable sentence.
Scope and out-of-scope lists exist separately.
The target process flow is drawn with its exceptions and approved by users.
Every functional requirement is numbered, one sentence, prioritized.
Systems to integrate, data objects and data directions are in a table.
Non-functional requirements cover the minimum list.
Critical dates are justified and a budget range is stated.
Acceptance criteria and the acceptance-test owner are defined.
Source-code ownership, documentation, training and maintenance expectations are written.
A product owner is assigned with a decision-time commitment.

Frequently asked questions

How long should a specification be?

As long as the scope. 5–8 pages for a single-module application, 15–25 for a multi-role integrated platform is typical. What matters is not length but every sentence being testable.

Should the vendor write the specification?

The organization should write the first draft; the vendor clarifies it with questions during discovery and deepens the requirements analysis. Leaving the specification entirely to the vendor carries the risk of the scope being shaped in the vendor's interest.

Is a specification needed in an agile project?

Yes, in a different form: instead of a long requirements list, a goal, scope, constraints and a prioritized story list. Even if acceptance criteria are written sprint by sprint, the purpose and out-of-scope sections are needed from the start.

Conclusion

A good specification answers what and why in measurable sentences, states what is out of scope, tabulates integration and data migration, and ties every requirement to an acceptance criterion. It makes proposals comparable, the project measurable and delivery indisputable.

To prepare your specification together, or review your existing draft in a discovery meeting, see our enterprise application development process. The discovery call and first estimate are free.