U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590

Skip to content U.S. Department of Transportation/Federal Highway AdministrationU.S. Department of Transportation/Federal Highway Administration

California Division

Home / About / Field Offices / California Division / Systems Engineering Guidebook for ITS

Home What's New Systems Engineering Guidebook Views Search Glossary Resources Feedback Site Map

8.4.5 Concept of Operations Template

Purpose of this Document

The Concept of Operations is a description of how the system will be used. It is non-technical, and presented from the viewpoints of the various stakeholders. This provides a bridge between the often vague needs that motivated the project to begin with and the specific technical requirements. There are several reasons for developing a Concept of Operations.

  • Get stakeholder agreement identifying how the system is to be operated, who is responsible for what, and what the lines of communication are
  • Define the high-level system concept and justify that it is superior to the other alternatives
  • Define the environment in which the system will operate
  • Derive high-level requirements, especially user requirements
  • Provide the criteria to be used for validation of the completed system

Tailoring this Document to Your Project

The greater the expected impact on operations, the more detailed the Concept of Operations needs to be. For example, automating operations that were formerly manual or integrating activities that were formerly independent will require the involvement of the various operators, clear and detailed description of their new procedures, and possibly examination of alternative approaches. This is especially true when building a regional system by integrating existing local systems. Local operations will usually change after integration, for compatibility and to take advantage of newly available regional resources.

For a simple system that requires little operator involvement and no coordination, this document may only be a couple of pages long. The key is to describe all possible system modes, both normal and failure, as seen by each stakeholder.

Figure 8‑1 shows two standard outlines for the Concept of Operations.  As shown, the ANSI outline lends itself to new systems while the IEEE standard is well suited to system upgrades with its initial focus on the current system.

Checklist: Critical Information

check Is the reason for developing the system clearly stated?
check Are all the stakeholders identified and their anticipated roles described? This should include anyone who will operate, maintain, build, manage, use, or otherwise be affected by the system.
check Are alternative operational approaches [such as centralized vs. distributed] described and the selected approach justified?
check Is the external environment described? Does it include required interfaces to existing systems?
check Is the support environment described? Does it include maintenance?
check Is the operational environment described?
check Are there clear and complete descriptions of normal operational scenarios?
check Are there clear and complete descriptions of maintenance and failure scenarios?
check Do the scenarios include the viewpoints of all involved stakeholders? Do they make it clear who is doing what?
check Are all constraints on the system development identified?


Figure 8‑1: Concept of Operations Standard Outlines


Relevant standards are the ANSI/AIAA G-043-1992 standard and IEEE Standard 1362



Title Page

The title page should follow the Transportation Agency procedures or style guide. At a minimum, it should contain the following information:

  • CONCEPT OF OPERATIONS FOR THE [insert name of project] AND [insert name of transportation agency]
  • Contract number
  • Date that the document was formally approved
  • The organization responsible for preparing the document
  • Internal document control number, if available
  • Revision version and date issued

1.0 Purpose of Document

This section is a brief statement of the purpose of this document. It is a description and rationale of the expected operations of the system under development. It is a vehicle for stakeholder discussion and consensus to ensure that the system that is built is operationally feasible. This will briefly describe contents, intention, and audience. One or two paragraphs will suffice.

2.0 Scope of Project

This short section gives a brief overview of the system to be built. It includes its purpose and a high-level description. It describes what area will be covered and which agencies will be involved, either directly or through interfaces. One or two paragraphs will suffice.

3.0 Referenced Documents

This optional section is a place to list any supporting documentation used and other resources that are useful in understanding the operations of the system. This could include any documentation of current operations and any strategic plans that drive the goals of the system under development.

4.0 Background

Here is a brief description of the current system or situation, how it is used currently, and its drawbacks and limitations. This leads into the reasons for the proposed development and the general approach to improving the system. This is followed by a discussion of the nature of the planned changes and a justification for them.

5.0 Concept for the Proposed System

This section describes the concept exploration. It starts with a list and description of the alternative concepts examined. The evaluation and assessment of each alternative follows. This leads into the justification for the selected approach. The operational concept for that selected approach is described here. This is not a design, but a high-level, conceptual, operational description. It uses only as much detail as needed to be able to develop meaningful scenarios. In particular, if alternative approaches differ in terms of which agency does what, that will need to be resolved and described. An example would be the question of whether or not a regional signal system will have centralized control.

6.0 User-Oriented Operational Description

This section focuses on how the goals and objectives are accomplished currently. Specifically, it describes strategies, tactics, policies, and constraints. This is where the stakeholders are described. It includes who users are and what the users do. Specifically, it covers when, and in what order, operations take place, personnel capabilities, organizational structures, personnel & inter-agency interactions, and types of activities. This may also include operational process models in terms of sequence and interrelationships.

7.0 Operational Needs

Here is a description of the vision, goals & objectives, and personnel needs that drive the requirements for the system. Specifically, this describes what the system needs to do that it is not currently doing.

8.0 System Overview

This is an overview of the system to be developed. This describes its scope, the users of the system, what it interfaces with, its states and modes, the planned capabilities, its goals & objectives, and the system architecture. Note that the system architecture is not a design [that will be done later]. It provides a structure for describing the operations, in terms of where the operations will be carried out, and what the lines of communication will be.

9.0 Operational Environment

This section describes the physical operational environment in terms of facilities, equipment, computing hardware, software, personnel, operational procedures and support necessary to operate the deployed system. For example, it will describe the personnel in terms of their expected experience, skills and training, typical work hours, and other activities [e.g., driving] that must be or may be performed concurrently.

10.0 Support Environment

This describes the current and planned physical support environment. This includes facilities, utilities, equipment, computing hardware, software, personnel, operational procedures, maintenance, and disposal. This includes expected support from outside agencies.

11.0 Operational Scenarios

This is the heart of the document. Each scenario describes a sequence of events, activities carried out by the user, the system, and the environment. It specifies what triggers the sequence, who or what performs each step, when communications occur and to whom or what [e.g., a log file], and what information is being communicated. The scenarios will need to cover all normal conditions, stress conditions, failure events, maintenance, and anomalies and exceptions. There are many ways for presenting scenarios, but the important thing is that each stakeholder can clearly see what his expected role is to be.

12.0 Summary of Impacts

This is an analysis of the proposed system and the impacts on each of the stakeholders. It is presented from the viewpoint of each, so that they can readily understand and validate how the proposed system will impact their operations. Here is where any constraints on system development are documented. Metrics for assessing system performance are also included here.

13.0 Appendices

This is a place to put a glossary, notes, and backup or background material for any of the sections. For example, it might include analysis results in support of the concept exploration.


Related Task Examples Checklist  


Return to top
Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000