System Engineering Documents

User Needs

User needs govern the development of the ICM system concept and are determined based upon  a conceptual system analysis and input from the stakeholders and the system development team.

User Needs Workshop

Project Management Plan

The Project Management Plan (PMP) is the primary planning document of a project. Elements captured in the PMP normally cover all phases of a project, from initiation through planning, execution, and closure. The PMP provides a comprehensive baseline of what has to be achieved by the project, how it is to be achieved, who will be involved, how it will be reported and measured, and how information will be communicated. Specific elements addressed by the PMP typically include the following:
  • Overview: Why the project is being conducted and its primary objectives
  • Scope: Business needs, requirements, deliverables, constraints, and work breakdown structure
  • Project team: The people working on the project, their roles and responsibilities
  • Schedules: Activities schedule and project milestones
  • Communications: Communication type, channels, and the reporting approach
  • Costs: Project budget and its funding approach
  • Quality Control: Quality measurement and control approach
  • Risks: Risk index, methods to identify and evaluate risks, risk mitigation, and contingency planning I-210 Connected Corridors Pilot – Project Management Plan 2
  • Procurements: Required procurements and purchase processes
  • Closure: Closure approach, including protocols for handing-off deliverables
  • Changes: Procedures used to track changes in the project
  • Baselines: Scope, schedule, and budget baselines
  • Project Evaluation: Methods to assess project activities and outcomes

Concept of Operations

The development of the ConOps is part of the systems engineering analysis process that the Federal Highway Administration (FHWA) requires be followed for the development of Intelligent Transportation System (ITS) projects. The development of a ConOps typically occurs after a needs assessment and some preliminary project planning have been conducted; but before a full design is initiated.  In this context, the primary functions of a ConOps are to:
  • Establish the rationale for the system;
  • Refine the vision, goals, and objectives of the proposed system;
  • Develop representative operational scenarios illustrating what the proposed system will do;
  • Ensure that the needs and expectations of stakeholders are captured early in the system development process;
  • Ensure that the system functionalities are linked to the mission, goals, and objectives of participating agencies;
  • Begin the traceability of the Systems Engineering Process.

A ConOps seeks more specifically to illustrate the benefits that can be obtained from the application of advanced technologies; the coordination of systems traditionally used independently to manage the movements of vehicles, persons, and goods within a corridor; and the development of cooperative operations among corridor systems and stakeholders.  Only high-level descriptions are typically provided in a ConOps as this document is primarily meant to act as a discussion vehicle and consensus-building tool among potential project stakeholders.

Specific questions that the ConOps seeks to address regarding the proposed I-210 ICM system include:

  • What are the goals and objectives of the system?
  • How will the system achieve its stated goals?
  • How can corridor performance be adequately captured?
  • How will existing corridor operations be enhanced by the proposed system?
  • What new functionalities will be provided by the system?
  • Who are the system users?
  • Who are the various system stakeholders?
  • What are the stakeholders’ specific roles?
  • What are the operational and institutional environments in which the system will operate?
  • What would be the main system components and functionalities?
  • What sequences of activities will typically be performed to address specific situations or requests of interest?
  • What resources would be needed to design, build, operate, and maintain the system?
  • What operational, technical, and institutional elements may influence the design and implementation of an actual system?

While it is expected that the ConOps will inform and guide future system design activities, it must be kept in mind that it is meant to be living documents, i.e., to be altered to address changes in user needs, system requirements, operating environment, desired functionalities, or constraining elements.

Project Tasks and Timeline

In following the systems engineering approach and tailoring it to the needs of the project, the Connected Corridors team developed the following timeline to map the project's tasks:

View full-size image (1)
project tasks and timeline workflow chart
As the timeline illustrates, many of the tasks overlap or occur simultaneously. Some are relatively brief, while others continue throughout the life of the project. There is also considerable and ongoing interplay among the tasks. For example:

  • Project Management touches every task in the project, as does Outreach and Communications with stakeholders, whose input and engagement are integral to moving the project forward.
  • System design, development, integration, and deployment tasks are interdependent and proceed in parallel.
  • System Evaluation begins with the design phase and continues for the rest of the project, to monitor and critically assess whether the objectives and user needs are being met.

Note: The timeline may be updated periodically in the course of the project.

 Systems Engineering Management Plan (SEMP)

Figure 1-2 illustrates how the SEMP relates to the systems engineering process.  The document is typically developed early in the process as a supplement to the Project Management Plan (PMP).  While the PMP addresses general project management details, such as project scope, participating personnel, schedule of activities, task scheduling, and costs, the SEMP focuses on the technical plans and systems engineering activities that will be used to carry the project to its end.  Its purpose is to detail the processes that will be used to support the design, implementation, integration, verification, and eventual operation of the proposed system.  Its development typically uses the foundation laid by the PMP to build the framework for implementing the technical tasks of the project.

