# Concept of Operations: [System name]

> Complete concept of operations (ConOps) document. The section structure
> follows the ConOps outline described in IEEE 1362 and the concept of
> operations information item referenced by ISO/IEC/IEEE 29148:2018. It
> describes, in the users' language, how the current situation works, why
> it must change, and how the proposed system will be used day to day.
> Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write for users, operators and sponsors, not engineers. A good ConOps
  can be read by a shift supervisor and confirmed as "yes, that is how we
  will work".
- Describe operations, not design. Say what users do and see; leave how
  the system does it to the requirements and architecture documents.
- Start with section 3 (current situation) and section 4 (justification).
  If you cannot describe what is wrong today, the proposed concept will
  not convince anyone.
- Section 6 (scenarios) is the heart of the document. Write at least one
  normal, one stress and one failure scenario.
-->

## Document control

<!-- Guidance: Identify the document so every copy can be traced to one version. -->

| Field | Value |
|---|---|
| Document ID | [CONOPS-SYSTEM-001] |
| System | [System name] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@operations-lead] |
| Author(s) | [@author] |
| Classification | [Internal / Confidential / Public] |
| Last updated | YYYY-MM-DD |
| Related documents | [Business case], [BRS / StRS], [SyRS], [Transition plan] |

### Approvals

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

## Revision history

<!-- Guidance: One row per published version. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial draft after site visits |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added night-shift scenario; revised user classes after workshop 2 |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved by sponsor and operations |

## Contents

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

