# System Requirements Specification: [System name]

> Complete system requirements specification (SyRS). The section structure
> follows the system requirements information item of ISO/IEC/IEEE
> 29148:2018 (clause 9.5). It turns agreed stakeholder requirements into
> technical, verifiable requirements on the whole system: hardware,
> software, people, facilities and data together. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- A system requirement describes the system as a black box: what it must
  do and how well, at its boundary. Allocation to hardware, software or
  people happens in architecture and the element specifications (SRS).
- Each requirement traces back to a stakeholder requirement (STK-UR-nnn) or
  a constraint, and forward to a verification activity in section 4.
- Section 4 runs parallel to section 3: same numbering, one verification
  entry per requirement. Gaps there are review findings.
- Delete sub-sections that genuinely do not apply, but leave the heading
  with "Not applicable because [reason]" so reviewers see it was considered.
-->

## Document control

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

| Field | Value |
|---|---|
| Document ID | [SYRS-SYSTEM-001] |
| System | [System name] [configuration or increment] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@systems-engineer] |
| Classification | [Internal / Confidential / Public] |
| Last updated | YYYY-MM-DD |
| Related documents | [StRS-xxx], [ConOps-xxx], [Architecture description], [SRS-xxx], [System test plan] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Chief systems engineer | [@name] | [Approved / Rejected / Approved with comments] | YYYY-MM-DD |
| Product or programme owner | [@name] | [Decision] | YYYY-MM-DD |
| Verification and test lead | [@name] | [Decision] | YYYY-MM-DD |
| Safety and security reviewer | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: One row per published version. Name requirements added, changed or deleted. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial draft derived from StRS 1.0 |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added environmental conditions 3.8 after site survey; tightened SYS-PR-002 |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Baseline approved at system requirements review |

## Contents

<!-- Guidance: Keep this list in sync with the headings. -->

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

## 1. Introduction

<!-- Guidance: Give enough context that section 3 can be read without the rest of the project file. -->

### 1.1 System purpose

[Why the system exists and which stakeholder needs it satisfies. One
paragraph, linked to the StRS objectives.]

*Example:* The Field Work Management System (FWMS) enables a water utility
to receive fault reports, dispatch qualified crews and record repairs, so
that mean fault-to-repair time falls below 12 hours (StRS BO-01).

### 1.2 System scope

<!-- Guidance: Name the system, its elements, what it does and does not do. List the elements that make up the system of interest so allocation is clear later. -->

- **System of interest**: [System name], [identifier and version].
- **Elements**: [software applications], [hardware such as rugged
  tablets or sensors], [operator roles], [facilities such as control
  room], [data sets].
- **In scope**: [capability 1], [capability 2], [capability 3].
- **Out of scope**: [capability], [system owned by another programme].
- **Enabling systems** (needed but not delivered): [build pipeline,
  training system, spares depot].

### 1.3 System overview

#### 1.3.1 System context

The context diagram shows the system boundary and every external entity
that exchanges data, energy or material with the system.

```mermaid
flowchart LR
  callc([Contact centre agents]) -->|fault reports| fwms[[FWMS]]
  tech([Field technicians]) <-->|jobs, status| fwms
  fwms <-->|work orders, assets| erp[(ERP)]
  fwms -->|customer messages| sms[SMS gateway]
  gis[(GIS)] -->|network maps| fwms
  fwms -->|interruption reports| reg[Regulator portal]
```

#### 1.3.2 System functions

| Function | Summary | Requirements |
|---|---|---|
| *Example:* Fault intake | Capture and prioritise fault reports | 3.1.1 |
| *Example:* Dispatch | Match jobs to qualified, available crews | 3.1.2 |
| *Example:* Mobile job execution | Deliver jobs to devices and capture outcomes, online or offline | 3.1.3 |
| [Function] | [Summary] | [3.1.x] |

#### 1.3.3 User characteristics

| User class | Number | Location | Expertise | Training available | Special needs |
|---|---|---|---|---|---|
| *Example:* Dispatcher | 24 | Control room | High domain, medium IT | 1 day classroom | 12-hour shifts, multi-monitor |
| *Example:* Field technician | 310 | Outdoors, vehicles | High domain, low IT | 2 hours on device | Gloves, sunlight, rain |
| [User class] | [n] | [Location] | [Level] | [Training] | [Needs] |