View full-size image (2)
systems engineering managment plan diagram

The SEMP does not attempt to answer what is to be done, but rather how what needs to be done should be executed.  For example, the SEMP does not seek to define what the product concept is. It asks instead how the product concept is to be determined. This distinction between “how” and “what” is important in understanding the purpose of the SEMP.  While the SEMP answers “how” questions, the various documents and processes it describes are used to answer the “what" questions.

Because the SEMP is developed early in the life cycle of a project, it is generally written with only a partial understanding of what is to be developed.  Available information typically includes only the results of preliminary corridor operational evaluations and needs assessments, as well as preliminary concept explorations that might have been conducted to assess project feasibility.  As a result, several versions the SEMP may be released during a project, usually within the first half of the systems engineering process, as shown in the annotations of Figure 1‑2:

  • A first version is generally produced by the project management staff early in the project life cycle to define the framework within which systems engineering activities are to be conducted. At this stage, only enough detail is included to allow the identification of all needed tasks and important constraints on the execution of each task. 
  • As the project progresses through the Concept of Operations, definition of system requirements, and system design, the various sections or plans identified in the SEMP framework are gradually completed. Examples of elements that are commonly defined at this stage include details of the tools that will be used to manage the requirements, the methodology that will be used to design software components, the processes that will be used to manage system configurations, methods to be followed for verifying system components, etc.

As indicated, the SEMP is not meant to be a static document.  Instead, it is meant to be a living document subject to various updates until it reaches a final, stable version.

Analysis, Modeling, and Simulation Report

Assessing Potential Project Benefits: Analysis, Modeling, and Simulation

The data collected about a corridor can provide a broad and detailed picture of its attributes, operations, and user needs. This information then raises key questions for the ICM project:

  • How could ICM improve corridor performance?
  • What are the most important scenarios that can be addressed by the project (recurrent congestion, incidents, weather, planned events, etc.)?
  • What response strategies should be considered?
  • How should the effectiveness of response strategies be measured?
  • How should benefits and costs be assessed?

These questions are explored through analysis, modeling, and simulation (AMS)—the use of modeling and simulation tools to test the impact of various control strategies and assess the potential benefits and implications of ICM.

An evaluation process

Analysis, modeling, and simulation (AMS) is an evaluation process used to understand traffic operations along a corridor, identify key transportation challenges, and explore potential management strategies to improve corridor operational performance. A vital part of the systems engineering methodology, AMS is tasked with ensuring that solutions are chosen correctly, funds are spent effectively, and performance is measured quantitatively. It plays an essential role in the I-210 Pilot project and proceeds in phases along with the planning, implementation, deployment, and evaluation of the I-210 Pilot itself.

Core components

The core components of AMS are:

  1. Analysis—Developing as thorough an understanding of the corridor as possible through detailed investigation of available information about the corridor.
  2. Modeling—Developing and calibrating a model that captures existing traffic conditions. Model building is an iterative process that begins with the best data and best understood parts of the corridor, and continues as additional data are analyzed and the extent of the model is expanded.
  3. Simulation—Using the developed model to improve understanding of traffic behavior on the corridor and to define and select the best management strategies and control interventions to address its key challenges.

AMS Phase 1 Report for the I-210

System Requirements

The purpose of system requirements is to define what the ICM system should do. This represents a key decision point in developing the system, as the requirements set the direction for how the system will be designed, built, and ultimately implemented. The process of generating requirements must therefore make sure that stakeholders, implementers, users, and future reviewers of the system clearly understand what it must do to function effectively.

To define what the ICM system should do, it is essential to understand what is meant by the "system." Not simply a piece of technology, the system is considered a total entity made up of people, organizations, hardware, and software. All these components must work together to achieve the goals of the project, and the system requirements must specify what is expected from each.

ICM system component diagram 

Defining what is required of each component is a challenging task, because no single person understands the system fully when requirements-gathering begins. Nor can they, for the requirements emerge from the additive process of each person defining what they believe the system must do in order to meet their agency's particular needs.

In a successful requirements-gathering process, each participant will learn more about their fellow users and how their requirements can fit in with the requirements of others. This process is iterative and can require creativity and compromise. It is thus both educational and definitional:

  • To educate stakeholders about the range of needs along the corridor
  • To define how those needs can be met to benefit corridor operations as a whole

