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

Skip to content
Facebook iconYouTube iconTwitter iconFlickr iconLinkedInInstagram

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

3.4.3 Concept of Operations



The Concept of Operations

  • documents the total environment and use of the system to be developed in a non-technical and easy-to-understand manner
  • presents this information from multiple viewpoints
  • provides a bridge from the problem space and stakeholder needs to the system level requirements


The Concept of Operations document results from a stakeholder view of the operations of the system being developed. This document will present each of the multiple views of the system corresponding to the various stakeholders. These stakeholders include operators, users, owners, developers, maintenance, and management. This document can be easily reviewed by the stakeholders to get their agreement on the system description. It also provides the basis for user requirements.


Shows the flow for Phase [1] Task 3, Concept of Operations Process.  Summaries are described for inputs, constraints, and enablers into the task;  activities of the task; and outputs from the task.  The flow is described in detail in the accompanying text.



Project goals and objectives determine how the system will be used.

Recommended system concept describes the concept selected with the best benefit for the cost. This concept will be the basis for the concept of operations.

Regional ITS architecture will provide the roles and responsibilities of the primary stakeholders and the systems they operate, which may suggest features for the project concept of operations.

Needs Assessment includes the list of collected needs, their sources, and documentation of the rationale for the selection of the key needs and any constraints that exist that may limit possible solutions to the needs. The development of the Concept of Operations starts with these needs and constraints.

Feasibility assessment or FSR defines and analyzes the conceptual system and, in the process, provides operational information.


The Project Plan describes the project and the SEMP describes the systems engineering effort needed for development. They both guide what may be developed.


Elicitation supports continual stakeholder input and review. This is essential to developing a system that meets their needs.

Technical reviews support continuing communications with the stakeholders, which are essential to developing a concept that reflects their needs within the stakeholders organization and operations.

Trade studies are used for the selection and documented rational of the optimum concept.

Stakeholder involvement is essential to ensure that the system will operate in a way that is useful to them.

Traceabilityof scenarios to user needs, requirements, design, implementation, and verification


Concept of operations describes the operation of the system being developed from the various stakeholder viewpoints. It documents the user’s requirements for ultimate system operations. The users and other stakeholders can review the document and provide feedback and validate these key going-in assumptions.

Process Activities:

Define project vision, goals, and objectives

Revisit the vision, goals, and objectives identified in Concept Exploration & Benefits Analysis [Ch. 3.3.2]. Expand and elaborate on them to capture multiple viewpoints.

Explore project concepts

Revisit the alternative concepts identified during Concept Exploration & Benefits Analysis [Ch. 3.3.2]. The goal is to glean just enough of a physical description of the system from the high-level system architecture to write the Concept of Operations. Perform additional trade studies as needed.

Develop operational scenarios

Operational scenarios describe how the system will be operated under various conditions. For example, incident management scenarios will include normal monitoring, the sequence of events following an incident, and response to failure [e.g., sensors or communications]. These scenarios will describe the activities from the viewpoint of each of the participants. Some techniques for describing the scenarios are flow diagrams and use cases, which are part of the unified modeling language used for software development.

Develop and document the concept of operations

The Concept of Operations is a document that records these findings and system characteristics from each of the multiple viewpoints of the various stakeholders. It is written in a language that they each understand. This document includes such information as vision, goals and objectives, operational philosophies, operational environment, support environment, operational scenarios, operational system characteristics, system constraints & limitations, institutional issues, external interfaces, stakeholder functions, roles & responsibilities, and capabilities.

Illustrates where the Concept of Operations is developed in the Vee Development Model. The Concept of Operations is used in the Concept of Operations section of the Vee Development Model.  The Concept of Operations are updated if necessary in the System Requirements section.

Where does the Concept of Operations take place in the project timeline?

Is there policy or standard that talks about the Concept of Operations?

The FHWA Final Rule requires participating agency roles and responsibilities to be identified in the systems engineering analysis for ITS projects funded from the Highway Trust Fund, including the Mass Transit Account.

For further description of the Concept of Operations, see IEEE Standard P1362 V3.2, http://www.ieee.org and ANSI/AIAA G-043-1992 Guide for the Preparation of Operational Concept Documents, http://global.ihs.com .

Which activities are critical for the system’s owner to do?

  • Discuss visions, goals, needs, expectations, practices & procedures, normal activities, constraints, environment, and other inputs to the Concept of Operations
  • Identify stakeholders
  • Review the developing Concept of Operations
  • Review and approve the final Concept of Operations

