Software Requirements Specification Template (ISO/IEC/IEEE 29148)

Full SRS per ISO/IEC/IEEE 29148:2018 – interfaces, functions, quality attributes, verification matrix, traceability

Anforderungen & AnalyseVollständigISO/IEC/IEEE 29148:2018srs iso 29148 mathAktualisiert 20.10.2026

Anleitung: Contract, regulated or multi-team software. Write section 3 first, one testable statement per row with ID, priority, source and verification method; then fill section 4 so every requirement has an acceptance criterion. Delete non-applicable 1.3.x subsections but say why in 1.6.

Vorschau

Software Requirements Specification: [Product name]

Complete software requirements specification. The section structure follows the SRS information item of ISO/IEC/IEEE 29148:2018 (clause 9.6). Replace every [bracketed] value and every row marked Example, then delete the rows and sections that do not apply and say why in 1.6.

Document control

Field	Value
Document ID	[SRS-PRODUCT-001]
Product / system	[Product name] [release or increment]
Version	[0.1]
Status	[Draft / In review / Approved / Superseded]
Owner	[@requirements-owner]
Classification	[Internal / Confidential / Public]
Last updated	YYYY-MM-DD
Related documents	[StRS-xxx], [SyRS-xxx], [Architecture description], [Test plan]

Approvals

Role	Name	Decision	Date
Product owner	[@name]	[Approved / Rejected / Approved with comments]	YYYY-MM-DD
Engineering lead	[@name]	[Decision]	YYYY-MM-DD
Quality / test lead	[@name]	[Decision]	YYYY-MM-DD
Security reviewer	[@name]	[Decision]	YYYY-MM-DD

Revision history

Version	Date	Author	Change summary
0.1	YYYY-MM-DD	[@name]	Initial draft for review
0.2	YYYY-MM-DD	[@name]	Example: Incorporated review comments; added 3.4 performance targets
1.0	YYYY-MM-DD	[@name]	Example: Baseline approved by the change control board

Introduction
References
Specific requirements
Verification
Appendices

1. Introduction

1.1 Purpose

This specification defines the software requirements for [Product name] [release]. It is the agreed basis for design, implementation, verification and acceptance, and it is the reference for every change request raised after baseline.

Intended readers: product management, engineering, test, security, operations, documentation and [customer or regulator, if applicable].

1.2 Scope

Software item: [Product name], [version or increment].
Objective: [One sentence on the business outcome, for example "reduce order handling time for warehouse staff by 40%"].
In scope: [capability 1], [capability 2], [capability 3].
Out of scope: [capability explicitly excluded], [capability deferred to a later release], [capability owned by another system].
Benefits: [measurable benefit 1], [measurable benefit 2].

1.3 Product perspective

[Product name] is a [new / replacement / component] [web application / service / embedded software] that [one sentence on its role]. It replaces [legacy system, if any] and exchanges data with the systems in the context diagram.

1.3.1 System interfaces

Interface	Counterpart system	Purpose	Direction
Example: IF-SYS-01	ERP system	Read stock levels, create sales orders	Bidirectional
[IF-SYS-02]	[System]	[Purpose]	[In / Out / Bidirectional]

1.3.2 User interfaces

Describe the logical characteristics of each user interface: platforms, screen classes, accessibility level and localisation. Detailed layouts belong in design; requirements on them are stated in 3.1 and 3.3.

Supported clients: [desktop browsers, versions], [mobile, versions].
Accessibility target: [WCAG 2.2 level AA].
Languages: [en, vi, ...]; right-to-left support: [yes / no].

1.3.3 Hardware interfaces

[Devices the software controls or reads, for example barcode scanners, printers, sensors; protocols and supported models. Write "None" when the software runs only on general-purpose hosts.]

1.3.4 Software interfaces

Software	Version	Use	Interface
Example: PostgreSQL	16.x	Primary data store	SQL over TLS
[Library or service]	[Version]	[Use]	[API or protocol]

1.3.5 Communications interfaces

[Network protocols, message formats, encryption, ports, bandwidth or latency assumptions. Example: HTTPS (TLS 1.2+) for all client traffic; AMQP 0-9-1 for asynchronous events to the ERP.]

