# System Operational Concept (OpsCon): [System name]

> System operational concept (OpsCon) for one proposed system: who will
> operate and support it, in which environment, in which modes, and
> through which scenarios, told from the users' point of view. It is the
> system-level information item that ISO/IEC/IEEE 29148:2018,
> *Requirements engineering*, distinguishes from the organisation-level
> concept of operations (ConOps). Use `requirements/conops` for the
> organisation level and this template when one system needs its own
> operational concept as the input to stakeholder requirements.
> Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write for operators, maintainers, users and the acquirer. A shift
  supervisor should be able to read section 6 and say "yes, that is how
  we will work with it".
- Describe use, not design. Say what people do, see and decide; leave
  how the system does it to the system requirements and architecture.
- Start with the modes (section 5) and the scenarios (section 6). Every
  stakeholder requirement written later should trace to a scenario ID.
- Cite the organisation-level ConOps in section 1.3 instead of repeating
  the business justification here.
- ISO/IEC/IEEE 29148 is a paid standard. This template uses its name,
  edition and the names of its information items only; buy or license
  the official text for the normative content.
-->

## Document control

<!-- Guidance: Identify the document so every copy can be traced to one version. Record the life cycle stage, because an OpsCon for an upgrade answers different questions from one for a new system. -->

| Field | Value |
|---|---|
| Document ID | [OPSCON-SYSTEM-001] |
| System | [System name and version or increment] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@systems-engineer] |
| Acquirer / sponsor | [Organisation unit] |
| Approvers / reviewers | [Operations lead, maintenance lead, user representative, safety or security reviewer] |
| Life cycle stage | [Concept / Development / Utilization / Support / Retirement] |
| Parent ConOps | [CONOPS-xxx or "none"] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Operations lead | [@name] | [Approved / Approved with comments / Rejected] | YYYY-MM-DD |
| Maintenance lead | [@name] | [Decision] | YYYY-MM-DD |
| User representative | [@name] | [Decision] | YYYY-MM-DD |
| Systems engineering lead | [@name] | Author | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial draft |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added degraded mode DM-02 after the operator workshop |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved as input to the stakeholder requirements |

## Contents

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

