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.
Document control
| 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
| 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
1. Introduction
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
- 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.
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
| 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
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
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
| 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
| 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
The system moves between the following modes.
| 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
| 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
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
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
| 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.