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.

Document control

Approvals

Revision history

Contents

1. Introduction
2. References
3. Business management requirements
4. Business operational requirements
5. User requirements
6. Concept of the proposed system
7. Project constraints
8. Verification and validation
9. Traceability to business needs
10. Appendices

1. Introduction

1.1 Business purpose

[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

• 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

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

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

2. References

3. Business management requirements

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

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

4.1 Business processes

The main process flow for the example is shown below.

4.2 Operational policies and rules

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

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

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

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.

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

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

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

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

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

6. Concept of the proposed system

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

6.3 Acquisition, deployment, support and retirement concepts

7. Project constraints

8. Verification and validation

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

9. Traceability to business needs

10. Appendices

10.1 Acronyms, abbreviations and glossary

10.2 Assumptions and dependencies

10.3 Open issues

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.