Software requirements specification: structure and checklist

Why a software requirements specification matters

A software requirements specification (SRS), often called a statement of work or terms of reference, records exactly what the vendor builds and how you will verify it. Without one, each side understands the scope differently, and the dispute surfaces at acceptance — when fixing things costs the most.

The data backs this up. PMI's Pulse of the Profession research found that 47% of unsuccessful projects missed their goals because of inaccurate requirements management. NASA engineers measured how the cost of a requirements error grows over a project: if fixing it during requirements costs 1 unit, the same fix costs 3–8 units in design, 21–78 units in integration and test, and 29 to more than 1,500 units in operations.

A good specification does three jobs:

• it is the basis for the estimate — the vendor prices a list of requirements, not a general idea;
• it sets the acceptance rules — every feature has a criterion that shows whether it is done;
• it separates scope from wishes — anything outside the document is handled as a change request.

Brief, specification and contract: what is the difference

A brief is a questionnaire for the first estimate, the specification is a detailed description of the system, and the contract is the legal frame the specification is attached to. Each has a different author and timing.

Win to Win follows this order in its own templates: a three-page development brief (in English and Russian) for a quick estimate, and a specification template drafted as Annex 1 to the services contract. In the W2W template, if the specification and the contract conflict, the contract prevails.

The 12 sections every specification needs

A working specification answers why, for whom, what exactly, connected to what, when, and how it is accepted. The structure below follows the W2W template, which has 15 sections in total including terms, exclusions and signatures:

1. General information — system name and a measurable goal: not "speed up work" but "cut request processing from 2 hours to 15 minutes".
2. Current state and problems — how the process runs today, which spreadsheets and tools are used, where time is lost.
3. System components — web portal, admin panel, mobile app, integrations.
4. User roles and permissions — who can do what, and what they cannot do.
5. Functional requirements — a numbered list (FR-1.1, FR-1.2…) with an acceptance criterion for each item.
6. Non-functional requirements — speed, supported browsers and OS versions, interface languages, backups.
7. Security and hosting — where the server sits, how access is granted, whether actions are logged.
8. Integrations — which systems, which data, which direction, and who provides access.
9. Client inputs — credentials, content, reference data, with deadlines and owners.
10. Stages, timeline and deliverables — what is handed over after each stage.
11. Acceptance procedure — where and on what test data results are checked.
12. Out of scope — what is explicitly not included.

Large government and enterprise systems in CIS countries often follow the interstate standard GOST 34.602-2020 on specifications for automated systems, which took effect on 1 January 2022 and replaced the 1989 version. For a commercial web platform or mobile app that level of detail is usually more than you need.

How to write requirements you can actually accept

A requirement is good when anyone can say "done" or "not done" without debate. That means every item carries an acceptance criterion — a concrete check, not a judgement like "user-friendly" or "fast".

The international standard ISO/IEC/IEEE 29148 lists nine characteristics of a well-formed requirement: necessary, appropriate, unambiguous, complete, singular, feasible, verifiable, correct and conforming. In practice, three checks catch most problems:

• one function per item — "users log in and can reset their password" is two functions; split them or accept them together on purpose;
• no vague adjectives — instead of "fast loading", write "a page opens in under 2 seconds with 100 concurrent users";
• a testable criterion — "a blocked user cannot log in" takes a minute to verify.

Non-functional requirements people forget

Non-functional requirements describe how the system works rather than what it does: speed, compatibility, reliability and security. They are the ones most often skipped — until the app fails on older phones or nobody set up backups.

At minimum, write down:

• performance — page load time at a given number of concurrent users;
• compatibility — browsers (for example current Chrome, Safari, Edge and Firefox), minimum screen width for responsive layouts (360 px in the W2W template), minimum iOS and Android versions;
• interface languages — they drive the volume of copy and testing;
• design — whose brand guidelines apply and how many rounds of mockup approval are included;
• reliability — backup frequency (at least daily in the W2W template) and retention period;
• security — personal accounts for server access, an admin action log, HTTPS.

If the system processes personal data, state the data storage requirements separately and check them against the laws of each country where you operate before development starts.

Common specification mistakes

Most mistakes are not about technology but about something missing from the document. Check yours against this list:

• no measurable goal — nobody can tell later whether the project succeeded;
• roles not described — permissions surface during testing and break the logic;
• integrations named but not specified — no one knows who grants access to the external system or which data flows where;
• client obligations left out — content and credentials arrive late and the timeline slips; the W2W template states that delays in client inputs shift deadlines proportionally;
• no out-of-scope section — content population, branding, licences and servers are assumed to be included;
• a solution instead of a problem — the client specifies a button rather than the user's need, leaving no room for a simpler option.

Specification checklist before you sign

Run through these 10 questions before approving a specification. Any question the document cannot answer is a risk.

1. Is the system goal written with a number?
2. Are all modules and platforms listed?
3. Is there a roles table with permissions and limits?
4. Does every functional requirement have an ID and an acceptance criterion?
5. Are speed, browsers, iOS and Android versions and languages specified?
6. Is hosting defined, along with backup frequency?
7. For each integration, are the data, direction, method and access owner clear?
8. Is there a list of client inputs with deadlines and owners?
9. Is the work split into stages with a clear deliverable for each?
10. Is there an out-of-scope section?

A specification does not have to be final before the first line of code. In an agile setup it is refined during analysis and design, and the pricing model should match how certain the scope is — see fixed price vs time and materials.

Where to start

Start with a brief: describe the goal, users, must-have launch features and integrations. It takes under an hour and gives a vendor enough to produce a first estimate.

Then:

• download the brief and specification templates — the same forms W2W uses with its clients (PDF to read, DOCX to fill in; the specification template is in Russian);
• book a 30-minute call — after it, W2W prepares a commercial proposal within 2–3 days;
• see how the W2W process works: the specification and architecture are approved during the design stage, before development begins.