Sources of Information
For the I-210 Pilot, the requirements were based primarily on information gathered from system stakeholders on the purpose and desired functionalities of the system, supplemented by additional criteria, guidelines, and technical expertise. Sources of information include:

  1. User Needs for the I-210 Pilot that were collaboratively identified by system stakeholders
  2. The Concept of Operations for the I-210 Pilot that was previously developed by the PATH Connected Corridors project based on the identified user needs
  3. Comments gathered from approximately 75 interviews with individuals and more than 20 meetings focused on requirements-gathering
  4. Transportation Systems Management and Operations (TSM&O) success criteria
  5. ICM Capability Maturity Matrix developed by Caltrans
  6. Review of system requirements developed for both the Dallas and San Diego ICM systems
  7. Review of various technical documents, websites, and presentations related to ICM
  8. Advice by informed personnel from other ICM sites
  9. Advice from knowledgeable consultants
  10. Management judgment

During the development process, we found that the people providing input into the requirements cover a broad base in experience and work function, and thus, their contributions and insights were invaluable for defining what the system should do. We also found that participants were interested and motivated, and their engagement added energy and momentum to carrying out this complex task.
While these were positive discoveries, the team also encountered some challenges:

• Defining the breadth and depth of the requirements
  • Breadth – The project team has taken the view that requirements should address people, organizations, software, and hardware. This is an alternative to the view that requirements should focus mainly on software. Many of the requirements are based on an assumption that the largest challenges of ICM are not in the software but in the successful integration of people and processes. Many essential requirements would be missed if they were to include only software elements.
  • Depth – It is believed that requirements should be specified to the level that identifies and resolves significant differences in opinion or belief, particularly before design of the proposed system is initiated, where we would prefer not to discover fundamental differences between our stakeholders. One of the purposes of requirements-gathering is to ensure that the project team has educated personnel on ICM and arrives at real agreement. This can require in-depth discussions on who or what will perform a function.
• Defining the difference between a requirement, a design constraint, and a design decision-a traditional answer is that requirements define what the system must do to meet the user needs, design constraints limit the possible implementation methods, and design decisions determine how to implement the requirements. In practice, it can be difficult to distinguish between a low-level requirement, a design constraint, and a high-level design decision. By its definition, a requirement is something that a person believes is required for the system to function correctly. One person’s beliefs are frequently different from another’s and often related to how a function will be implemented. For the I-210 Pilot, we have chosen to apply the following rule: If a specific item that could reasonably be considered a design decision was mentioned by more than one person, this item was then listed as a potential requirement. • Missing requirements- several areas where requirements were missing were identified throughout the gathering process. To address these missing elements, the following actions were taken:
  • If, when looking across the process flows we discussed in the user meetings, we saw a missing piece that was at the same level as other requirements, we included it as a requirement.
  • If a requirement was so high-level that we didn’t know how or who we may ask to implement it, then we broke it down into smaller requirements.
  • As we brought together source material from different areas, we noted that we did not discuss certain items in our interviews. We used judgment in adding in requirements from other sources.

• Unfamiliarity with the ICM concept- The concept of ICM is new to many people who were being asked to provide requirements. As such, they looked to us to help define the requirements. We have used our own experiences combined with previous efforts and the opinions of experts to help guide us.

Categories of Requirements
As illustrated in the following diagram, the requirements were organized into categories that match the major functions in the corridor management workflow:

connected cooridors requirements chart

The main categories shown above in blue support these workflow functions:
  • Institutional Support- People and organizations work together to manage, resource, fund, and maintain a working ICM system that is accepted by all stakeholders
  • Strategic Incident Response Planning- Stakeholders routinely plan, review, and update responses to incidents
  • Corridor Monitoring- Real-time corridor status information is continually monitored
  • Real-time Response Planning- Predefined response plan components and the current corridor state suggest tailored response plans
  • Response Plan Implementation- Once a response plan is chosen, it will then be implemented by corridor resources

To learn more about user needs, themes, actors and stories, and the categories of requirements, please visit the System Requirements section on the Connected Corridors website.

High-Level Design

The high-level design process results in the development of a document that identifies the primary subsystems and major components of the proposed ICM System. The document also explains the selection, development, and integration of these components into a system that satisfies the system requirements as defined previously in the Systems Requirements Document. The high level design governs the technology platform and direction of the I-210 Pilot ICM System and will serve as the basis for other Caltrans-led ICM efforts statewide.

The high level design and detailed design steps are part of the System Definition and Design phase in the systems engineering process. The resulting high level design elements are in turn used to inform and guide the more detailed design of the various system and subsystem components.

For the I-210 Pilot, the high level design shows the various system components including the field elements (green), data hub (red), the Decision Support System (blue), and the Corridor Management System (purple). The high level design document is available on the Connected Corridors website ( The detailed design document will be made available in the coming year.

View full-size image (3)
high level design process chart

To learn more about user needs, themes, actors and stories, and the categories of requirements, please visit the System Requirements section on the Connected Corridors website.