# Stakeholder Requirements Specification: [System name]

> Complete stakeholder requirements specification (StRS). The section
> structure follows the stakeholder requirements information item of
> ISO/IEC/IEEE 29148:2018 (clause 9.4). It records what each stakeholder
> group needs from the system, in their terms, before any system or
> software requirement is written. Replace every `[bracketed]` value and
> every row marked *Example*, then remove what does not apply and say why.

<!--
Guidance: How to use this template
- Write from the stakeholders' point of view. "The dispatcher needs to see
  every open job on one screen" is a stakeholder requirement; "the UI shall
  use a Kanban board" is design and does not belong here.
- Fill sections 1 and 3 first: if you cannot name the business purpose and
  the stakeholders, the user requirements in section 5 will drift.
- Every user requirement gets an ID, a stakeholder source, a priority and a
  validation method. Section 9 traces each one back to a business need.
- Keep the numbering. The system requirements specification (SyRS) and the
  traceability matrix refer to these section numbers and IDs.
-->

## 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 | [STRS-SYSTEM-001] |
| System | [System name] [release or increment] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@business-analyst] |
| Sponsor | [@sponsor] |
| Classification | [Internal / Confidential / Public] |
| Last updated | YYYY-MM-DD |
| Related documents | [BRS-xxx], [ConOps-xxx], [SyRS-xxx], [Project charter] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Business sponsor | [@name] | [Approved / Rejected / Approved with comments] | YYYY-MM-DD |
| Representative of each key stakeholder group | [@name] | [Decision] | YYYY-MM-DD |
| Product owner | [@name] | [Decision] | YYYY-MM-DD |
| Systems engineering lead | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: One row per published version. Describe changes in requirement terms ("added STK-UR-021 from the field technician workshop"), not editorial fixes. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial draft from elicitation interviews |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added operational modes after control-room observation; merged duplicate needs |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Baseline approved by sponsor and stakeholder representatives |

## Contents

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