1. [Scope](#1-scope)
2. [Referenced documents](#2-referenced-documents)
3. [Current system or situation](#3-current-system-or-situation)
4. [Justification for and nature of changes](#4-justification-for-and-nature-of-changes)
5. [Concepts for the proposed system](#5-concepts-for-the-proposed-system)
6. [Operational scenarios](#6-operational-scenarios)
7. [Summary of impacts](#7-summary-of-impacts)
8. [Analysis of the proposed system](#8-analysis-of-the-proposed-system)
9. [Notes and appendices](#9-notes-and-appendices)

## 1. Scope

<!-- Guidance: Identify the system and orient the reader. Keep it to one page. -->

### 1.1 Identification

[Full name, abbreviation, identifier and release of the system this
ConOps applies to.]

*Example:* Regional Emergency Dispatch Platform (REDP), release 1, serving
the three counties of [region].

### 1.2 Document overview

[Purpose of this document, intended readers, and how it relates to the
requirements and design documents. State any security or privacy handling
rules for the document itself.]

### 1.3 System overview

[One or two paragraphs: what the system is for, its sponsor, acquirer,
users, developers and support organisation, and the sites where it will
operate. Describe it as the users will experience it.]

## 2. Referenced documents

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

| ID | Title | Version / date | Source |
|---|---|---|---|
| REF-01 | IEEE 1362, Guide for Concept of Operations Document | [Edition] | IEEE |
| REF-02 | ISO/IEC/IEEE 29148:2018 Requirements engineering | 2018 | ISO / IEC / IEEE |
| REF-03 | [Business case] | [x.y] | [Location] |
| REF-04 | [Current procedures manual] | [x.y] | [Location] |

## 3. Current system or situation

<!-- Guidance: Describe things as they are today, including manual workarounds. Do not argue for change here; that is section 4. Observation beats interviews for this section. -->

### 3.1 Background, objectives and scope

[History of the current operation, what it is meant to achieve, and the
area it covers.]

### 3.2 Operational policies and constraints

[Rules and limits that govern current operations: staffing levels, shift
patterns, response targets, legal duties, budgets.]

### 3.3 Description of the current system or situation

[How work is done today: the tools, the steps, the information flows and
the hand-offs. Include manual steps and spreadsheets; they are part of the
real system.]

The current flow is shown below.

```mermaid
flowchart LR
  A[Caller dials emergency line] --> B[Call taker writes card]
  B --> C[Card passed to radio dispatcher]
  C --> D[Dispatcher radios nearest unit by memory]
  D --> E[Unit reports status by radio]
  E --> F[Dispatcher updates whiteboard]
```

### 3.4 Modes of operation

| Mode | Description |
|---|---|
| *Example:* Normal | Two call takers and one dispatcher per county |
| *Example:* Surge | Off-duty staff recalled by phone tree; average 40 min to staff up |
| *Example:* Backup site | Paper-only operation from the fire station annex |
| [Mode] | [Description] |

### 3.5 User classes and other involved personnel

| User class | Number | Responsibilities | Skills and training | Interaction with system |
|---|---|---|---|---|
| *Example:* Call taker | 36 | Answer calls, record details | 6 weeks certification | Telephone, paper cards |
| *Example:* Dispatcher | 18 | Assign units, track status | 3 years experience typical | Radio, whiteboard |
| *Example:* Field unit crew | 420 | Respond to incidents | Varies by service | Radio |
| [Class] | [n] | [Responsibilities] | [Skills] | [Interaction] |

### 3.6 Support environment

[Who maintains today's equipment and procedures, support hours, spares,
and known support problems.]

## 4. Justification for and nature of changes

<!-- Guidance: Connect each problem in section 3 to a change. Rank the changes so that scope can be cut sensibly if budget falls short. -->

### 4.1 Justification for changes

[Problems, deficiencies and new needs that justify change: missed
targets, growth, new regulation, obsolete equipment. Quantify them.]

*Example:* In the last 12 months, 22% of priority calls missed the 8-minute
response target. Post-incident reviews attribute 60% of those misses to
dispatchers not knowing the nearest available unit.

### 4.2 Description of desired changes

| ID | Desired change | Type | Problem addressed |
|---|---|---|---|
| CH-01 | *Example:* Show live unit locations to dispatchers | Capability | Nearest unit unknown |
| CH-02 | *Example:* Share incidents across county boundaries | Interface | Border incidents delayed |
| CH-03 | *Example:* Electronic call records | Data | Lost or illegible cards |
| CH-04 | [Change] | [Capability / Interface / Personnel / Environment / Support] | [Problem] |

### 4.3 Priorities among changes

| Priority | Changes | Reason |
|---|---|---|
| Essential | CH-01, CH-03 | Directly affect response time and legal record keeping |
| Desirable | CH-02 | Benefit limited to border areas |
| Optional | [CH-nn] | [Reason] |

### 4.4 Changes considered but not included

[Changes discussed and rejected or deferred, with the reason, so they are
not raised again without new information.]

*Example:* Automatic unit assignment without dispatcher confirmation was
rejected because the services' unions and medical directors require a
human decision for every dispatch.

### 4.5 Assumptions and constraints

[Assumptions and constraints that apply to the proposed changes: funding,
existing radio network, staff numbers, legal limits.]

## 5. Concepts for the proposed system

<!-- Guidance: Describe the future operation at the same level as section 3, so a reader can compare them side by side. -->

### 5.1 Background, objectives and scope

[What the proposed system will achieve and the operational area it
covers.]

### 5.2 Operational policies and constraints

[Policies that will apply in the future operation, including new ones
created by the system.]

### 5.3 Description of the proposed system

[How the operation will work: main components as users see them, the
information each user has, and the flow of work.]

The proposed flow is shown below.

```mermaid
flowchart LR
  A[Caller dials emergency line] --> B[Call taker records incident on screen]
  B --> C[Platform suggests nearest available units]
  C --> D[Dispatcher confirms assignment]
  D --> E[Unit receives incident on vehicle terminal]
  E --> F[Unit status updates automatically]
```

### 5.4 Modes of operation

| Mode | Description | Change from today |
|---|---|---|
| *Example:* Normal | Each county staffed as today; shared incident view | Common picture across counties |
| *Example:* Surge | Any console can take any county's calls | Staffing shifts in minutes, not 40 min |
| *Example:* Degraded | Local cache keeps incidents if the data centre link fails | Paper fallback only as last resort |
| [Mode] | [Description] | [Change] |

### 5.5 User classes and other involved personnel

| User class | Future responsibilities | New skills needed | Training |
|---|---|---|---|
| *Example:* Call taker | Records incidents directly on screen | Structured questioning in the platform | 2 days |
| *Example:* Dispatcher | Confirms suggested assignments | Map-based dispatch | 3 days plus simulator |
| *Example:* Field unit crew | Acknowledges incidents on terminal | Terminal use | 2 hours |
| [Class] | [Responsibilities] | [Skills] | [Training] |

### 5.6 Support environment

[Future support: service desk, hours, vendor support, spares for vehicle
terminals, maintenance windows.]

## 6. Operational scenarios

<!-- Guidance: Each scenario is a short, concrete story with numbered steps. Cover normal, peak, failure and recovery situations. Name the users and systems involved and the requirements or changes each scenario demonstrates. -->

### 6.1 Scenario OS-01: [Normal operation, for example Single priority call]

**Situation.** [Who, where, when, and the starting state.]

*Example:* Weekday afternoon, normal staffing. A caller reports a person
collapsed in a supermarket.

| Step | Actor | Action | System response |
|---|---|---|---|
| 1 | Caller | Dials emergency number | Call routed to free call taker; caller location shown |
| 2 | Call taker | Records location and complaint | Incident created, priority 1 suggested |
| 3 | Dispatcher | Reviews three suggested ambulances | Travel times shown for each |
| 4 | Dispatcher | Confirms nearest unit | Incident sent to vehicle terminal |
| 5 | Ambulance crew | Acknowledges, drives to scene | Status "en route" with live position |
| 6 | Ambulance crew | Marks "on scene" | Response time recorded automatically |

**Outcome.** Unit on scene in [n] minutes; complete electronic record.
**Demonstrates.** CH-01, CH-03.

### 6.2 Scenario OS-02: [Peak or stress, for example Multi-vehicle collision on county border]

**Situation.** [Starting state.]

| Step | Actor | Action | System response |
|---|---|---|---|
| 1 | Several callers | Report the same collision | Platform flags possible duplicates by location and time |
| 2 | Call taker | Links calls to one incident | Single incident with all caller details |
| 3 | Dispatcher (county A) | Requests units from county B | Units from both counties shown on one map |
| 4 | Dispatcher (county B) | Approves loan of two units | Units assigned; both dispatchers see status |
| 5 | Incident commander | Requests more resources | Request logged; supervisor alerted |

**Outcome.** [Result.] **Demonstrates.** CH-02.

### 6.3 Scenario OS-03: [Failure, for example Loss of data centre link]

**Situation.** [Starting state and the failure.]

| Step | Actor | Action | System response |
|---|---|---|---|
| 1 | Platform | Detects loss of link | Consoles switch to local mode and show a banner |
| 2 | Call taker | Continues recording incidents | Incidents stored locally |
| 3 | Dispatcher | Assigns units by radio | Assignments recorded locally |
| 4 | Platform | Link restored | Local records synchronised; conflicts listed for review |
| 5 | Supervisor | Reviews conflict list | Record corrected and signed off |

**Outcome.** [Result.] **Demonstrates.** [Mode or requirement.]

### 6.4 Scenario OS-04: [Maintenance or support, for example Vehicle terminal replacement]

**Situation.** [Starting state.]

*Example:* A vehicle terminal in an ambulance fails at the start of a
night shift. The ambulance is otherwise ready for service.

| Step | Actor | Action | System response |
|---|---|---|---|
| 1 | Ambulance crew | Reports terminal fault to the service desk | Ticket opened; unit flagged "radio only" on dispatcher map |
| 2 | Dispatcher | Continues to assign the unit by radio | Assignments entered on the crew's behalf and logged |
| 3 | Fleet technician | Swaps terminal from spares stock | New terminal registers itself to the vehicle |
| 4 | Platform | Pushes current incident and settings to the terminal | "Radio only" flag cleared |
| 5 | Service desk | Closes ticket with time to repair | Repair time recorded for support reporting |

**Outcome.** The unit stays in service throughout; no incident data is
lost. **Demonstrates.** Support environment in 5.6, CH-01.

## 7. Summary of impacts

<!-- Guidance: Be honest about what will be harder, more expensive or disruptive. Hidden impacts become resistance later. -->

### 7.1 Operational impacts

[Changes to procedures, interfaces with other organisations, data
retention, contingency arrangements and response times during and after
transition.]

### 7.2 Organisational impacts

[Changes to roles, responsibilities, staffing levels, skills, training,
shift patterns and union agreements.]

| Area | Impact | Mitigation | Owner |
|---|---|---|---|
| *Example:* Dispatcher role | Shift from finding units to confirming suggestions | Simulator training; review after 3 months | [@name] |
| *Example:* Paper records | Clerical post no longer needed | Redeploy to quality review | [@name] |
| [Area] | [Impact] | [Mitigation] | [@name] |

### 7.3 Impacts during development

[Effects on current operations while the system is being built and
introduced: staff released for workshops and testing, parallel running,
data migration, temporary procedures.]

## 8. Analysis of the proposed system

<!-- Guidance: Weigh the concept fairly: benefits, limits and the options that were rejected. Reviewers trust a ConOps that admits disadvantages. -->

### 8.1 Summary of improvements

| Improvement | Measure | Today | Expected |
|---|---|---|---|
| *Example:* Priority calls meeting response target | % within 8 min | 78% | 90% |
| *Example:* Time to staff a surge | Minutes | 40 | 5 |
| [Improvement] | [Measure] | [Value] | [Value] |

### 8.2 Disadvantages and limitations

[New problems the system introduces or does not solve. Example: reliance
on GPS coverage, which is poor in two valleys; dispatchers may over-trust
suggestions.]

### 8.3 Alternatives and trade-offs considered

| Alternative | Description | Advantages | Disadvantages | Decision |
|---|---|---|---|---|
| A1 | *Example:* Upgrade current radio system only | Lowest cost; no retraining | Does not fix nearest-unit problem | Rejected |
| A2 | *Example:* Join neighbouring region's platform as a tenant | Faster start | Loss of local configuration control | Considered for phase 2 |
| A3 | *Example:* Proposed regional platform | Meets all essential changes | Highest cost; larger change | Selected |
| [An] | [Description] | [Advantages] | [Disadvantages] | [Decision] |

## 9. Notes and appendices

<!-- Guidance: Glossary, background studies and supporting data. -->

### 9.1 Glossary

| Term | Definition |
|---|---|
| ConOps | Concept of operations |
| Dispatch | Assigning a response unit to an incident |
| Surge | Period when call volume exceeds normal staffing capacity |
| [Term] | [Definition] |

### 9.2 Supporting data

[Call volume statistics, site visit notes, survey results, cost
estimates. Reference them by ID if they are held elsewhere.]

### 9.3 Open issues

| ID | Issue | Owner | Due | Resolution |
|---|---|---|---|---|
| OI-01 | *Example:* Confirm whether police dispatch joins in phase 1 | [@name] | YYYY-MM-DD | [Open] |
| [OI-nn] | [Issue] | [@name] | YYYY-MM-DD | [Resolution] |

## Standard and licence note

Structure aligned with IEEE 1362, *Guide for Information Technology:
System Definition, Concept of Operations (ConOps) Document*, and with the
concept of operations content referenced by ISO/IEC/IEEE 29148:2018. This
template is original text written for this collection and reproduces no
text from either standard; obtain the standards from IEEE or ISO for their
normative content. Template licence: MIT.