1.3.6 Memory constraints

[Limits on primary and secondary memory, for example "runs within 512 MiB RAM per instance" or "client bundle under 300 KB compressed". Write "No specific constraint" if none.]

1.3.7 Operations

[Normal and special operations: hours of service, unattended operation, batch windows, backup and recovery operations, data retention.]

1.3.8 Site adaptation requirements

[Configuration needed per installation site or tenant: locale, currency, time zone, feature flags, data migration steps.]

1.3.9 Interfaces with services

[External services the software depends on, such as payment, maps, identity, messaging; note the service level each one provides.]

1.4 Product functions

Function	Summary	Detailed in
Example: Order capture	Create, edit and submit customer orders	3.2.1
Example: Stock lookup	Show real-time availability per warehouse	3.2.2
[Function]	[Summary]	[3.2.x]

1.5 User characteristics

User class	Frequency	Domain expertise	Technical expertise	Privileges	Notes
Example: Warehouse clerk	Daily, all shift	High	Low	Create and edit orders	Uses handheld scanners, gloves
Example: Administrator	Weekly	Medium	High	Configuration, user management
[User class]	[Frequency]	[Level]	[Level]	[Privileges]	[Notes]

1.6 Limitations

[Regulatory policies, hardware limits, interfaces to other applications, parallel operation, audit functions, control functions, higher-order language requirements, signal handshake protocols, quality requirements such as reliability, criticality of the application, safety and security considerations, and physical or mental limitations of users that constrain the design options. List each with its source.]

1.7 Assumptions and dependencies

[Factors that, if they change, would change the requirements. Example: "The ERP exposes the stock API described in IF-SYS-01 by YYYY-MM-DD". The full register with owners and review dates is in 5.1.]

1.8 Apportioning of requirements

[Requirements allocated to later releases or to other system elements (hardware, people, other software). Reference the requirement IDs and the target release.]

Requirement	Allocated to	Reason
Example: SRS-FR-020	Release 2	Depends on ERP upgrade
[ID]	[Release or element]	[Reason]

2. References

ID	Title	Version / date	Source
REF-01	ISO/IEC/IEEE 29148:2018 Requirements engineering	2018	ISO / IEC / IEEE
REF-02	[Stakeholder requirements specification]	[x.y]	[Location]
REF-03	[Architecture description]	[x.y]	[Location]
REF-04	[Applicable regulation or contract]	[Date]	[Location]

3. Specific requirements

3.0 Requirement conventions

Identifiers. SRS-<type>-<nnn>, never reused. Types: IF external interface, FR function, US usability, PR performance, DB logical database, DC design constraint, SC standards compliance, RA reliability and availability, SE security, MA maintainability, PO portability.

Wording. "The system shall ..." for mandatory requirements, "should" for goals, "may" for options. One requirement per statement; no "and/or", "etc.", "user-friendly", "fast" or other unmeasurable words.

Attributes. Every requirement carries:

Attribute	Values
Priority	Must / Should / Could (MoSCoW)
Source	Stakeholder need ID, regulation, or decision record
Rationale	Why the requirement exists
Verification	Inspection (I), Analysis (A), Demonstration (D), Test (T)
Status	Proposed, Approved, Implemented, Verified, Deleted

Quality check. Before approval each requirement must be necessary, appropriate to this level, unambiguous, complete, singular, feasible, verifiable, correct and conforming to these conventions. The set as a whole must be complete, consistent, feasible and bounded.

3.1 External interfaces

ID	Requirement	Priority	Source	Verification
SRS-IF-001	Example: The system shall retrieve stock levels from the ERP stock API (IF-SYS-01) using the JSON schema in REF-03, appendix B.	Must	StRS-12	T
SRS-IF-002	Example: The system shall reject ERP responses that fail schema validation and record the rejection in the integration log within 1 s.	Must	Decision ADR-007	T
[SRS-IF-nnn]	[Statement]	[M/S/C]	[Source]	[I/A/D/T]

3.2 Functions