### 1.4 Definitions

[Terms with a specific meaning in this document. Full list in 5.2.]

## 2. References

<!-- Guidance: Every cited document with version and date. -->

| 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 | [Concept of operations] | [x.y] | [Location] |
| REF-04 | [Interface specifications of external systems] | [x.y] | [Location] |
| REF-05 | [Applicable regulation or industry standard] | [Date] | [Location] |

## 3. System requirements

<!-- Guidance: One verifiable statement per row. Use "shall" for mandatory, "should" for goals. Each row carries a source (STK-UR or constraint), priority and verification method. -->

**Conventions.** IDs follow `SYS-<type>-<nnn>`: `FR` functional, `US`
usability, `PR` performance, `IF` interface, `OP` operations, `MS` modes
and states, `PH` physical, `EN` environmental, `SE` security, `IM`
information management, `PL` policy and regulation, `LS` life cycle
sustainment, `PK` packaging and transport. Verification methods:
Inspection (I), Analysis (A), Demonstration (D), Test (T).

### 3.1 Functional requirements

<!-- Guidance: What the system must do at its boundary, per function from 1.3.2. Include behaviour under abnormal inputs. -->

#### 3.1.1 [Function, for example Fault intake]

| ID | Requirement | Source | Priority | Verification |
|---|---|---|---|---|
| SYS-FR-001 | *Example:* The system shall record a fault report with location, reporter contact, fault type and time received. | STK-UR-020 | Must | T |
| SYS-FR-002 | *Example:* The system shall assign a priority from 1 to 4 to each fault using the rules in POL-01 within 10 s of recording. | POL-01 | Must | T |

#### 3.1.2 [Function, for example Dispatch]

| ID | Requirement | Source | Priority | Verification |
|---|---|---|---|---|
| SYS-FR-010 | *Example:* The system shall propose the three nearest available crews holding every skill the job requires. | STK-UR-002 | Must | T |
| SYS-FR-011 | *Example:* The system shall prevent assignment of a confined-space job to a crew of fewer than two people. | POL-02 | Must | T |

#### 3.1.3 [Function, for example Mobile job execution]

| ID | Requirement | Source | Priority | Verification |
|---|---|---|---|---|
| SYS-FR-020 | *Example:* The system shall let a technician view and update assigned jobs without network connectivity for at least 12 hours. | STK-UR-010 | Must | T |
| SYS-FR-021 | *Example:* The system shall synchronise offline updates within 60 s of connectivity returning, without data loss. | STK-UR-010 | Must | T |

### 3.2 Usability requirements

| ID | Requirement | Source | Priority | Verification |
|---|---|---|---|---|
| SYS-US-001 | *Example:* 90% of technicians shall close a job in under 60 s after 2 hours of training. | STK-UR-011 | Should | T (usability test) |
| SYS-US-002 | *Example:* Mobile screens shall remain readable at 100,000 lux ambient light. | Site survey | Must | T |

### 3.3 Performance requirements

<!-- Guidance: State numbers with the load or condition under which they apply. Percentiles beat averages. -->

| ID | Requirement | Condition | Priority | Verification |
|---|---|---|---|---|
| SYS-PR-001 | *Example:* The system shall handle 1,500 fault reports per hour. | Storm peak | Must | T (load) |
| SYS-PR-002 | *Example:* Crew proposals shall be returned within 3 s at the 95th percentile. | 40 concurrent dispatchers | Must | T |
| SYS-PR-003 | [Requirement] | [Condition] | [M/S/C] | [Method] |

### 3.4 System interfaces

<!-- Guidance: Every external interface from the context diagram. Reference the interface control document for message detail. -->

| ID | Interface | Counterpart | Requirement | Verification |
|---|---|---|---|---|
| SYS-IF-001 | *Example:* IF-ERP-01 | ERP | The system shall create a work order in the ERP for every job closed, within 5 minutes. | T |
| SYS-IF-002 | *Example:* IF-SMS-01 | SMS gateway | The system shall send customer status messages through the gateway API and retry failed sends 3 times. | T |
| SYS-IF-003 | [Interface] | [System] | [Requirement] | [Method] |