How do I fit these activities to my project? [Tailoring]

The level of each activity should be scaled to the size of the project. For example, a small project may have a Concept of Operations that is only a couple of pages long. The emphasis on concept exploration depends more on the newness of the project than on its size. For example, if the system will be automating activities that were formerly manual, or integrating formerly independent activities, it is a good idea to look at alternative ways for structuring the system. This will be useful for allowing the stakeholders to envision using the new system. Whenever formerly independent activities are merged, it is essential to carefully spell out the new operational responsibilities of each agency.

What should I track in this process step to reduce project risks and get what is expected? [Metrics]

On the technical side:

  • The number of operational changes the new system will require, since they introduce institutional, operational, and acceptance risks
  • The number of interfaces between formerly independent systems, since they introduce institutional, operational, and technical risks

On the project management side:

  • The number of stakeholder groups who have reviewed and approved the concept of operations

Checklist: Are all the bases covered?

check Is the Concept of Operations documented in an easily understood manner?
check Are the operations described from the viewpoints of all key stakeholders?
check Are both normal and failure operational scenarios included?
check Does the Concept of Operations cover the key information?
check Has an identification of stakeholders and their responsibilities been made?
check Are goals, objectives, and vision evident?
check Are both constraints and metrics in the system?
check Does the system include external interfaces?
check Are both operational and support environment included?
check Does evidence exist for alternative concepts and rationale for the selection process?
check Does the process include operational scenarios?
check Has the Concept of Operations been reviewed and accepted by the stakeholders?

Are there any recommendations that can help?

Requirement.The Concept of Operations has applicability beyond this phase in the development.

Since the Concept of Operation describes how the system is expected to operate in its intended environment, it can be used to support the validation of the system, training, and users & maintenance manuals.

Caution.There is a temptation at this point to make assumptions about system design. The Concept of Operations should address what is to be done, but not how it will be implemented. That will be determined later during design.

A closer look at scenarios – scenarios are an important part of the Concept of Operations. They should include, at a minimum:

  • What is to be done?
  • Who will do it?
  • What is communicated? To whom?

This could be a flowchart or text. It must be something easily understandable by the stakeholders. A simple way to do this is to write the scenario from the viewpoints of each of the stakeholders involved. Some other techniques that one may see used in concepts of operation are use cases, thread analysis, and flow analysis.

Here is a simple example of a text scenario for a transit system from the view of the dispatcher. There will be corresponding scenarios for the driver, maintenance, and the bus yard.

  • Scenario: Bus breakdown
  • Viewpoint: Dispatcher
  • Receive notification of breakdown from the driver.
  • Locate bus.
  • Request repairs from maintenance department.
  • Request replacement bus from the bus yard.
  • Confirm actions complete.

Notice that this scenario does not specify how these steps will be completed

This scenario is short and easy to present to the stakeholders. Their feedback at this point will prevent re-design later. For example, the maintenance department may say that they always contact the yard when they are called for a breakdown. So the dispatcher does not need to do that. A manager may point out that they need to have the actions logged. These changes are easy to make now.

Multiple viewpoints The most important purpose of the Concept of Operation is to get agreement from the stakeholders on:

  • their responsibilities
  • how the system will operate
  • the environment
  • system expectations
  • processes that the system will support

This is best accomplished by presenting the information from the viewpoint of each of the stakeholders. Then, they can readily review and respond to it. Be sure that the document addresses the system from the viewpoint of the operator, user, owner, developer, maintenance, and management. It should answer the "five Ws and an H" that reporters are supposed to address in their writing: who, what, when, where, why, and how.

The environment in which the system will operate arguably has as much influence on system performance as does the system itself. This includes not only the physical environment, but also the political, procedural, operational, and any other factors which either support or constrain system operation.

The following considerations circumscribe the system to be developed and should be addressed in the Concept of Operations:

  • Mission objectives and rationale
  • Operational philosophies
  • Operational system characteristics
  • System constraints and limitations
  • Relevant stakeholders organizations and policies
  • External interfaces and requirements

The system is surrounded by its operational and support environments. The operational environment describes the conditions under which the system will be used. For example, will the operators be doing other tasks while operating the system? The support environment includes such things as maintenance, disposal, facilities, and utilities.

Related Template Checklist  


Page last modified on September 20, 2016
Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000