Concept of Operations (ConOps) Template

Current situation, justification for change, proposed operations, step-by-step scenarios, impacts and alternatives

आवश्यकताएँ और विश्लेषणपूर्णIEEE 1362, ISO/IEC/IEEE 29148:2018conopsअपडेट किया गया 20 अक्टू॰ 2026

उपयोग कैसे करें: Use it early, when users and sponsors must agree how the future operation will work before requirements are written. Describe the current situation and the problems first. The main pitfall is drifting into design detail instead of what users will do.

प्रीव्यू

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.

Document control

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

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

Scope
Referenced documents
Current system or situation
Justification for and nature of changes
Concepts for the proposed system
Operational scenarios
Summary of impacts
Analysis of the proposed system
Notes and appendices

1. Scope

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

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

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.

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

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

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.

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

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

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

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

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.