Software Requirements Specification (SRS) Template: Structure and Examples

A software requirements specification (SRS) describes what a system must do and under which constraints — not how it will be built. Whether you write one for a customer or for a university course, the hardest part is usually the empty page.

The outline below follows the structure that ISO/IEC/IEEE 29148 (the current standard) inherited from the older IEEE 830. You do not need to follow it slavishly, but readers and graders expect to find information in these places.

1. Introduction#

Purpose: who the document is for and what it decides. Scope: the system’s name, what it will and will not do, and the benefit it brings. Definitions: every abbreviation and domain term a reader might not know. References: standards, contracts and other documents this SRS depends on. Overview: how the rest of the document is organised.

2. Overall description#

• Product perspective — is this a new system, a replacement, or part of a larger one? A simple context diagram helps.
• Product functions — a short summary of the main capabilities (details come in section 3).
• Users and their characteristics — who uses the system, how often, and with what experience.
• Constraints — regulations, hardware, mandated technologies, deadlines.
• Assumptions and dependencies — things you rely on that could change, such as an external service being available.

3. Specific requirements#

This is the core of the SRS and usually most of its pages. Each requirement gets a unique ID and is written as one verifiable statement.

• External interfaces — user interfaces, hardware, software and communication interfaces. Example: "IF-03: The system shall export reports as PDF."
• Functional requirements — what the system does, grouped by feature or user task. Example: "REQ-012: The system shall let a member renew a loan up to two times."
• Performance requirements — measurable response times, capacity, throughput. Example: "PERF-02: Catalogue search shall return results within 2 seconds for 95% of queries."
• Quality attributes — availability, security, usability, maintainability, each with a number or a test. Example: "SEC-04: Passwords shall be stored only as salted hashes."
• Design constraints — standards or technologies the solution must use.

4. Verification and appendices#

Many teams add a verification section that says how each requirement will be checked (test, inspection, analysis or demonstration), or a traceability table from requirements to tests. Appendices hold data models, diagrams and anything too detailed for the main text.

The mistakes reviewers see most#

• Describing the solution instead of the need ("use a MySQL database" where "store 10 years of loan history" was meant).
• Vague words without numbers: fast, easy, flexible, user-friendly.
• Two requirements in one sentence joined by "and", so neither can be tested alone.
• No IDs, so nobody can refer to a requirement in a test, a ticket or a review comment.
• Missing scope: readers cannot tell what the system will not do.
• No version history, so it is unclear which version was approved.

Starting from a template#

Copy the headings above into your document and fill them in from the top: scope first, then users, then requirements. Write the introduction last if you like — it is easier once you know what the document contains.

In Requify you can start a software (SRS) or hardware (HRS) specification from this structure, write requirements with IDs inside it, and export the result to PDF or Word for submission or review.