![](media/image1.jpeg){width="8.516666666666667in" height="11.1375in"}

**Form DOT F 1700.7 (8-72)**

+-----------------+---+----------+--------+-------------+--------------+
| 1\. Report No.  | 2 |          |        | 3\.         |              |
|                 | \ |          |        | Recipient's |              |
| FHWA-HOP-07-003 | . |          |        | Catalog No. |              |
|                 | G |          |        |             |              |
|                 | o |          |        |             |              |
|                 | v |          |        |             |              |
|                 | e |          |        |             |              |
|                 | r |          |        |             |              |
|                 | n |          |        |             |              |
|                 | m |          |        |             |              |
|                 | e |          |        |             |              |
|                 | n |          |        |             |              |
|                 | t |          |        |             |              |
|                 | A |          |        |             |              |
|                 | c |          |        |             |              |
|                 | c |          |        |             |              |
|                 | e |          |        |             |              |
|                 | s |          |        |             |              |
|                 | s |          |        |             |              |
|                 | i |          |        |             |              |
|                 | o |          |        |             |              |
|                 | n |          |        |             |              |
|                 | N |          |        |             |              |
|                 | o |          |        |             |              |
|                 | . |          |        |             |              |
+-----------------+---+----------+--------+-------------+--------------+
| 4\. Title and   |   |          |        | 5\. Report  |              |
| Subtitle        |   |          |        | Date        |              |
|                 |   |          |        |             |              |
| Developing and  |   |          |        | September   |              |
| Using a Concept |   |          |        | 2005        |              |
| of Operations   |   |          |        |             |              |
| in              |   |          |        |             |              |
| Transportation  |   |          |        |             |              |
| Management      |   |          |        |             |              |
| Systems: A      |   |          |        |             |              |
| Primer          |   |          |        |             |              |
+-----------------+---+----------+--------+-------------+--------------+
|                 |   |          |        | 6\.         |              |
|                 |   |          |        | Performing  |              |
|                 |   |          |        | O           |              |
|                 |   |          |        | rganization |              |
|                 |   |          |        | Code:       |              |
+-----------------+---+----------+--------+-------------+--------------+
| 7\. Author(s)   |   |          |        | 8\.         |              |
|                 |   |          |        | Performing  |              |
| B. Smith (U.    |   |          |        | O           |              |
| Va), R. Barnes  |   |          |        | rganization |              |
| (SAIC)          |   |          |        | Report No.  |              |
+-----------------+---+----------+--------+-------------+--------------+
| 9\. Performing  |   |          |        | 10\. Work   |              |
| Organization    |   |          |        | Unit No.    |              |
| Name and        |   |          |        | (TRAIS)     |              |
| Address         |   |          |        |             |              |
|                 |   |          |        |             |              |
| Science         |   |          |        |             |              |
| Applications    |   |          |        |             |              |
| International   |   |          |        |             |              |
| Corporation     |   |          |        |             |              |
| (SAIC)          |   |          |        |             |              |
|                 |   |          |        |             |              |
| 1710 SAIC       |   |          |        |             |              |
| Drive, M/S      |   |          |        |             |              |
| T1-12-3         |   |          |        |             |              |
|                 |   |          |        |             |              |
| McLean, VA      |   |          |        |             |              |
| 22102           |   |          |        |             |              |
|                 |   |          |        |             |              |
| University of   |   |          |        |             |              |
| Virginia        |   |          |        |             |              |
|                 |   |          |        |             |              |
| Department of   |   |          |        |             |              |
| Civil           |   |          |        |             |              |
| Engineering     |   |          |        |             |              |
|                 |   |          |        |             |              |
| P.O. Box 400742 |   |          |        |             |              |
|                 |   |          |        |             |              |
| C               |   |          |        |             |              |
| harlottesville, |   |          |        |             |              |
| VA 22904-4742   |   |          |        |             |              |
+-----------------+---+----------+--------+-------------+--------------+
|                 |   |          |        | **11.       |              |
|                 |   |          |        | Contract or |              |
|                 |   |          |        | Grant No.** |              |
|                 |   |          |        |             |              |
|                 |   |          |        | DTFH61      |              |
|                 |   |          |        | -01-C-00180 |              |
+-----------------+---+----------+--------+-------------+--------------+
| 12\. Sponsoring |   |          |        | 13\. Type   | 14\.         |
| Agency Name and |   |          |        | of Report   | Sponsoring   |
| Address         |   |          |        | and Period  | Agency Code  |
|                 |   |          |        | Covered     |              |
| Operations      |   |          |        |             |              |
| Office of       |   |          |        | Primer      |              |
| Transportation  |   |          |        |             |              |
| Management      |   |          |        |             |              |
|                 |   |          |        |             |              |
| Federal Highway |   |          |        |             |              |
| Administration  |   |          |        |             |              |
|                 |   |          |        |             |              |
| 400 Seventh     |   |          |        |             |              |
| St., SW         |   |          |        |             |              |
|                 |   |          |        |             |              |
| Washington, DC  |   |          |        |             |              |
| 20590           |   |          |        |             |              |
+-----------------+---+----------+--------+-------------+--------------+
| 15\.            |   |          |        |             |              |
| Supplementary   |   |          |        |             |              |
| Notes           |   |          |        |             |              |
|                 |   |          |        |             |              |
| Emiliano Lopez  |   |          |        |             |              |
| (COTM)          |   |          |        |             |              |
+-----------------+---+----------+--------+-------------+--------------+
| 16\. Abstract   |   |          |        |             |              |
|                 |   |          |        |             |              |
| This document   |   |          |        |             |              |
| provides        |   |          |        |             |              |
| guidance to     |   |          |        |             |              |
| transportation  |   |          |        |             |              |
| professionals   |   |          |        |             |              |
| as they seek to |   |          |        |             |              |
| develop and use |   |          |        |             |              |
| the Concept of  |   |          |        |             |              |
| Operations      |   |          |        |             |              |
| throughout the  |   |          |        |             |              |
| life cycle of a |   |          |        |             |              |
| Transportation  |   |          |        |             |              |
| Management      |   |          |        |             |              |
| System (TMS).   |   |          |        |             |              |
| It is designed  |   |          |        |             |              |
| to provide the  |   |          |        |             |              |
| reader with     |   |          |        |             |              |
| insight into a  |   |          |        |             |              |
| TMS-focused     |   |          |        |             |              |
| Concept of      |   |          |        |             |              |
| Operations      |   |          |        |             |              |
| document.       |   |          |        |             |              |
+-----------------+---+----------+--------+-------------+--------------+
| 17\. Key Words  |   |          |        | 18\.        |              |
|                 |   |          |        | D           |              |
| concept of      |   |          |        | istribution |              |
| operations,     |   |          |        | Statement   |              |
| transportation  |   |          |        |             |              |
| management      |   |          |        | No          |              |
| system,         |   |          |        | re          |              |
| business        |   |          |        | strictions. |              |
| planning        |   |          |        | This        |              |
| documents,      |   |          |        | document is |              |
| systems         |   |          |        | available   |              |
| engineering     |   |          |        | to the      |              |
| standards       |   |          |        | public      |              |
|                 |   |          |        | through the |              |
|                 |   |          |        | National    |              |
|                 |   |          |        | Technical   |              |
|                 |   |          |        | Information |              |
|                 |   |          |        | Service,    |              |
|                 |   |          |        | S           |              |
|                 |   |          |        | pringfield, |              |
|                 |   |          |        | VA 22161.   |              |
+-----------------+---+----------+--------+-------------+--------------+
| 19\. Security   |   | 20\.     |        | 21\. No of  | 22\. Price   |
| Classif.        |   | Security |        | Pages       |              |
|                 |   | Classif. |        |             | N/A          |
| (of this        |   |          |        | 15          |              |
| report)         |   | (of this |        |             |              |
|                 |   | page)    |        |             |              |
| Unclassified    |   |          |        |             |              |
|                 |   | Uncl     |        |             |              |
|                 |   | assified |        |             |              |
+-----------------+---+----------+--------+-------------+--------------+
| **Form DOT F    |   |          | **     |             |              |
| 1700.7 (8-72)** |   |          | Reprod |             |              |
|                 |   |          | uction |             |              |
|                 |   |          | of     |             |              |
|                 |   |          | com    |             |              |
|                 |   |          | pleted |             |              |
|                 |   |          | page   |             |              |
|                 |   |          | author |             |              |
|                 |   |          | ized** |             |              |
+-----------------+---+----------+--------+-------------+--------------+