1. [Introduction](#1-introduction)
2. [References](#2-references)
3. [Business management requirements](#3-business-management-requirements)
4. [Business operational requirements](#4-business-operational-requirements)
5. [User requirements](#5-user-requirements)
6. [Concept of the proposed system](#6-concept-of-the-proposed-system)
7. [Project constraints](#7-project-constraints)
8. [Verification and validation](#8-verification-and-validation)
9. [Traceability to business needs](#9-traceability-to-business-needs)
10. [Appendices](#10-appendices)

## 1. Introduction

<!-- Guidance: Give a reader with no project history enough context to understand why the system is wanted and who wants it. -->

### 1.1 Business purpose

<!-- Guidance: Why does the organisation want this system? Name the problem or opportunity and the outcome it expects. Avoid describing features. -->

[Organisation name] needs [System name] in order to [business outcome].
Today [describe the problem or opportunity in one or two sentences, with a
number where possible]. Success means [measurable outcome].

*Example:* The regional water utility needs a field work management system
to cut the average time from fault report to repair from 26 hours to under
12 hours and to give customers a reliable repair estimate.

### 1.2 Business scope

<!-- Guidance: Name the business area the system supports and draw the boundary. Scope disputes are cheaper now than in acceptance. -->

- **Business area**: [department, process or value stream supported].
- **Organisational units involved**: [units, regions, partners].
- **In scope**: [activity 1], [activity 2], [activity 3].
- **Out of scope**: [activity excluded], [activity owned by another system],
  [activity deferred to a later phase].
- **Expected benefits**: [benefit with measure], [benefit with measure].

### 1.3 Business overview

<!-- Guidance: Describe the organisation and how the system fits it. A context diagram of stakeholders and neighbouring systems helps reviewers spot who is missing. -->

[Two or three paragraphs on the organisation, its main activities, the
part of the business that will change, and the major internal and external
parties involved.]

The diagram shows the stakeholder groups and the neighbouring systems that
interact with the proposed system.

```mermaid
flowchart LR
  cust([Customers]) -->|report faults| sys[[Proposed system]]
  disp([Dispatchers]) -->|assign jobs| sys
  tech([Field technicians]) -->|update job status| sys
  sys -->|work orders| erp[(ERP / asset register)]
  sys -->|status messages| sms[SMS gateway]
  reg([Regulator]) -.->|receives reports| sys
```

### 1.4 Definitions

[Terms used with a specific meaning in this document. The full glossary is
in 10.1. Define each business term once and use it consistently.]

### 1.5 Stakeholders

<!-- Guidance: List every group that affects or is affected by the system, including people who never touch it (regulators, finance, unions). Record their interest and influence so conflicts can be resolved by the right person. -->

| ID | Stakeholder group | Representative | Interest in the system | Influence | Involvement |
|---|---|---|---|---|---|
| STK-01 | *Example:* Dispatchers | [@name] | Assign the right technician quickly | High | Workshops, acceptance |
| STK-02 | *Example:* Field technicians | [@name] | Clear job details, offline access | Medium | Field trials |
| STK-03 | *Example:* Customers | Customer panel | Reliable repair estimates | Medium | Surveys |
| STK-04 | *Example:* Regulator | [Agency] | Timely incident reporting | High | Review of reports |
| STK-05 | [Group] | [@name] | [Interest] | [High / Medium / Low] | [How involved] |

## 2. References

<!-- Guidance: List every document cited, with version and date, so a requirement that refers to "the service charter" 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 | [Business case or BRS] | [x.y] | [Location] |
| REF-03 | [Elicitation records: interview notes, workshop outputs] | YYYY-MM-DD | [Location] |
| REF-04 | [Applicable regulation, licence or contract] | [Date] | [Location] |

## 3. Business management requirements

<!-- Guidance: Describe the business context that shapes all stakeholder needs: environment, goals, business model and information. These are inputs, not requirements on the system. -->

### 3.1 Business environment

[External factors that affect the business: market, competitors,
regulation, technology trends, economic and social conditions. Note which
of them are expected to change during the system's life.]

### 3.2 Mission, goals and objectives

<!-- Guidance: Each objective must be measurable and dated. Stakeholder requirements in section 5 should each contribute to at least one objective. -->

| ID | Objective | Measure | Baseline | Target | By |
|---|---|---|---|---|---|
| BO-01 | *Example:* Shorten fault-to-repair time | Mean hours from report to closure | 26 h | 12 h | YYYY-MM-DD |
| BO-02 | *Example:* Improve estimate reliability | Share of repairs finished within quoted window | 61% | 90% | YYYY-MM-DD |
| BO-03 | [Objective] | [Measure] | [Value] | [Value] | YYYY-MM-DD |

### 3.3 Business model

[How the organisation creates value in the affected area: services
provided, customers served, revenue or funding, cost drivers and key
partners. Note how the system is expected to change the model.]

### 3.4 Information environment

[The information the business relies on, where it lives today, who owns
it, and the quality problems stakeholders report. Example: "Asset records
are held in the ERP; 12% of hydrant locations are known to be inaccurate."]

## 4. Business operational requirements

<!-- Guidance: Describe how the business operates around the system. These describe the operational context that user requirements must fit. -->

### 4.1 Business processes

<!-- Guidance: List the processes the system supports, with their trigger and outcome. A simple flow diagram per key process helps stakeholders confirm the sequence. -->

| ID | Process | Trigger | Outcome | Process owner | Frequency |
|---|---|---|---|---|---|
| BP-01 | *Example:* Fault intake | Customer call or web report | Logged, prioritised job | Contact centre lead | 300 per day |
| BP-02 | *Example:* Dispatch | New or reprioritised job | Job assigned to crew | Dispatch manager | 300 per day |
| BP-03 | *Example:* Field repair | Crew arrives on site | Repair done, job closed | Field operations manager | 280 per day |
| BP-04 | [Process] | [Trigger] | [Outcome] | [@owner] | [Volume] |

The main process flow for the example is shown below.

```mermaid
flowchart LR
  A[Fault reported] --> B[Job logged and prioritised]
  B --> C[Crew assigned]
  C --> D[Crew travels and repairs]
  D --> E{Repair complete?}
  E -->|Yes| F[Job closed, customer notified]
  E -->|No| C
```

### 4.2 Operational policies and rules

[Policies and business rules the operation must follow. Give each an ID so
that requirements can cite it.]

| ID | Policy or rule | Source | Owner |
|---|---|---|---|
| POL-01 | *Example:* Priority 1 faults (no supply to a hospital) are attended within 2 hours, day or night. | Service charter | Operations director |
| POL-02 | *Example:* A technician may not work alone in a confined space. | Health and safety policy | HSE manager |
| POL-03 | [Rule] | [Source] | [@owner] |

### 4.3 Operational constraints

[Limits on how the business can operate: staffing, shift patterns,
budgets, geography, union agreements, existing contracts, legacy
equipment. State the source of each constraint.]

### 4.4 Operational modes and states

<!-- Guidance: Describe the different ways the business runs (normal, peak, emergency, degraded) and what changes for stakeholders in each. -->

| Mode | When it applies | What changes for stakeholders |
|---|---|---|
| *Example:* Normal | Business as usual | Standard priorities and shift rota |
| *Example:* Major incident | More than 50 open priority 1 jobs | Mutual-aid crews join; dispatch centralised |
| *Example:* Degraded | Mobile network unavailable in an area | Technicians work from printed job sheets |
| [Mode] | [Condition] | [Changes] |

### 4.5 Operational quality

[Quality the business expects from its operation, stated in business
terms: service levels to customers, accuracy of records, regulatory
reporting deadlines, customer satisfaction targets.]

### 4.6 Business structure

[Organisation chart or description of the units, roles, reporting lines
and geographic sites involved. Note planned reorganisations.]

## 5. User requirements

<!-- Guidance: The core of the StRS. Each requirement states a need of one stakeholder group in their own terms, with attributes. Group by stakeholder. Avoid solutions: say what the user must be able to achieve, and how well. -->

### 5.1 Conventions

**Identifiers.** `STK-UR-<nnn>`, never reused, numbered across all groups.

**Wording.** "[Stakeholder] needs to [capability] so that [outcome]" or
"[Stakeholder] shall be able to [capability] [condition] [measure]".

**Attributes.**

| Attribute | Values |
|---|---|
| Source | Stakeholder ID and elicitation record (interview, workshop, observation) |
| Priority | Must / Should / Could / Won't this time |
| Rationale | Why the stakeholder needs it |
| Business objective | BO-ID it supports |
| Validation | How the stakeholder will confirm it is met: demonstration, trial, inspection, survey |
| Stability | Stable / Volatile |
| Status | Proposed, Agreed, Deferred, Rejected |

### 5.2 Requirements of [Stakeholder group 1, for example Dispatchers]

| ID | Requirement | Source | Priority | Rationale | Objective | Validation |
|---|---|---|---|---|---|---|
| STK-UR-001 | *Example:* Dispatchers need to see all open jobs in their region with priority and age on one screen. | STK-01, WS-03 | Must | Jobs are missed when spread across lists | BO-01 | Demonstration |
| STK-UR-002 | *Example:* Dispatchers need to know which technicians are qualified and nearest for a job before assigning it. | STK-01, INT-07 | Must | Wrong-skill assignments cause repeat visits | BO-01 | Trial |
| STK-UR-003 | [Requirement] | [Source] | [Priority] | [Rationale] | [BO-ID] | [Method] |

### 5.3 Requirements of [Stakeholder group 2, for example Field technicians]

| ID | Requirement | Source | Priority | Rationale | Objective | Validation |
|---|---|---|---|---|---|---|
| STK-UR-010 | *Example:* Technicians need job details, asset history and site hazards available without mobile coverage. | STK-02, OBS-02 | Must | 18% of sites have no signal | BO-01 | Field trial |
| STK-UR-011 | *Example:* Technicians need to close a job in under one minute using gloved hands. | STK-02, OBS-04 | Should | Paperwork is done late and inaccurately | BO-02 | Trial |

### 5.4 Requirements of [Stakeholder group 3, for example Customers]

| ID | Requirement | Source | Priority | Rationale | Objective | Validation |
|---|---|---|---|---|---|---|
| STK-UR-020 | *Example:* Customers need a repair time window when they report a fault and an update if it changes. | STK-03, SURV-01 | Must | Top complaint in the last survey | BO-02 | Survey |

### 5.5 Requirements of [Stakeholder group 4, for example Regulator]

| ID | Requirement | Source | Priority | Rationale | Objective | Validation |
|---|---|---|---|---|---|---|
| STK-UR-030 | *Example:* The regulator needs a monthly report of supply interruptions over 3 hours, by area. | STK-04, REF-04 | Must | Licence condition | BO-03 | Inspection |

### 5.6 Conflicting and rejected requirements

[Record conflicts between stakeholders and how they were resolved, and
needs that were rejected or deferred with the reason. This saves reopening
the same debate later.]

| Conflict | Requirements | Resolution | Decided by | Date |
|---|---|---|---|---|
| *Example:* Detail versus speed of job closure | STK-UR-011 vs STK-UR-030 | Mandatory fields limited to those the regulator needs | Sponsor | YYYY-MM-DD |

## 6. Concept of the proposed system

<!-- Guidance: Describe how stakeholders will use the system, in narrative form, without design detail. A full ConOps may be a separate document; summarise it here and reference it. -->

### 6.1 Operational concept

[Describe at a high level how the proposed system will be used to reach
the objectives in 3.2: who uses it, where, when, and how work flows
through it. Reference the ConOps if one exists.]

### 6.2 Operational scenarios

[Short step-by-step stories showing stakeholders using the system in
normal and exceptional situations. Each scenario cites the user
requirements it exercises.]

| ID | Scenario | Actors | Steps (summary) | Requirements exercised |
|---|---|---|---|---|
| SC-01 | *Example:* Burst main reported at night | Customer, dispatcher, technician | Report, auto-priority 1, nearest qualified crew assigned, offline job sheet, closure, customer SMS | STK-UR-001, 002, 010, 020 |
| SC-02 | [Scenario] | [Actors] | [Steps] | [IDs] |

### 6.3 Acquisition, deployment, support and retirement concepts

| Life-cycle stage | Stakeholder expectation |
|---|---|
| Acquisition | [Build, buy or configure; preferred commercial model] |
| Deployment | [Phased by region, pilot first, training approach] |
| Support | [Who supports users, hours, expected response times] |
| Retirement | [How data is kept or migrated when the system is withdrawn] |

## 7. Project constraints

<!-- Guidance: Constraints on the project rather than on the system: budget, schedule, mandated suppliers, staff availability, contractual terms. -->

| ID | Constraint | Source | Impact |
|---|---|---|---|
| PC-01 | *Example:* Go-live before the winter peak, YYYY-MM-DD | Sponsor | Fixes schedule; scope is the variable |
| PC-02 | *Example:* Capital budget of [amount] | Approved business case | Limits custom development |
| PC-03 | [Constraint] | [Source] | [Impact] |

## 8. Verification and validation

<!-- Guidance: Explain how each stakeholder requirement will be confirmed as correctly understood (validation of the requirement) and later as satisfied by the delivered system (acceptance). -->

[Describe the review approach for this StRS (walkthrough with each
stakeholder group, sign-off by representatives) and the acceptance
approach for the delivered system.]

| Requirement | Validation method | Acceptance criterion | Evidence | Result |
|---|---|---|---|---|
| STK-UR-001 | Demonstration | Dispatcher views all regional open jobs, sorted by priority and age, in one view | UAT-DSP-01 | [Pass / Fail / Not run] |
| STK-UR-010 | Field trial | 20 technicians complete jobs at no-signal sites for two weeks with no lost updates | TRIAL-02 | [Result] |
| STK-UR-020 | Survey | 85% of customers rate the quoted window as reliable | SURV-03 | [Result] |
| [ID] | [Method] | [Criterion] | [Evidence] | [Result] |

## 9. Traceability to business needs

<!-- Guidance: Every user requirement traces back to a business objective or policy, and forward to system requirements once the SyRS exists. A requirement with no backward link is a candidate for removal. -->

| Business objective / policy | Stakeholder requirement | System requirement (SyRS) | Status |
|---|---|---|---|
| BO-01 | STK-UR-001, STK-UR-002, STK-UR-010 | [SYS-FR-001, SYS-FR-004] | [Agreed] |
| BO-02 | STK-UR-011, STK-UR-020 | [SYS-FR-012] | [Agreed] |
| POL-01 | STK-UR-002 | [SYS-FR-005] | [Agreed] |
| [ID] | [STK-UR IDs] | [SYS IDs] | [Status] |

## 10. Appendices

<!-- Guidance: Supporting material that would interrupt the main text. -->

### 10.1 Acronyms, abbreviations and glossary

| Term | Definition |
|---|---|
| StRS | Stakeholder requirements specification |
| SyRS | System requirements specification |
| ConOps | Concept of operations |
| [Term] | [Definition used in this document] |

### 10.2 Assumptions and dependencies

| ID | Assumption or dependency | Impact if false | Owner | Review date |
|---|---|---|---|---|
| AD-01 | *Example:* Technicians are issued rugged tablets before the pilot | Offline access cannot be trialled | [@name] | YYYY-MM-DD |
| AD-02 | [Assumption] | [Impact] | [@name] | YYYY-MM-DD |

### 10.3 Open issues

| ID | Issue | Owner | Due | Resolution |
|---|---|---|---|---|
| OI-01 | *Example:* Confirm whether contractors are a separate stakeholder group | [@name] | YYYY-MM-DD | [Open] |
| [OI-nn] | [Issue] | [@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*, stakeholder
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.