3.2.1 [Function name, for example Order capture]

Description: [What the function achieves for which user class.]

ID	Requirement	Priority	Source	Rationale	Verification
SRS-FR-001	Example: The system shall let a warehouse clerk create an order with one or more order lines.	Must	StRS-03	Core business process	T
SRS-FR-002	Example: The system shall reject an order line whose quantity is not a positive integer and show the reason next to the field.	Must	StRS-03	Prevents invalid stock moves	T
SRS-FR-003	Example: The system shall save an unsubmitted order as a draft automatically at least every 30 s.	Should	Usability study U-4	Avoids lost work on handheld devices	T

Abnormal situations: [behaviour on network loss, timeout, duplicate submission, concurrent edit].

3.2.2 [Function name, for example Stock lookup]

Description: [What the function achieves.]

ID	Requirement	Priority	Source	Rationale	Verification
SRS-FR-010	Example: The system shall display available quantity per warehouse for a searched product.	Must	StRS-05	Clerks choose the source warehouse	T
SRS-FR-011	Example: The system shall mark stock data older than 5 minutes as stale.	Should	StRS-05	Prevents overselling	D

3.3 Usability requirements

ID	Requirement	Priority	Verification
SRS-US-001	Example: 90% of first-time warehouse clerks shall complete "create an order with three lines" in under 2 minutes without assistance.	Must	T (usability test)
SRS-US-002	Example: All user interface screens shall conform to WCAG 2.2 level AA.	Must	I + T
[SRS-US-nnn]	[Statement]	[M/S/C]	[Method]

3.4 Performance requirements

Response times are measured server-side as the $p$ -th percentile over a rolling 5-minute window:

t_{p95} = \min\{\, t : P(T \le t) \ge 0.95 \,\}

ID	Requirement	Load condition	Priority	Verification
SRS-PR-001	Example: The system shall support 500 concurrent signed-in users.	Peak shift	Must	T (load test)
SRS-PR-002	Example: Order submission shall complete with $t_{p95} \le 800$ ms.	50 orders/s	Must	T
SRS-PR-003	Example: Stock lookup shall complete with $t_{p95} \le 300$ ms.	200 queries/s	Should	T
[SRS-PR-nnn]	[Statement]	[Condition]	[M/S/C]	[Method]

3.5 Logical database requirements

ID	Requirement	Priority	Verification
SRS-DB-001	Example: The system shall retain submitted orders for 7 years and then delete them.	Must	I + T
SRS-DB-002	Example: Every order line shall reference exactly one product and one order.	Must	A
[SRS-DB-nnn]	[Statement]	[M/S/C]	[Method]

3.6 Design constraints

ID	Constraint	Source	Verification
SRS-DC-001	Example: The server components shall run on the company's managed Kubernetes platform.	IT policy P-14	I
SRS-DC-002	Example: The system shall store personal data only in EU data centres.	GDPR, contract C-22	I
[SRS-DC-nnn]	[Constraint]	[Source]	[Method]

3.7 Standards compliance

ID	Requirement	Standard or regulation	Verification
SRS-SC-001	Example: The system shall record who created, changed or deleted an order and when, and keep the record for 7 years.	[Internal audit policy], [regulation]	I + T
[SRS-SC-nnn]	[Statement]	[Standard]	[Method]

3.8 Software system attributes

3.8.1 Reliability

ID	Requirement	Verification
SRS-RA-001	Example: The system shall lose no submitted order in the event of a single node failure.	T (fault injection)
SRS-RA-002	Example: Mean time between failures shall be at least 720 hours in production operation.	A (operational data)

3.8.2 Availability

Availability is measured monthly over the service hours in 1.3.7:

A = \frac{\text{service time} - \text{unplanned downtime}}{\text{service time}} \times 100\%

ID	Requirement	Verification
SRS-RA-010	Example: Availability shall be at least 99.9% per calendar month.	A (monitoring)
SRS-RA-011	Example: After a full region outage the service shall be restored within 4 hours (RTO) with at most 15 minutes of data loss (RPO).	D (recovery drill)

3.8.3 Security