**Table of Contents**

[1. Introduction 1](#introduction)

[Objective and Audience 1](#objective-and-audience)

[2. The Concept of Operations Defined
2](#the-concept-of-operations-defined)

[Why Use a Concept of Operations? 3](#why-use-a-concept-of-operations)

[What are the Elements of a Concept of Operations?
4](#what-are-the-elements-of-a-concept-of-operations)

[What are the Major Goals of the Concept of Operations?
8](#what-are-the-major-goals-of-the-concept-of-operations)

[Examples of Concepts of Operations for Different Types of Systems
9](#examples-of-concepts-of-operations-for-different-types-of-systems)

[3. Developing a Concept of Operations
9](#developing-a-concept-of-operations)

[Requirements for Technical Expertise
9](#requirements-for-technical-expertise)

[The Need for a Team Effort 9](#the-need-for-a-team-effort)

[A Purpose-Driven Scope 10](#a-purpose-driven-scope)

[Resources Required for Concept of Operations Development
10](#resources-required-for-concept-of-operations-development)

[Stakeholder Identification and Involvement
11](#stakeholder-identification-and-involvement)

[Defining Performance Measures 12](#defining-performance-measures)

[4. The Concept of Operations and Systems Engineering
12](#the-concept-of-operations-and-systems-engineering)

[The Systems Engineering Life Cycle and the Systems Engineering "V"
12](#the-systems-engineering-life-cycle-and-the-systems-engineering-v)

[5. Transition from a Concept of Operations to System Requirements
13](#transition-from-a-concept-of-operations-to-system-requirements)

[6. Additional Resources 14](#additional-resources)

#  {#section .unnumbered}

# 1. Introduction

## Objective and Audience

The objective of this document is to provide guidance to transportation
professionals as they seek to develop and use the Concept of Operations
throughout the life cycle of a Transportation Management System (TMS).
For the purposes of this document, a *TMS is defined as* *any complex,
integrated software/hardware project with a large number of inputs and
outputs whose goal is to manage the large-scale movement of people and
goods safely, efficiently, and effectively*.

This document is designed to provide the reader with insight into a
TMS-focused Concept of Operations document. As such, it offers:

-   *Guidance on developing the Concept of Operations*, including what
    information to include, how to begin the development process,
    stakeholder identification and involvement in the process, and
    identifying resources that will facilitate the development process.

-   *Guidance on using Concepts of Operations*, including highlights of
    the entire systems engineering life cycle and presentation of a
    variety of stakeholder vantage points.

-   *Specific examples of good practice from transportation agencies*,
    including testimonials, experiences and guidance from transportation
    professionals as well as from their Concept of Operations documents.

```{=html}
<!-- -->
```
-   *Guidance on tailoring the Concept of Operations to a specific
    system for successful development*, since there are no "cookbooks"
    (i.e., multi-step processes) for developing/using Concepts of
    Operations.

This primer is written for transportation professionals involved in the
planning, development, design, operations, and maintenance of TMSs.
However, the document is relevant to a wide audience with relatively
little TMS experience since it is intended to communicate essential
information about a TMS to a high-level audience.

The following common "classes" of TMS professional will find the
guidance document useful for the following reasons:

-   *Management* -- Transportation managerial professionals operating
    either within or in conjunction with a TMS will find that this
    document reiterates the necessity of system stakeholder
    communication. A Concept of Operations is a critical foundation for
    such communication.

-   *Technical staff* -- Professionals working within a TMS that deal
    with all aspects of the system's operation, including but not
    limited to design engineers, integration and test engineers,
    operators of the various system functions, and maintenance staff,
    will find that this document demonstrates how a Concept of
    Operations helps to clarify agency goals and objectives.

-   *Support engineering firms* -- Any members of a contracted firm that
    work within or in conjunction with the TMS, performing work that
    includes repairs and maintenance, system support services, etc.,
    will find that this document shows how a Concept of Operations
    assures that the 'client' has communicated, at the highest possible
    level, what they want the system to be -- adding clarity and helping
    to avoid scope creep for all parties.

But this document is not just aimed at transportation professionals. It
is also written for non-technical community leaders, local officials,
and others who have an interest in transportation issues and who may
influence resource allocation decisions. Such individuals may have as
much input, if not more, in some cases, into transportation system
development decisions as transportation professionals themselves.

This document will also present information on the development of
Concept of Operations for TMSs with the understanding that not all of
the individuals or groups reviewing this document will be at the same
point operationally or developmentally. As such, consideration will be
given to those organizations, agencies and individuals who:

-   *Are new to a Concept of Operations*.

-   *Have limited experience with a Concept of Operations.*

-   *Are seeking to develop and use a Concept of Operations for an
    existing system*.

# 2. The Concept of Operations Defined

*A Concept of Operations is defined as a high-level description of what
the major system capabilities will be -- it attempts to answer the who,
what, when, where, why, and how questions for new systems in general
terms.* Figure 1 provides a conceptual representation of the overarching
structure that, once fleshed out, becomes a Concept of Operations.

![](media/image2.wmf)

-   What -- What are the known elements and the high-level capabilities
    of the system?

-   Where -- What are the geographical and physical extents of the
    system?

-   When -- What is the time-sequence of activities that will be
    performed?

-   How -- What resources do we need to design, build, or retrofit the
    system?

-   Who -- Who are the stakeholders involved with the system?

-   Why -- What does your organization lack that the system will
    provide?

The Concept of Operations is the key transition point leading to
development of Requirements, a document which the Concept of Operations
informs and shapes.

The Concept of Operations should be a document that is available and
relevant to all stakeholders in the system, no matter what their
background or role within the system. In the context of a TMS, it should
be as readable and relevant to high-level decision makers and community
leaders as it is to the TMS manager, the TMS operator, and other
transportation professionals.

The Concept of Operations is not a requirements document that lists the
thousands of low-level capabilities of the system. It should not contain
information on the specifics of systems design that will make this
functionality possible, but rather lay out all the things the system
should be able to do. The ideal case is that all those people who have
any stake in the system (including end users, all organizations who are
sharing information, system developers, management, etc.) are able to
understand the basic idea of the system and be able to discuss the
system in terms of what it does.

A Concept of Operations may not be called by this name. In many cases,
the elements of a Concept of Operations are scattered through various
related documents -- such as a system's Business Plan, Requirements,
etc. However, if the core elements of a Concept of Operations, as
outlined within this document, are found within a document such as the
Business Plan, then it can be considered to be a Concept of Operations.
Nonetheless, it is often the case that existing systems do not have one
document containing all of the core elements that will be outlined.

## Why Use a Concept of Operations?

There are a variety of benefits that can accrue to an organization or
group of organizations from developing a Concept of Operations. The
primary motivations for moving forward with the development of such a
document include the following:

-   The identification of system stakeholders and the assurance that
    they will communicate in a common forum.

-   The formulation and documentation of a high-level system definition.

-   The foundation for all lower-level sub-system descriptions.

-   The definition of all major user groups and activities.

-   The identification of the environment in which the system will
    function.

An overwhelming majority of transportation professionals interviewed for
*Developing and Using a Concept of Operations in Transportation
Management Systems*, the companion report for this primer,[^1] mentioned
*stakeholder agreement* on interrelationships, information sharing, and
roles and responsibilities for the system as the most important benefit
of the Concept of Operations development process. A testimonial from one
transportation professional identified the principal benefits as being
creation of a consensus on the priority of needs for the organization, a
bridging of the gap between the technical and operational sides of the
organization, and establishment of continuity throughout the ebb and
flow of economic and political fluctuations.

An additional benefit that accrues from stakeholder consensus is a
*decreased risk of project failure*. The experiences of transportation
professionals have shown that developing a Concept of Operations
significantly increases the chance for success on the project. The
stakeholder consensus integral to the Concept of Operations development
process not only builds a unified vision and understanding of a new
system, but also contributes to reductions in cost overruns, a more
accurate definition of the system earlier in the development stage, and
a decrease in the likelihood that stakeholder dissatisfaction will
terminate the project. One transportation professional said of the
Concept of Operations for a Transportation Management System that it is
"not a silver bullet \[i.e., not a cure-all to the problems of
developing and maintaining a TMS\], but it does decrease the likelihood
of failure for a project."

## What are the Elements of a Concept of Operations?

The ANSI Concept of Operations standard (ANSI/AIAA G-043-1992) provides
an excellent format for developing a Concept of Operations Document for
any highly complex system. In essence, ANSI recommends that a Concept of
Operations Document "...describes system characteristics from an
operational perspective," and, for each stakeholder, answers the
question "What does it \[the system\] look like from my point of view?"
The standard is summarized in the diagram in Figure 2, and its elements
are addressed below.

![](media/image3.png){width="5.7555555555555555in"
height="3.6993055555555556in"}

It is important to note that all Concept of Operations documents will
not be the same since they are all tailored to support the development
and use of a specific system or set of services. The critical function
of the Concept of Operations is to encourage careful consideration of
the system by multiple stakeholders at the outset of a system
development process and to document agreed-upon descriptions. The
formality of the section titles is not necessary, and it is apparent
when looking at the current state-of-the-practice for Concept of
Operations development that each organization will arrange information
in a way that best fits its individual system.

1.  **Scope** -- This section presents an overview of the entire Concept
    of Operations, including the following elements:

    -   Outline of the Contents of the Document.

    -   Purpose for Implementing the System.

    -   Highlight Major Objectives and Goals.

    -   Identify the Intended Audience.

    -   Set Boundaries on the Scope of the System.

    -   Describe an Overarching Vision for the System.

+-----------------------------------------------------------------------+
| **Example**[^2] --- *Fontana/Ontario, a joint TMC project for the     |
| I-10 corridor between Fontana and Ontario in Southern California,     |
| includes in its Concept of Operations an introduction section, which, |
| among other details, lists the major organizations that will be       |
| included in the integrated operation. This introduction clearly sets  |
| the boundary of the system and states high-level goals for the        |
| project:*                                                             |
|                                                                       |
| 2 Introduction                                                        |
|                                                                       |
| 2.1 Document Organization                                             |
|                                                                       |
| This document sets forth the Concept of Operations for the            |
| Fontana/Ontario Advanced Traffic Management and Information System    |
| (ATMIS). The document will provide the reader the following           |
| information:                                                          |
|                                                                       |
| -   Identification of the issues and problems to be resolved.         |
|                                                                       |
| -   The agency needs to operate and manage the proposed solution.     |
|                                                                       |
| -   Operational and use perspectives to define the use and intent of  |
|     the ATMIS.                                                        |
|                                                                       |
| This document flows from the Inventory / Needs Document and forms the |
| basis for the System Requirements Document...                         |
|                                                                       |
| 3 Fontana / Ontario ATMIS...                                          |
|                                                                       |
| 3.2 System Overview / Purpose of Project                              |
|                                                                       |
| Funded by a Federal ITS grant and local resources, the                |
| Fontana/Ontario ATMIS will be one of several ITS projects in the      |
| Southern California ITS Priority Corridor. The project is being       |
| implemented as a joint venture between Caltrans District 8 (D8) and   |
| the cities of Fontana and Ontario. ...\[T\]he system encompasses      |
| several major event generators - among them, Ontario Mills Mall,      |
| Ontario Convention Center, Ontario Airport, California Speedway, and  |
| commercial transportation from manufacturing facilities adjacent to   |
| the California Speedway.                                              |
|                                                                       |
| The ATMIS will provide for integration of freeway and surface street  |
| operations, and will become the foundation of a "Smart Corridor"      |
| along the I-10. With multiple parallel alternatives (both freeway and |
| arterial), ATMIS will facilitate the coordination of traffic          |
| management activities on both the freeway network and the local       |
| arterials.                                                            |
+-----------------------------------------------------------------------+

2.  **Referenced Documents** -- In this section, authors of the Concept
    of Operations list the resources used when developing the document.
    This both clarifies the sources of information that went into the
    document and provides the reader with guidance to find additional
    information. Types of reference documents that are typically listed
    include:

    -   Business Planning Documents.

    -   Concept of Operations for related systems.

    -   Requirements for related systems.

    -   Studies to Identify Operational Needs.

    -   System Development Meeting Minutes.

3.  **User-Oriented Operational Description** -- This section of the
    document describes the system from a user vantage point. It
    identifies how organization/system-specific goals and objectives are
    accomplished, including strategies, tactics, policies, and
    constraints. This portion of the Concept of Operations should be the
    main focus for the entire document. Its purpose is to outline the
    system and provide a clear working image of how each party should
    expect to integrate itself within the overall system. Information
    that should be highlighted in this section includes:

    -   User Activities.

    -   Order of User Operations.

    -   Operational Process Procedures.

    -   Organizational/Personnel Structures.

4.  **Operational Needs** -- This section details agency- and
    region-specific goals and objectives that will drive the
    requirements for the system. In other words, the section addresses
    the question of what is necessary to the agency or region that the
    current system or set of services does not provide.

5.  **System Overview** --This section provides a high-level description
    of the interrelationships of key system components. (Figure 3) The
    areas this section should address include:

    -   Scope.

    -   Interfaces.

    -   System Capabilities (Functions).

    -   Goals and Objectives

6.  **The Operational and Support Environments** -- Although the
    ANSI/AIAA standard describes two sections, there is considerable
    overlap between them. Therefore, it is recommended that the sections
    be combined to provide information about the general operational
    environment for operation of the new system (or created by the
    change in the current system). This section includes the following
    environmental characteristics:

    -   Facilities.

    -   Equipment.

    -   Hardware.

    -   Software.

    -   Personnel.

        ![](media/image4.wmf){width="5.345833333333333in"
        height="3.8756944444444446in"}

    -   Operational Procedures.

    -   Support Necessary to Operate the Deployed System.

> Ideally, a description of the operational and supporting environment
> should make a clear connection between functional, physical, and
> logical viewpoints.

7.  **Operational Scenarios** -- In this section of the Concept of
    Operations, the authors place themselves in the users' position and
    detail how the new system would impact their activities under
    various conditions ranging from normal to stress and failure
    conditions. There are four basic elements to consider in operational
    scenario development:

    -   Included Users' Perspectives.

    -   Variety of User Classes.

    -   Stress/Failure Scenarios.

    -   Multiple Circumstances.

+-----------------------------------------------------------------------+
| **Example** --- *Fontana/Ontario Concept of Operations*[^3] *gives    |
| different user perspectives for several different scenarios, which    |
| are listed below:*                                                    |
|                                                                       |
| -   Fontana TMC Operator                                              |
|                                                                       |
| -   Fontana Maintenance Operator                                      |
|                                                                       |
| -   Fontana Engineering                                               |
|                                                                       |
| -   Police Department: Caltrans District 8 Operator                   |
|                                                                       |
| -   Caltrans District 8 Signal Engineer                               |
|                                                                       |
| -   Major Event Generator                                             |
|                                                                       |
| -   Traveling Public                                                  |
|                                                                       |
| -   Ontario International Airport                                     |
|                                                                       |
| The following is an excerpt from the Fontana TMC Operator Perspective |
| which concerns operator "Joe":                                        |
|                                                                       |
| > Alerted by the sudden decrease in vehicle speeds along Sierra, Joe  |
| > selects the video images from Sierra and Randall. Joe notices that  |
| > the north bound lanes on Sierra are backing up due to a stalled car |
| > on the outside lane. The problem is exacerbated by the fact that    |
| > there is a construction crew working next to the car on the inside  |
| > lane. Upon further review he notices the construction crew          |
| > assisting the driver out of his car and onto the street. He         |
| > switches the image to the large screen display -- it looks like a   |
| > medical emergency.                                                  |
| >                                                                     |
| > Joe logs the incident using the ATMIS 'Incident Management          |
| > Dialogue' window. He enters information about the incident -        |
| > reporting agency, contact name, phone, incident location, phone     |
| > number, lanes affected, place on map, description, notification     |
| > list, traffic management plan and alternate routes. The incident    |
| > report is immediately transmitted to the Fontana PD CAD system      |
| > alerting operators who can react by dispatching police and          |
| > emergency services. Additionally, Joe updates local dynamic message |
| > signs (already in use for the construction activity) to warn        |
| > oncoming traffic of the incident and provide alternate routes.      |
+-----------------------------------------------------------------------+

## What are the Major Goals of the Concept of Operations?

In order to understand a concept of operations, it is essential to
comprehend its goals. Key goals of a concept of operations are as
follows:

-   *Stakeholder Identification and Communication.* A major goal of the
    document is to facilitate discussion and eventually find common
    ground among the relevant groups associated with system design,
    development, and operation.

-   *High-level System Definition.* All stakeholders should be able to
    understand, what the system is being designed to do, including the
    flows of information among major system entities, the information
    flow to external entities, high-level capabilities, and the main
    daily operational occurrences..

-   *Foundation for Lower-level System Description.* Although the
    Concept of Operations is not a requirements document itself, a
    well-formed Concept of Operations will be a source of information
    that can be decomposed into a first cut of high-level functional
    requirements.

-   *Definition of Major User Classes and User Activities*. All
    stakeholders should be aware of the different types of users of the
    system and activities those users will perform, allowing everyone
    who uses the document to get an idea of who is performing what
    activity, and which high-level capability that activity is
    supporting.

## Examples of Concepts of Operations for Different Types of Systems

A Concept of Operations should be developed for any system-level
initiative in a TMS. These initiatives may be developing a new traffic
control center/system, integrating multiple systems in a region, adding
a service to an existing system, etc. This section briefly discusses
expected differences in Concepts of Operation for different classes of
TMS initiatives.

**Stand-Alone Centers ---** Transportation Management Centers that have
a contained scope of one agency/jurisdiction can approach the Concept of
Operations straightforwardly. The Texas DOT TMC Advanced Traffic
Management System ATMS for Austin is an example of a 'stand-alone'
center whose Concept, while focused on one activity/ system, relates
very well to the core elements.

**Integration Programs** --- iFlorida represents a statewide
transportation integration effort, and the Concept of Operations
document is adjusted to fit that level of operation. The iFlorida
Concept of Operations is divided into various sections from which the
statewide integration project will be built. Each "Procurement" of the
project describes all the elements listed for each section of the
integration, thereby conveying all the information for the core elements
of a Concept of Operations on a section-by-section basis.

**Existing Systems** ---There are several reasons for developing a
Concept of Operations after systems development has already begun -
including adding functionality to an existing system or addressing
groups of stakeholders with jurisdictional concerns. The Virginia
Department of Transportation's Hampton Roads Smart Traffic Center, a
regional TMC, is such an example. The Center has existed for several
years with little change in overall mission, stakeholders, users, etc.
However, with the addition of new functionality to the TMC's
capabilities, an entirely new group of stakeholders, system connections,
and information analysis capabilities have been integrated, resulting in
the need for a thorough review of the TMC's original concept. The Center
is now in the process of developing an entirely new Concept of
Operations.

# 3. Developing a Concept of Operations

## Requirements for Technical Expertise

The Concept of Operations document is intended to have a wide audience.
As such, its writing must balance generality with specificity: it must
be general enough for individuals or stakeholders with limited system
knowledge to understand the overall system, yet detailed enough that
in-system technical stakeholders are able to glean a depth of
understanding that will enable them to transition from step-to-step
within the systems engineering process to build or refine the system.

This writing balance is often best assured by creating a writing team
that contains members with a broad set of backgrounds and that
encompasses the core of the stakeholder group. The leaders of this group
should be the individuals who will be responsible for operating the
system. So, while technical expertise is necessary for the development
of the Concept of Operations, it is not a required qualification for
those who will actually write a Concept of Operations document.

## The Need for a Team Effort

An effective concept of operations depends on a solid team compiled to
create and use the document. The following guidance may be useful in
this effort:

-   *Begin compiling the team immediately* --The process to build the
    Concept of Operations document is iterative. It involves the core
    group whose goal is to define an idea, bring in additional
    stakeholders for their review and consideration, and then refine the
    idea further. The core stakeholders and the core idea will come into
    balance in time, and finding individuals who have the time and
    interest in developing the concept is critical in the earliest
    stages.

-   *Focus on those who will be responsible for using the system* --The
    expansive, reiterative process involved in idea/concept development
    should involve all stakeholders, but the writing should involve only
    a core group containing the immediate users rather than peripheral
    stakeholders, who may attempt to redirect the effort toward their
    more critical, but less pertinent, needs.

## A Purpose-Driven Scope

A Concept of Operations may be developed for many different classes of
systems initiatives.

-   *New center* -- Although it may be perceived that a new TMS without
    the influence of any existing system will be easier to develop, this
    is not always true. The challenge lies in the preparatory phases:
    identifying system boundaries, identifying stakeholders, determining
    what the system should do, etc.

-   *Regional integration program* -- Such TMSs must integrate systems
    representing both similar and different technologies, organizations,
    and missions. Here, the Concept of Operations generates a new,
    overarching mission demonstrating how a regional, systemic need can
    only be met by integrating some or all aspects of existing regional
    TMSs.

-   *Adding/modifying functionality to an existing system* --It is
    generally considered a good idea to rewrite a Concept of Operations
    document when substantial new functionality is added to the system
    resulting from a change to the nature of the mission, when
    significant new capabilities are added, or when new stakeholder
    groups arise whose needs require integration.

## Resources Required for Concept of Operations Development

The resources necessary to develop a Concept of Operations will vary
greatly from system to system depending on institutional issues and the
size and scope of the system in question. However, there are a few
issues to consider:

-   *Owning agency leadership* -- First and foremost, it will be well
    understood that without leadership from the owning agency, moving
    forward with a Concept of Operations, or with any system, would
    substantially increase the likelihood of project failure.

-   *Logistics of a major development* -- Undertaking a new system
    involves a tremendous logistical effort; therefore, the owning
    organization should seek out experienced professionals, such as
    consultants, to take on the associated tasks.

-   *Appropriate Concept of Operations drivers* -- Technical system
    operators should not be selected to lead the Concept of Operations
    development. Such individuals' perspectives may be too narrow to
    facilitate good overall system design.

-   *Staffing, duration, and funding* -- Information gathered from
    surveys and interviews suggests that the average development team
    for a Concept of Operations consists of 2 to 4 people who typically
    do not work exclusively on the Concept of Operations effort. The
    development processes experienced ranged from 2 months to 6 months,
    and project budgets varied from \$10,000 to \$400,000, depending on
    the size, scope, and number of participants in the effort.

## Stakeholder Identification and Involvement

The ANSI/AIAA standard explains the purpose of a Concept of Operations
as being to afford better understanding of the system at hand for a wide
variety of key players. Many stakeholder groups are readily apparent in
the early stages of system development, but others are identified later
in the process as system definition and scope become more detailed. It
is advisable to separate stakeholders into internal groups and external
groups. Attributes of each class are described in Table 1.

+--------------------------------+-------------------------------------+
| Table 1: Highlights of the     |                                     |
| Different Attributes of        |                                     |
| Internal and External          |                                     |
| Stakeholders                   |                                     |
+--------------------------------+-------------------------------------+
| **Internal Stakeholders**      | **External Stakeholders**           |
+--------------------------------+-------------------------------------+
| -   **Within in the primary    | -   **Interact with the system but  |
|     organization(s) that is    |     are outside the scope of the    |
|     developing or operates the |     system**                        |
|     system**                   |                                     |
|                                | -   **Play a secondary role in      |
| -   **Play a significant role  |     system function or are only     |
|     in system function**       |     affected by system function**   |
|                                |                                     |
| -   **Are significantly        |                                     |
|     affected by changes in     |                                     |
|     system design and          |                                     |
|     function**                 |                                     |
+--------------------------------+-------------------------------------+

It is impossible to create a list that will include every possible
stakeholder for every TMS, but there are key classes of stakeholders
that will be present in most, if not all, TMSs. The categories of
stakeholders listed in the ANSI standard include:

-   *Users*---any individual, organization, or system that interacts
    with the system.

-   *Operators*--- staff members who actively manage the system.

-   *Maintainers*---staff who deal with system upkeep including
    software, hardware, sources for collecting information, and data
    storage.

-   *System Engineers and Architects---*staff who design the system from
    the Concept of Operations stage through the system's lifecycle.

-   *System Implementers---*those who perform software coding,
    implementation of data collection sources, integration among various
    sub systems, and other technical development roles.

-   *Customers and Buyers*---any group that is purchasing some aspect of
    the system from organizations or contractors who exist outside the
    scope of the system

-   *Testers---*staff who test all aspects of the system from the
    component level of software development to testing the completed,
    working system for user acceptance.

-   *Customer and Developer Organization Management---* managerial-level
    members of the organizations involved in the development or
    operation of the system.

Active participation among stakeholders is essential for successfully
developing a concept of operations. Advice obtained from transportation
professionals overwhelmingly concludes that stakeholder involvement is
necessary, and that the sooner stakeholders become involved, the better.

Interview information suggests that it is essential for each stakeholder
to hold meetings internally to come to a consensus as to that
organization's needs and goals before joining in discussions with all
other stakeholders. If this process is overlooked, stakeholder agreement
can become more difficult than it already is since certain organizations
in the process have not yet identified their own vision, goals, and
desired function for the system.

Research also suggests that problems occur during the development phase
of a project if all stakeholders do not feel that their mission/goals
are being met. Agreement on every aspect of the system is not necessary,
but one TMS professional recollects that the Concept of Operations
"would not have been successful without each organization feeling like
it could meet its goals and objectives."

## Defining Performance Measures

Goals and objectives drive requirements development for the operation of
a system, but measuring how close or how far one is from those goals and
objectives once the system is operational requires some sense of system
performance. By generating initial performance measures in the Concept
of Operations, a foundation for the System Acceptance and System
Validation plans is formed. While the system will be modified and
expectations for the system will change over time, the performance
measures outlined in the Concept of Operations should be both on a high
enough level and flexible enough to allow for some re-interpretation and
new application.

Generally, in TMS, the Concept of Operations developers will need to
consider at least these performance measure focus areas:

-   *Applied System* -- The finished system is intended to improve some
    characteristic of the transportation system, so some quantitative
    method must be used to explain the before and after system states of
    a transportation characteristic, e.g., travel time or travel cost.

-   *Inter/Intra* -- The system will have unique features that may be
    useful in measuring the efficiency of its own operation. An example
    would include system reliability.

-   *Peripheral* -- The system may have associations with other systems,
    technically or organizationally, whose measures may address both
    applied system performance and inter/intra system performance. An
    example may be traveler level of satisfaction with transportation
    services.

# 4. The Concept of Operations and Systems Engineering

*Systems engineering is a method to facilitate the development,
maintenance, refinement, and retirement of dynamic, large-scale systems
of systems comprising both technological components (machines,
information systems, etc.) and human components (users, stakeholders,
etc.)*. Despite the apparent simplicity of the definition of systems
engineering, the methods it utilizes are rich enough to manage the most
sophisticated system application.

## The Systems Engineering Life Cycle and the Systems Engineering "V"

The series of iterative steps identified above is captured in what is
referred to as the Systems Engineering "V." This form places the
relevant procedures in a step-wise, temporally relevant (with time
moving left to right) shape (Figure 5). Developing a Concept of
Operations is a critical first step, setting the stage for the remainder
of the system development process and assisting in continuous validation
of the system once it has become operational.

The Systems Engineering "V" diagram succinctly captures the relationship
that the Concept of Operations maintains with the systems engineering
process. It is clear that the best development practice, one that
assures all goals are achieved, would be to incorporate the Concept of
Operations at every phase of development, keeping both process goals and
stakeholders' needs at the forefront in each step.

![](media/image5.wmf){width="4.559027777777778in"
height="5.120833333333334in"}

# 5. Transition from a Concept of Operations to System Requirements

All of the effort to create a Concept of Operations now gives way to
stating, in detail, what the system must have in order to achieve those
features and characteristics detailed in the Concept of Operations. This
is the job of the System Requirements development team. Figure 6, below,
summarizes the activities that are part of the Concept of Operations
development process and shows the segue into the requirements
development phase.

Generally, any Concept of Operations should have addressed, and included
in some fashion, the integration of the concept, the systems' diagram,
and the commonly accepted stakeholder system objectives, referenced
above as an Objectives Hierarchy. These are the features that will be of
greatest value for the Requirements development team as they commence
their efforts in the next step of the system engineering process.

![](media/image6.png){width="5.169444444444444in"
height="2.377083333333333in"}

# 6. Additional Resources

The handbook entitled *Developing and Using a Concept of Operations in
Transportation Management Systems* is intended to provide guidance for
transportation professionals as they seek to develop and use a Concept
of Operations throughout the life cycle of a TMS. It is written for
transportation professionals involved in the planning, development,
design, operation, and maintenance of TMSs.

The documents listed below are available on the TMC Pooled-Fund Study
website at <http://tmcpfs.ops.fhwa.dot.gov/>.

-   *Developing and Using a Concept of Operations in Transportation
    Management Systems*,\
    FHWA-HOP-07-001 (Washington, DC: September 2005).

-   *Developing and Using a Concept of Operations in Transportation
    Management Systems* *-- Fact Sheet*, FHWA-HOP-07-002 (Washington,
    DC: August 2006).

![](media/image7.jpeg){width="8.58611111111111in"
height="11.227777777777778in"}

[^1]: Federal Highway Administration, *Developing and Using a Concept of
    Operations in Transportation Management Systems*, FHWA-HOP-07-001
    (Washington, DC; September 2005).

[^2]: City of Fontana, California, *Fontana/Ontario Advanced Traffic
    Management Information System (ATMIS), Phase 1C: Concept of
    Operations Document,* (Fontana, CA; December 13, 2000).

[^3]: Ibid.