# 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.

<!--
Guidance: How to use this template
- Hidden notes like this one explain each section. They do not appear in
  the preview or in exported files, so you can leave them while drafting.
- Write requirements, not design. A requirement states WHAT the software
  must do or how well; the design document states HOW.
- Every requirement gets an ID, a priority, a source, a rationale and a
  verification method (see 3.0). Section 4 proves each one is testable.
- Keep the numbering. Reviewers and auditors navigate by section number.
-->

## Document control

<!-- Guidance: Identify the document so that every copy can be traced to one version. Status moves Draft -> In review -> Approved -> Superseded. -->

| 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

<!-- Guidance: One row per published version. Describe what changed in requirements terms ("added SRS-FR-014, relaxed SRS-PR-003"), not editorial noise. -->

| 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 |

## Contents

<!-- Guidance: Keep this list in sync with the headings. The editor's Outline panel also navigates by heading. -->

1. [Introduction](#1-introduction)
2. [References](#2-references)
3. [Specific requirements](#3-specific-requirements)
4. [Verification](#4-verification)
5. [Appendices](#5-appendices)

## 1. Introduction

<!-- Guidance: Section 1 gives a reader enough context to understand section 3 without having seen the project before. It describes the product, not the requirements themselves. -->

### 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

<!-- Guidance: Name the software, state what it will and will not do, and tie it to the business objective. Scope disputes are cheaper here than in acceptance testing. -->

- **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

<!-- Guidance: Place the product in its environment: is it new, a replacement, or a component of a larger system? The diagram below is a context view; keep it to the software and the actors and systems it exchanges data with. -->

[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.

```mermaid
flowchart LR
  user([End user]) -->|uses| sys[[Product name]]
  admin([Administrator]) -->|configures| sys
  sys -->|orders, stock queries| erp[(ERP system)]
  sys -->|sends notifications| mail[Email service]
  idp[Identity provider] -->|authenticates| sys
```

#### 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

<!-- Guidance: Summarise the major functions so a reader sees the whole product at a glance. The detailed, testable statements go in 3.2; keep this list short and use the same names. -->

| 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

<!-- Guidance: Describe each user class by what affects the requirements: frequency of use, expertise, privileges, accessibility needs. Personas from research help, but keep this factual. -->

| 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

<!-- Guidance: List every document the SRS cites, with version and date, so a requirement such as "complies with the brand guide" points at one exact edition. -->

| 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

<!-- Guidance: This is the core of the SRS. Each requirement is one testable statement with its attributes. Group by the sub-sections below; inside 3.2 group by feature or by user class, whichever reviewers find easier. -->

### 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

<!-- Guidance: Detail every input and output across the interfaces named in 1.3: data items, ranges, units, timing, formats, error handling. -->

| 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

<!-- Guidance: Describe the fundamental actions on inputs to produce outputs: validity checks, sequence of operations, responses to abnormal situations, parameters, and the relationship of outputs to inputs. Add a sub-section per function from 1.4. -->

#### 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

<!-- Guidance: State measurable effectiveness, efficiency and satisfaction criteria for named user classes and tasks, not adjectives. -->

| 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

<!-- Guidance: Give static numbers (users, sessions, data volume) and dynamic numbers (throughput, response time) with the load condition under which they apply. Percentiles beat averages. -->

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

<!-- Guidance: Describe the information the software must store: entities, relationships, integrity constraints, retention and access frequency. This is the logical view; physical schema belongs in the database design document. -->

```mermaid
erDiagram
  CUSTOMER ||--o{ ORDER : places
  ORDER ||--|{ ORDER_LINE : contains
  PRODUCT ||--o{ ORDER_LINE : "is ordered in"
  WAREHOUSE ||--o{ STOCK : holds
  PRODUCT ||--o{ STOCK : "is stocked as"
```

| 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

<!-- Guidance: Constraints imposed by other standards, regulations, hardware or company policy that limit the designers' choices. State the source of each. -->

| 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

<!-- Guidance: Requirements derived from existing standards or regulations: report formats, data naming, accounting procedures, audit tracing. -->

| 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

<!-- Guidance: Quality requirements that apply to the whole software item. Each must be measurable; if you cannot name the measurement, rewrite it. -->

#### 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

<!-- Guidance: Mirror section 3. For each requirement record how it will be verified, where the evidence will live, and the result. Inspection = review of documents or code; Analysis = calculation or modelling; Demonstration = observed operation without measurement; Test = measured execution against acceptance criteria. -->

| 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

<!-- Guidance: Keep material here that supports the requirements but would interrupt reading section 3. -->

### 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

<!-- Guidance: Every SRS requirement traces back to a source (stakeholder need, regulation, decision) and forward to design and verification. Orphans in either direction are review findings. -->

| 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.