### 3.5 System operations

[Requirements on how the system is operated: hours of service, staffing,
monitoring, backup and restore, unattended operation, administrator
tasks.]

| ID | Requirement | Source | Verification |
|---|---|---|---|
| SYS-OP-001 | *Example:* The system shall operate 24 hours a day, 7 days a week, with planned maintenance only between 02:00 and 04:00 local time. | STK-UR-001 | D |
| SYS-OP-002 | *Example:* An operator shall be able to restore the system from the latest backup within 2 hours. | Continuity plan | D |

### 3.6 System modes and states

<!-- Guidance: Name each mode, the transitions between them, and which requirements apply in each. A state diagram shows the transitions compactly. -->

The system moves between the following modes.

```mermaid
stateDiagram-v2
  [*] --> Normal
  Normal --> MajorIncident: open P1 jobs > 50
  MajorIncident --> Normal: open P1 jobs < 20 for 2 h
  Normal --> Degraded: ERP or GIS unavailable
  Degraded --> Normal: dependency restored
  Normal --> Maintenance: planned window
  Maintenance --> Normal: checks passed
```

| ID | Requirement | Verification |
|---|---|---|
| SYS-MS-001 | *Example:* In Degraded mode the system shall continue fault intake and dispatch and queue ERP updates for later delivery. | T |
| SYS-MS-002 | *Example:* In Major incident mode the system shall show a region-wide dispatch board to all dispatchers. | D |

### 3.7 Physical characteristics

[Size, weight, shape, colour, mounting, ruggedness and labelling of
physical elements.]

| ID | Requirement | Verification |
|---|---|---|
| SYS-PH-001 | *Example:* Field devices shall weigh no more than 900 g including the protective case. | I |
| SYS-PH-002 | *Example:* Field devices shall withstand a 1.2 m drop onto concrete on all faces. | T |

### 3.8 Environmental conditions

[Conditions the system must operate in or survive: temperature, humidity,
dust and water ingress, vibration, electromagnetic compatibility.]

| ID | Requirement | Verification |
|---|---|---|
| SYS-EN-001 | *Example:* Field devices shall operate between -20 °C and +50 °C. | T |
| SYS-EN-002 | *Example:* Field devices shall be rated at least IP65 for dust and water ingress. | I (certificate) |

### 3.9 System security

<!-- Guidance: Confidentiality, integrity, availability, authentication, authorisation, audit and physical protection. Link to the threat model. -->

| ID | Requirement | Source | Verification |
|---|---|---|---|
| SYS-SE-001 | *Example:* The system shall authenticate every user through the corporate identity provider with multi-factor authentication. | Security policy | T |
| SYS-SE-002 | *Example:* A lost field device shall be remotely wiped within 15 minutes of being reported. | Threat model T-04 | D |
| SYS-SE-003 | *Example:* The system shall log every change to job priority with user, time and old and new values. | POL-01 | I + T |

### 3.10 Information management

[Information the system creates, stores and exchanges: retention,
archival, data ownership, integrity, data quality and disposal.]

| ID | Requirement | Verification |
|---|---|---|
| SYS-IM-001 | *Example:* The system shall retain closed job records for 7 years and then delete them. | I + T |
| SYS-IM-002 | *Example:* The system shall treat the ERP as the master source for asset data and never edit asset attributes locally. | I |

### 3.11 Policies and regulations

| ID | Requirement | Policy or regulation | Verification |
|---|---|---|---|
| SYS-PL-001 | *Example:* The system shall produce the monthly interruption report in the regulator's prescribed format. | [Licence condition] | I |
| SYS-PL-002 | *Example:* The system shall process personal data only for the purposes listed in the privacy notice. | [Data protection law] | I |

### 3.12 System life cycle sustainment

[Requirements that keep the system supportable over its life:
maintenance, spares, technology refresh, supportability, training,
documentation and disposal.]

| ID | Requirement | Verification |
|---|---|---|
| SYS-LS-001 | *Example:* Spare field devices equal to 5% of the fleet shall be held in stock throughout the service life. | I |
| SYS-LS-002 | *Example:* Software updates to field devices shall be deployable remotely without user action. | D |