1. [Scope](#1-scope)
2. [References](#2-references)
3. [Operational environment](#3-operational-environment)
4. [Users, operators and support roles](#4-users-operators-and-support-roles)
5. [Operational modes and states](#5-operational-modes-and-states)
6. [Operational scenarios](#6-operational-scenarios)
7. [Support concept](#7-support-concept)
8. [Operational constraints and expectations](#8-operational-constraints-and-expectations)
9. [Impacts of the system](#9-impacts-of-the-system)
10. [Traceability to requirements and validation](#10-traceability-to-requirements-and-validation)
11. [Glossary and open issues](#11-glossary-and-open-issues)

## 1. Scope

<!-- Guidance: Identify the system, its boundary and its purpose in one page. Questions: what is inside the system, what is an external system, which organisation-level concept does it serve? Pitfall: a boundary so vague that two teams both think an interface belongs to the other. -->

### 1.1 System identification

[System name, short code, version or increment, acquirer, developer,
operator and maintainer.]

*Example:* LeakWatch is a district leak detection system for Kestrelmoor
Water (a fictional utility). It combines 1,200 acoustic sensors on the
distribution network, a central analytics service and a mobile app for
field crews. The control room operates it, the network maintenance team
repairs leaks, and an external supplier maintains the sensors.

### 1.2 System purpose and boundary

[What the system is for, and what is inside and outside its boundary.]

| Inside the system boundary | Outside (external systems and actors) |
|---|---|
| [Sensors, gateways, analytics service, control room console, field app] | [Work order system, geographic information system, telemetry network, customer contact centre] |

### 1.3 Relationship to the organisation-level ConOps

[Cite the ConOps (`requirements/conops`) and say which of its operations
this system supports. If there is no ConOps, state the organisation's
operational objective in two sentences.]

*Example:* The Kestrelmoor network ConOps sets the objective of halving
the average time leaks run before repair. LeakWatch supports its
operations "detect", "locate" and "dispatch"; "repair" remains with the
existing work order process.

### 1.4 Where this document sits

| 29148:2018 information item | Level | Relationship to this OpsCon |
|---|---|---|
| Concept of operations (ConOps) | Organisation | Parent; cited in 1.3 |
| System operational concept (OpsCon) | System | This document |
| Stakeholder requirements specification (StRS) | System | Consumes sections 4 to 8 (`requirements/stakeholder-requirements`) |
| System requirements specification (SyRS) | System | Consumes section 8 through the StRS (`requirements/system-requirements`) |

## 2. References

<!-- Guidance: List every document a reader needs, with version and date. Cite external standards by full title and edition. -->

| ID | Document | Version / date |
|---|---|---|
| REF-01 | [Organisation-level ConOps] | [Version] |
| REF-02 | [Business requirements specification] | [Version] |
| REF-03 | ISO/IEC/IEEE 29148:2018, *Systems and software engineering: Life cycle processes: Requirements engineering* | Second edition, 2018 |
| REF-04 | ISO/IEC/IEEE 15288:2023, *Systems and software engineering: System life cycle processes* | 2023 |
| REF-05 | [Applicable safety, security or regulatory documents] | [Version] |

## 3. Operational environment

<!-- Guidance: Describe where and under what conditions the system is used. Questions: physical sites, climate, connectivity, hours of operation, other systems that share the environment, threats? Pitfall: describing only the data centre and forgetting the field. -->

| Aspect | Description |
|---|---|
| Sites | [Control room, field locations, supplier depot] |
| Physical conditions | [Temperature, humidity, ingress, noise, vibration] |
| Connectivity | [Networks used, expected coverage, fallback] |
| Hours of operation | [24x7, business hours, seasonal peaks] |
| Interfacing systems | [List with owner] |
| Security environment | [Threats, zones, physical access] |
| Regulatory environment | [Licences, reporting duties] |

*Example:* Sensors are installed in chambers below street level, often
flooded, with cellular coverage that drops in 4% of chambers. The
control room runs 24 hours a day with two operators at night.

## 4. Users, operators and support roles

<!-- Guidance: Describe each class of user by what they do with the system, their skills and their constraints. Questions: who touches the system, how often, with what training, under what pressure? Pitfall: one class called "user" that hides five very different jobs. -->

| ID | User class | Tasks with the system | Skills and training | Frequency | Constraints |
|---|---|---|---|---|---|
| UC-01 *(Example)* | Control room operator | Monitor alerts, confirm leaks, raise work orders | Network operations, 2-day system course | Continuous | Night shift alone or in pairs, many other screens |
| UC-02 *(Example)* | Field crew technician | Receive leak locations, confirm on site, close tasks | Leak location, smartphone use | Daily | Gloves, rain, poor coverage |
| UC-03 *(Example)* | Network analyst | Tune detection thresholds, review missed leaks | Hydraulics, data analysis | Weekly | Office based |
| UC-04 *(Example)* | Sensor maintainer (supplier) | Replace batteries and faulty sensors | Supplier certification | Monthly rounds | Contracted response times |
| [UC-nn] | [Class] | [Tasks] | [Skills] | [Frequency] | [Constraints] |

## 5. Operational modes and states

<!-- Guidance: List the modes the system can be in, from the operators' view, and how it moves between them. Questions: what does the operator see in each mode, who can switch modes, what is lost in degraded mode? Pitfall: modes that exist in the design but that no operator can recognise. -->

| ID | Mode | Description | Entered when | Exited when | What operators can still do |
|---|---|---|---|---|---|
| OM-01 *(Example)* | Normal | All functions available | Start-up checks pass | Fault, maintenance or training selected | Everything |
| DM-01 *(Example)* | Degraded: partial sensor coverage | More than 10% of sensors in a district silent | Coverage check fails | Coverage restored | Monitor other districts, manual leak reports |
| DM-02 *(Example)* | Degraded: analytics unavailable | Central analytics service down | Health check fails | Service restored | View raw sensor alarms only |
| MM-01 *(Example)* | Maintenance | Planned update or recalibration | Operator lead schedules it | Checks pass | Receive manual reports only |
| TM-01 *(Example)* | Training | Simulated alerts on a separate data set | Trainer selects it | Trainer exits it | Training only, no live work orders |

The diagram shows the permitted transitions between the modes in the
table above.

```mermaid
stateDiagram-v2
  [*] --> Normal
  Normal --> PartialCoverage: sensor coverage below threshold
  PartialCoverage --> Normal: coverage restored
  Normal --> AnalyticsDown: analytics health check fails
  AnalyticsDown --> Normal: service restored
  Normal --> Maintenance: planned window starts
  Maintenance --> Normal: checks pass
  Normal --> Training: trainer selects training
  Training --> Normal: trainer exits
```

## 6. Operational scenarios

<!-- Guidance: The heart of the document. Write each scenario as a short story with a trigger, the steps people and the system take, and the outcome. Include at least one normal, one peak, one degraded or failure and one support scenario. Pitfall: scenarios that describe screens instead of work. -->

### 6.1 Scenario OS-01: [Normal operation, for example Leak detected and repaired]

| Item | Content |
|---|---|
| Trigger | [Event that starts it] |
| Actors | [User classes and external systems] |
| Mode | [OM-01] |
| Preconditions | [What is true before] |
| Outcome | [What is true after, with a measure] |

*Example:* Steps:

1. Sensors in district D14 report a noise pattern consistent with a leak.
2. LeakWatch raises an alert with an estimated location on the control
   room console.
3. The operator (UC-01) checks recent works and pressure data and
   confirms the alert.
4. The operator raises a work order; LeakWatch sends the location to the
   field app.
5. A technician (UC-02) confirms the leak on site and starts the repair.
6. After the repair the technician closes the task; LeakWatch watches the
   district for 48 hours and clears the alert.

```mermaid
sequenceDiagram
  participant S as Sensors
  participant L as LeakWatch
  participant O as Control room operator
  participant W as Work order system
  participant T as Field technician
  S->>L: Noise pattern from district D14
  L->>O: Alert with estimated location
  O->>L: Confirm alert
  O->>W: Raise work order
  L->>T: Send location to field app
  T->>L: Confirm leak on site
  T->>W: Close task after repair
  L->>O: Clear alert after 48 hours of quiet
```

### 6.2 Scenario OS-02: [Peak, for example Freeze and thaw night]

[Many alerts at once after a cold night. Describe how operators triage,
which alerts are grouped, and what the system must not do (for example
hide a large burst behind many small leaks).]

### 6.3 Scenario OS-03: [Degraded, for example Analytics service unavailable]

[The system enters DM-02. Operators fall back to raw sensor alarms and
customer reports. Describe what they lose, how long they can work this
way, and how they know the system has recovered.]

### 6.4 Scenario OS-04: [Support, for example Sensor replacement round]

[The supplier's maintainer replaces sensors. Describe scheduling, how
the control room knows which sensors are offline on purpose, and how
the replaced sensors are checked before use.]

### 6.5 Scenario summary

| ID | Scenario | Type | Modes | User classes |
|---|---|---|---|---|
| OS-01 | Leak detected and repaired | Normal | OM-01 | UC-01, UC-02 |
| OS-02 | Freeze and thaw night | Peak | OM-01, DM-01 | UC-01, UC-02, UC-03 |
| OS-03 | Analytics service unavailable | Failure | DM-02 | UC-01 |
| OS-04 | Sensor replacement round | Support | MM-01 | UC-01, UC-04 |

## 7. Support concept

<!-- Guidance: Describe how the system is kept working over its life: maintenance, supply, training, help desk, updates and disposal. Questions: who fixes what, within what time, with which spares and skills? Pitfall: leaving support to the contract and discovering at handover that nobody owns the gateways. -->

| Aspect | Concept |
|---|---|
| Maintenance levels | [First line by operators, second line by the internal IT team, third line by the supplier] |
| Response and repair times | [Targets per component, stated as expectations for the StRS] |
| Spares and logistics | [Stock levels, depots, lead times] |
| Updates | [How software and firmware updates are tested, scheduled and rolled back] |
| Training | [Initial and refresher training per user class, training mode TM-01] |
| Help desk | [Hours, channels, escalation] |
| Disposal | [Sensor batteries and electronics, data deletion at retirement] |

## 8. Operational constraints and expectations

<!-- Guidance: State the constraints and performance expectations that the stakeholder requirements must turn into verifiable requirements. Mark each with its source. Pitfall: writing system requirements here; keep these as expectations in the users' terms. -->

| ID | Constraint or expectation | Source | Becomes requirement |
|---|---|---|---|
| OC-01 *(Example)* | Operators see a new alert on the console within one minute of detection | Operations lead | STK-PF-001 |
| OC-02 *(Example)* | The field app works without coverage and synchronises later | Field crew workshop | STK-OP-004 |
| OC-03 *(Example)* | Training mode never creates a live work order | Control room procedures | STK-SF-002 |
| OC-04 *(Example)* | Sensor data is kept no longer than the network records policy allows | Records policy | STK-DT-003 |
| [OC-nn] | [Constraint] | [Source] | [STK ID] |

## 9. Impacts of the system

<!-- Guidance: Describe how the system changes work, organisation and other systems, so that change management can prepare. Questions: whose job changes, which procedures are rewritten, what happens during transition? Pitfall: ignoring the transition period when old and new run side by side. -->

| Area | Impact | Action and owner |
|---|---|---|
| Control room | [New console, new alert triage procedure] | [Procedure update, @operations-lead] |
| Field crews | [Locations on the app instead of radio] | [Training, @maintenance-lead] |
| Network analysts | [New threshold tuning duty] | [Role description, @analytics-lead] |
| External systems | [New interface to the work order system] | [Interface agreement, @integration-lead] |
| Transition | [Old and new detection run in parallel for one quarter] | [Transition plan, @project-manager] |

## 10. Traceability to requirements and validation

<!-- Guidance: Show that every scenario and constraint feeds at least one stakeholder requirement and one validation activity. Pitfall: scenarios that nobody validates, so the OpsCon is never checked against reality. -->

| Scenario or constraint | Stakeholder requirements | Validation activity |
|---|---|---|
| OS-01 *(Example)* | STK-UR-001 to STK-UR-006, STK-PF-001 | Operational trial in district D14 |
| OS-02 *(Example)* | STK-UR-010, STK-UR-011 | Replay of last winter's data |
| OS-03 *(Example)* | STK-OP-002, STK-OP-003 | Failure drill with the analytics service stopped |
| OS-04 *(Example)* | STK-SP-001 | Supplier round witnessed by the control room |
| OC-03 *(Example)* | STK-SF-002 | Training mode test |

Keep the full matrix in `requirements/traceability-matrix`.

## 11. Glossary and open issues

<!-- Guidance: Define terms the operators and engineers might read differently, and record unresolved questions with an owner. -->

### 11.1 Glossary

| Term | Meaning |
|---|---|
| ConOps | Concept of operations: the organisation-level description of intended operations (ISO/IEC/IEEE 29148) |
| OpsCon | System operational concept: how one proposed system will be used and supported, from the users' point of view (ISO/IEC/IEEE 29148) |
| Mode | A recognisable way of operating the system, with its own set of available functions |
| Scenario | A short story of how people and the system act together to reach an outcome |
| StRS | Stakeholder requirements specification |

### 11.2 Open issues

| ID | Issue | Owner | Due | Resolution |
|---|---|---|---|---|
| OI-01 *(Example)* | Confirm whether the contact centre sees live alerts | [@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* (second
edition, 2018), which describes the system operational concept (OpsCon)
as an information item separate from the organisation-level concept of
operations. The section sequence (environment, users, modes, scenarios,
support, impacts) follows common systems engineering practice; check the
official text for the outline the standard gives. As of October 2026 the
2018 edition is current and a third edition is at Draft International
Standard stage, so check the current edition before use. Process names
refer to ISO/IEC/IEEE 15288:2023. This template is original text written
for this collection and reproduces no text from either standard.
Official text: ISO, IEC and IEEE, purchase or licensed access at
https://www.iso.org/standard/72089.html (29148) and
https://www.iso.org/standard/81702.html (15288). Template licence: MIT.