SRS Explained: The Engineering Contract for a System

A Software Requirements Specification is the document engineering builds against and tests against. Where the FRD states what the system must do, the SRS states what must be true of it: the interfaces in detail, the data definitions, the performance and availability it must meet, the constraints it cannot violate, and the criteria by which it will be accepted.

It is the most technical of the requirements documents and the most frequently written badly — usually because it is produced to satisfy a process rather than to answer questions engineers actually have.

What it is for#

Three purposes, and if a section serves none of them it can be cut:

1. A shared understanding precise enough that two engineering teams would build compatible systems.
2. A basis for verification — every requirement stated so that a test can demonstrate it.
3. A contract, particularly where a supplier is involved, defining what "delivered" means.

That last purpose is why SRS documents survive in regulated and contracted work long after lighter methods have replaced them elsewhere. When delivery is a commercial commitment, ambiguity has a price, and it is paid by whoever wrote the vaguer sentence.

Structure that holds up#

The long-standing structure — introduction, overall description, specific requirements, appendices — is fine, and the international standard commonly referenced for requirements engineering is ISO/IEC/IEEE 29148. Do not adopt a template wholesale without asking what each section is for.

Introduction and scope. What the system is, who it serves, what it deliberately excludes.

Overall description. Context and dependencies, users and their characteristics, operating environment, assumptions and constraints. The assumptions section is worth real attention: it is where "we assume the upstream system provides a unique customer identifier" gets written down before it becomes a crisis.

Specific requirements. Functional behaviour with identifiers; external interfaces at field level; data definitions with types, ranges, formats and validation; and the non-functional requirements below.

Acceptance criteria. How each requirement will be demonstrated.

Appendices. Glossary — genuinely useful, because most requirement disputes are vocabulary disputes — plus references and open issues.

Non-functional requirements decide the architecture#

This is the section most often filled with numbers nobody derived, and it matters more than the functional list, because functional requirements can usually be added later while non-functional ones are architectural.

State each with a number and a condition:

• Performance. Which operation, at what percentile, under what concurrent load. "Response time under two seconds" without a percentile and a load is not a requirement.
• Volume and growth. Records today, growth per year, peak versus average, the largest single transaction.
• Availability. Target, measured how, and the maintenance windows excluded from it.
• Recovery. How much data may be lost (RPO) and how long recovery may take (RTO). These two numbers do more to shape a design than anything else on the page.
• Security. Authentication, authorisation model, encryption in transit and at rest, audit requirements, retention.
• Accessibility. Name the standard and level. In the European Union, the Accessibility Act has been enforceable since 28 June 2025, and the harmonised standard EN 301 549 tracks WCAG — build to WCAG 2.2 AA unless you have a specific reason not to.
• Compliance and residency. Which regimes apply, where data may be stored, what must be retained and for how long.

A number that was never derived from anything is worse than no number, because it will be designed to. If a figure is a placeholder, label it as one with a date to resolve it.

Interfaces are where integration projects fail#

For every interface: the protocol, the format, the fields with types and constraints, the authentication method, expected volumes, timeout behaviour, retry policy, idempotency, error codes and their meanings, and who to contact when it misbehaves.

The two rows that are almost always missing are what happens when the other side is unavailable and whether repeating a request is safe. Those omissions cause duplicate orders, lost messages and the class of defect that appears only under load.

Writing requirements that can be verified#

Same discipline as the FRD, applied harder. Each requirement gets an identifier that is never reused, states one thing, uses "shall" for obligations, and names the condition under which it applies.

Then, for each: how would we prove this? If the answer is "inspect the code" or "the developer confirms", it is not verifiable, and it will not be verified.

Keep the requirement free of the solution. "The system shall store the audit trail in a relational database" is a design decision wearing a requirement's clothes; the requirement is that audit records are retained for seven years, are immutable, and are retrievable within a stated time.

Why SRS documents get archived#

Written to be approved, not used. Length is mistaken for rigour. Nobody reads it, so nobody finds the contradictions until build.

Frozen at signature. Delivery learns things; if the document cannot change without a three-week process, it will simply not change, and its authority quietly transfers to whatever the team believes.

Full of unverifiable statements. A document where a third of the requirements cannot be tested teaches everyone that requirements are decorative.

No glossary. Two teams using "customer" to mean different things will agree on every sentence and build incompatible systems.

Non-functional section copied from the last project. Nothing damages credibility faster than an availability target nobody costed and a performance figure nobody measured.

A realistic starting point#

For a system of moderate complexity: scope and exclusions, assumptions and dependencies, a numbered functional requirement list grouped by capability, an interface specification per integration, a data dictionary, the non-functional table with derived numbers, acceptance criteria, a glossary, and an open-issues list with owners and dates.

Then have an engineer who was not involved read it and mark every sentence they would need to ask a question about. That single review finds more than a formal approval cycle.

FAQ#

What is the difference between an FRD and an SRS?#

The FRD states what the system must do in business terms; the SRS states the full engineering specification, including interfaces at field level, data definitions and non-functional requirements. On many projects they are combined, which is fine — provided the engineering detail actually exists somewhere.

Do agile teams write an SRS?#

Frequently not as a single upfront document, and sometimes they should. Where a system is contracted, regulated, safety-relevant, or integrating deeply with third parties, the precision is worth it. A reasonable middle path is a living specification for the durable facts — interfaces, data, constraints, non-functional targets — with stories carrying the increments.

How long should it be?#

As long as the interfaces and constraints require, and no longer. Length correlates with being ignored. If it cannot be reviewed in sections by the people who care about each section, it will be approved without being read.

Who owns it?#

Engineering, with business analysis input. Owned solely by the business it drifts from what is buildable; owned solely by a supplier it tends to describe what they intended to build anyway.

How do we handle changes?#

With a version, a date, a change record and a named approver — and a process light enough that people actually use it. The failure mode is not too many changes; it is changes that happen in reality and never reach the document.

What if requirements are genuinely unknown?#

Record them as open issues with an owner and a date, and design for the decision to arrive late. Unknowns are normal. Unknowns disguised as decided requirements are how a system gets built around an assumption nobody agreed to.

Is the SRS the same as the technical design?#

No, and keeping them separate is worth the discipline. The SRS states what must be true; the design states how it is achieved. Merging them makes it impossible to change the implementation without appearing to change the requirement.

Related Articles#

Come from the FRD and the BRD, trace each requirement through the RTM, and demonstrate fitness for purpose in UAT.

What else is coming for SRS