### 3.13 Packaging, handling, shipping and transportation

| ID | Requirement | Verification |
|---|---|---|
| SYS-PK-001 | *Example:* Field devices shall be shipped in packaging that passes a standard parcel drop test and is fully recyclable. | I |
| SYS-PK-002 | [Requirement on storage, handling or transport] | [Method] |

## 4. Verification

<!-- Guidance: Parallel to section 3. Each requirement has a verification entry with method, criterion, level (element, integration, system, acceptance) and evidence. -->

### 4.1 Verification approach

[Describe the verification levels, environments and responsibilities.
Example: element tests by suppliers, integration tests in the staging
environment, system tests in a field pilot, acceptance by the operations
director.]

### 4.2 Verification matrix

| Section | Requirement | Method | Level | Acceptance criterion | Evidence | Result |
|---|---|---|---|---|---|---|
| 3.1 | SYS-FR-002 | T | System | 200 sample faults prioritised correctly within 10 s | ST-FR-002 | [Pass / Fail / Not run] |
| 3.1 | SYS-FR-020 | T | System | 12 h offline, 50 updates, all synchronised | ST-FR-020 | [Result] |
| 3.3 | SYS-PR-002 | T | System | p95 at or below 3 s for 1 h at 40 users | PERF-02 | [Result] |
| 3.4 | SYS-IF-001 | T | Integration | ERP order created for 100% of 500 closed jobs | IT-ERP-01 | [Result] |
| 3.8 | SYS-EN-002 | I | Element | Supplier IP65 certificate on file | CERT-07 | [Result] |
| 3.9 | SYS-SE-002 | D | Acceptance | Device wiped within 15 min in observed drill | ACC-SE-02 | [Result] |
| [3.x] | [ID] | [I/A/D/T] | [Level] | [Criterion] | [Evidence] | [Result] |

### 4.3 Verification status summary

Report this table at each milestone review. A requirement counts as
verified only when its evidence has been reviewed and filed, not when the
test has merely been run.

| Section | Total | Verified | Failed | Waived (with approval) | Not yet verified |
|---|---|---|---|---|---|
| 3.1 Functional | [n] | [n] | [n] | [n] | [n] |
| 3.3 Performance | [n] | [n] | [n] | [n] | [n] |
| 3.9 Security | [n] | [n] | [n] | [n] | [n] |
| All sections | [n] | [n] | [n] | [n] | [n] |

Failed or waived requirements are listed with their deviation or waiver
reference, the risk accepted and the person who accepted it.

## 5. Appendices

<!-- Guidance: Supporting material: assumptions, glossary, traceability. -->

### 5.1 Assumptions and dependencies

| ID | Assumption or dependency | Impact if false | Owner | Review date |
|---|---|---|---|---|
| AD-01 | *Example:* ERP work-order API v2 is live before system test | SYS-IF-001 cannot be verified | [@name] | YYYY-MM-DD |
| AD-02 | [Assumption] | [Impact] | [@name] | YYYY-MM-DD |

### 5.2 Acronyms and abbreviations

| Term | Definition |
|---|---|
| SyRS | System requirements specification |
| StRS | Stakeholder requirements specification |
| IP65 | Ingress protection rating: dust-tight and protected against water jets |
| p95 | 95th percentile of a measured distribution |
| [Term] | [Definition] |

### 5.3 Traceability

<!-- Guidance: Backward to stakeholder needs, forward to architecture elements and verification. -->

| Stakeholder requirement | System requirement | Allocated to element | Verification |
|---|---|---|---|
| STK-UR-002 | SYS-FR-010 | Dispatch service | ST-FR-010 |
| STK-UR-010 | SYS-FR-020, SYS-FR-021 | Mobile app, sync service | ST-FR-020 |
| POL-02 | SYS-FR-011 | Dispatch service | ST-FR-011 |
| [STK-ID] | [SYS IDs] | [Element] | [Test IDs] |

## Standard and licence note

Structure aligned with ISO/IEC/IEEE 29148:2018, *Systems and software
engineering: Life cycle processes, Requirements engineering*, system
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.