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

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.

This short section gives a brief overview of the system to be built. It includes its objectives 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.