System Engineering Documents
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.
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|
|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|
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 portion of 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 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 document, i.e., to be altered to address changes in user needs, system requirements, operating environment, desired functionalities, or constraining elements.
The document is typically developed early in the process as a supplement to the PMP. While the PMP addresses general project management details, such as project scope, participating personnel, schedule of activities, task scheduling, and costs, the Systems Engineering Management Plan (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.
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:
- 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.
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.)?
- Which arterials should be included?
- 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
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.Core components
The core components of AMS are:
- Analysis—Developing as thorough an understanding of the corridor as possible through detailed investigation of available information about the corridor.
- 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.
- 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.
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.
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 ICM, requirements are 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:
- User Needs gathered from local partners and stakeholders
- The Concept of Operations developed based on the identified user needs
- Comments gathered from interviews with individuals and meetings focused on requirements-gathering
- Transportation Systems Management and Operations (TSM&O) success criteria
- ICM Capability Maturity Matrix (CMM) developed by Caltrans
- Review of system requirements developed for existing ICM systems across the U.S.
- Review of various technical documents, websites, and presentations related to ICM
- Advice provided by informed personnel from other U.S. ICM sites
- Advice from knowledgeable consultants
- Management judgment
ChallengesDefining the breadth and depth of the requirements.
- Breadth – The project team should understand that requirements include people, organizations, software, and hardware; all facets of the ICM CMM. This is in contrast 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 to create and manage a real-time operational system. Many essential requirements would be missed if only requirements for software elements were included.
- Depth – Requirements should be specified to the level that identifies and resolves significant differences in stakeholder opinion and/or beliefs, particularly before design of the proposed system is initiated, where it would be preferable not to discover fundamental differences between 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 requires in-depth discussions on who or what will perform each 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. The following rule may be applied: If a specific item that could reasonably be considered a design decision was mentioned by more than one person, this item can then be listed as a potential requirement.
For areas where requirements are missing, the following actions may be taken:
- If, when looking across the process flows discussed in the user meetings, a missing piece is identified that was at the same level as other requirements, it could be included as a requirement.
- If a requirement is at such a high-level that it is unclear how or whom to ask to implement, then it may be broken down into smaller requirements.
- As source material from different areas are reviewed it may be discovered that certain items were omitted from partner discussions and interviews. In such cases, professional judgment is necessary to determine whether to add a requirement or not.
Unfamiliarity with the ICM concept - The concept of ICM is new to many people who will be asked to provide requirements. As such, they will look to the management team to help define the requirements. The management team, including the contractor, should use their professional expertise combined with knowledge gained from previous efforts and the input from experts wherever available to assist in guiding the project.
Categories of Requirements
As illustrated in the following diagram, requirements may be organized into categories that match the major functions in the corridor management workflow:
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 Caltrans ICM website.
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 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.
The high-level design below illustrates the various system components that may be included in an ICM including the field elements (green), data hub (red), the Decision Support System (blue), and the Corridor Management System (purple). An example of a high-level design document is available on the UC Berkeley Connected Corridors website.