ID	Requirement	Verification
SRS-SE-001	Example: The system shall authenticate users through the corporate identity provider using OpenID Connect.	T
SRS-SE-002	Example: The system shall enforce role-based access so that clerks cannot change configuration.	T
SRS-SE-003	Example: All data in transit shall use TLS 1.2 or later; all personal data at rest shall be encrypted.	I + T
SRS-SE-004	Example: Security-relevant events (sign-in, permission change, export) shall be logged and retained for 1 year.	I

3.8.4 Maintainability

ID	Requirement	Verification
SRS-MA-001	Example: Automated tests shall cover at least 80% of lines in the business logic modules.	A (coverage report)
SRS-MA-002	Example: Configuration changes listed in 1.3.8 shall not require a code change or redeployment.	D

3.8.5 Portability

ID	Requirement	Verification
SRS-PO-001	Example: The client shall run on the two latest major versions of Chrome, Edge, Firefox and Safari.	T
SRS-PO-002	Example: The server shall run on any Linux host that provides a container runtime compatible with the OCI image specification.	D

3.9 Supporting information

[Sample input and output formats, cost analysis studies, results of user surveys, background on the problem, and packaging instructions for code and media. Reference them as annexes when they are long.]

4. Verification

Requirement	Method	Acceptance criterion	Test or evidence ID	Result
SRS-IF-001	T	Stock values match ERP for 100 sampled products	TC-INT-001	[Pass / Fail / Not run]
SRS-FR-002	T	Invalid quantities rejected with field message	TC-ORD-004	[Result]
SRS-US-001	T	90% of 10 first-time users finish under 2 min	UT-2026-01	[Result]
SRS-PR-002	T	p95 at or below 800 ms at 50 orders/s for 30 min	PERF-003	[Result]
SRS-RA-010	A	Monthly availability report at or above 99.9%	OPS-REPORT-MM	[Result]
SRS-SE-002	T	Clerk role receives 403 on configuration endpoints	SEC-TC-011	[Result]
[ID]	[I/A/D/T]	[Criterion]	[Evidence]	[Result]

Verification status summary:

Category	Total	Verified	Failed	Not yet verified
Functions (FR)	[n]	[n]	[n]	[n]
Performance (PR)	[n]	[n]	[n]	[n]
Security (SE)	[n]	[n]	[n]	[n]
All requirements	[n]	[n]	[n]	[n]

5. Appendices

5.1 Assumptions and dependencies register

ID	Assumption or dependency	Impact if false	Owner	Review date	Status
AD-01	Example: ERP stock API is available in production by YYYY-MM-DD	Stock lookup (3.2.2) cannot ship	[@name]	YYYY-MM-DD	Open
AD-02	[Assumption]	[Impact]	[@name]	YYYY-MM-DD	[Open / Confirmed / Invalid]

5.2 Acronyms, abbreviations and definitions

Term	Definition
ERP	Enterprise resource planning system
RTO	Recovery time objective: maximum acceptable time to restore service
RPO	Recovery point objective: maximum acceptable data loss measured in time
p95	95th percentile of a measured distribution
[Term]	[Definition used in this document]

5.3 Traceability matrix

Source	SRS requirement	Design element	Verification
StRS-03	SRS-FR-001, SRS-FR-002	Order service	TC-ORD-001, TC-ORD-004
StRS-05	SRS-FR-010, SRS-FR-011	Stock adapter	TC-INT-001
[Source ID]	[SRS IDs]	[Component]	[Test IDs]

5.4 Open issues

ID	Issue	Raised by	Owner	Due	Resolution
OI-01	Example: Confirm whether drafts expire after 30 days	[@name]	[@name]	YYYY-MM-DD	[Open]
[OI-nn]	[Issue]	[@name]	[@name]	YYYY-MM-DD	[Resolution]

Standard and licence note

Structure aligned with ISO/IEC/IEEE 29148:2018, Systems and software engineering: Life cycle processes, Requirements engineering, software requirements specification information item. This template is original text written for this collection and reproduces no text from the standard; obtain the standard from ISO, IEC or IEEE for its normative requirements. Template licence: MIT.