Software Requirements Specification (SRS): What It Is, Template and Worked Example

A software requirements specification (SRS) is a document that describes what a software system must do, how well it must do it, and the constraints it has to respect. It turns business needs into testable requirements, so the people who pay for the product and the people who build it agree on scope before anyone writes code.

In other words, the SRS is the contract between the business and the engineering team. At Severus we spend much of our time as the translator between those two sides. This guide shows how a good SRS document looks, how it differs from a BRD, and how to write one without drowning your team in paperwork.

What is SRS in software engineering?

In software engineering, an SRS sits between the business case and the design. The business side explains why the product should exist. The SRS then states what the system has to do to deliver that outcome. Finally, the design and code decide how.

A typical SRS covers four things:

• Functional requirements: the behaviour the system must show, such as “the user can reset a password by email”.
• Non-functional requirements: quality attributes like performance, security, availability and usability.
• Interfaces: the users, other systems, APIs and hardware the software talks to.
• Constraints: regulation, budget, technology choices and anything else the team cannot change.

The international reference for this work is ISO/IEC/IEEE 29148, which covers requirements engineering across the life cycle. It replaced the older IEEE 830 recommended practice, which many templates online still quote.

SRS vs BRD vs functional specification

These three documents often get mixed up. However, each one answers a different question and speaks to a different reader.

Document	Main question	Written for	Typical content
Business requirements document (BRD)	Why the business needs it and which outcome matters	Sponsors, founders, budget holders	Goals, scope, stakeholders, success measures
Software requirements specification (SRS)	What the system must do, and how well	Product, engineering, QA, suppliers	Functional and non-functional requirements, interfaces, constraints
Functional specification	How each feature behaves in detail	Designers, developers, testers	Screens, flows, rules, field-level logic

For small teams, the SRS and functional specification often merge into one document. By contrast, the BRD should stay separate, because it belongs to the business owner. Our guide on how to write a business requirements document covers that step in depth.

SRS template: a structure based on ISO/IEC/IEEE 29148

The outline below follows the SRS content suggested in ISO/IEC/IEEE 29148. You can copy it as a starting SRS template and cut any section that adds nothing to your project.

1. Introduction: purpose, scope, product overview, definitions and references.
2. Product perspective: where the system fits, including users, other systems and interfaces.
3. Product functions: a short summary of the main capabilities.
4. User characteristics: who uses the system and what they already know.
5. Limitations, assumptions and dependencies: anything outside the team’s control.
6. Specific requirements: functions, usability, performance, data, design constraints, compliance and quality attributes.
7. Verification: how the team will prove that each requirement works.
8. Appendices: glossary, acronyms, supporting models and open questions.

Section 6 is the heart of the document. For quality attributes, many teams borrow the categories in ISO/IEC 25010, such as security, reliability and maintainability. Our article on non-functional requirements and their impact explains each type with examples.

How to write a software requirements specification step by step

Writing a software requirements specification is mostly a conversation, not a writing exercise. The steps below keep that conversation focused.

1. Start from the business goal. Confirm the outcome, the budget range and the deadline. Without these, every requirement looks equally important.
2. Identify stakeholders and users. List who uses, pays for, supports and approves the system.
3. Gather needs. Run interviews, workshops and process walk-throughs. Look at real data and real screens, not only opinions.
4. Draft requirements as single, testable statements. Give each one an ID, a priority and a source.
5. Add non-functional requirements and constraints. Security, UK GDPR, performance and integrations belong here.
6. Review with both sides. Walk the business through the scope, then ask engineering to challenge feasibility and estimates.
7. Agree acceptance criteria. QA should be able to write a test for every requirement.
8. Baseline and control changes. Version the document and record who approved each change and why.

If you still need to find out what to build at all, do discovery first. Our product discovery guide shows how to validate the problem before you specify the solution.

Worked example: a user onboarding feature

To make this concrete, here is a short extract from an SRS for a B2B SaaS onboarding flow. The IDs, priorities and acceptance criteria show the level of detail developers and testers need.

Functional requirements

• FR-01 (Must): The system shall let an invited user create an account from the invitation link within 7 days of sending.
• FR-02 (Must): The system shall require email verification before the user can view company data.
• FR-03 (Should): The system shall let an admin resend or cancel an invitation.
• FR-04 (Could): The system shall show a three-step setup checklist after first login.

Non-functional requirements

• NFR-01 (Must): The system shall store passwords only as salted hashes.
• NFR-02 (Must): The sign-up page shall meet WCAG 2.2 level AA.
• NFR-03 (Should): The account creation request shall complete within 2 seconds for 95% of requests under expected load.

Acceptance criteria for FR-01

• Given a valid invitation under 7 days old, when the user submits the form, then the system creates the account.
• Given an expired invitation, when the user opens the link, then the system shows an “invitation expired” message and a request-new-link option.

Note that the numbers here come from the example, not from a rule. Your own targets should come from real usage data and agreed business priorities. For more on writing behaviour-level requirements, read our piece on functional requirements in software development.

Characteristics of a good requirement

ISO/IEC/IEEE 29148 lists the qualities that each requirement should have. In plain terms, a good requirement is:

• Necessary: removing it would leave a real gap.
• Unambiguous: it has only one reasonable reading.
• Singular: it states one thing. As a result, you can test and trace it on its own.
• Feasible: the team can build it within the known constraints.
• Verifiable: someone can prove it passes or fails. Otherwise, QA has nothing to test against.
• Correct and consistent: it reflects the real need and does not contradict other requirements.

A quick test helps here. Read the requirement to a developer and a tester separately. If they describe different tests, rewrite it.

Software requirements specification in agile teams

Many agile teams assume that an SRS belongs to waterfall projects. That view misses the point. The Agile Manifesto values working software over comprehensive documentation, but it never says “no documentation”.

In practice, a lightweight software requirements specification works well alongside a backlog:

• Keep the stable parts in the SRS: scope, users, interfaces, constraints and non-functional requirements.
• Keep the changing detail in user stories and acceptance criteria.
• Link each story back to a requirement ID, so you can trace coverage.
• Review the SRS at each release, not only at the start.

This hybrid matters most when you work with an outside supplier or answer a tender. In that case, a clear SRS often forms the core of the request for proposal, and it gives every bidder the same baseline.

Common SRS mistakes

Most failed specifications fail in familiar ways. Watch for these:

• Writing solutions instead of needs. “Use a React dropdown” is a design choice. Instead, write “the user can pick one of five account types”.
• Vague words. Terms like “fast”, “user-friendly” and “secure” mean nothing until you attach a measure.
• Missing non-functional requirements. Teams skip them, then discover the security and performance gaps at launch.
• No priorities. When everything is a “must”, nothing is. Use MoSCoW or a similar scale.
• No owner or change log. Without version control, nobody knows which scope the estimate covered.
• Too much detail too early. A 90-page SRS for an unvalidated idea wastes money. Instead, specify what you know and mark open questions.

How Severus helps

We sit between founders and engineering teams. Through our SaaS product consulting work, we turn business goals into an SRS that developers can estimate and QA can test. Before a big build, our R&D validation service checks that the riskiest requirements are technically feasible. You can also see how this plays out for early-stage companies on our startups and SaaS page.

Severus is a business automation and operations consulting firm helping companies redesign workflows, integrate systems and implement automation and AI to reduce operating costs and manual work. In practice, we write requirements the way we run every project: process before automation, and the business problem before the tool.

Frequently Asked Questions

Strategy before code. Every time.

Need a software requirements specification your developers can actually build from? Book a discovery call with Severus