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

Skip to content
Facebook iconYouTube iconTwitter iconFlickr iconLinkedInInstagram

California Division

Home / About / Field Offices / California Division / Systems Engineering Guidebook for ITS

Home What's New Systems Engineering Guidebook Views Search Glossary Resources Feedback Site Map

1.2 Questions that this Guidebook Addresses

Is systems engineering just an elaborate process that will unduly burden the ITS practitioner?

No. When applied correctly, systems engineering requires more effort at the beginning of the project. However, it reduces effort in re-work during and at the end of the project thus potentially providing an overall schedule savings.

Systems engineering is associated with a set of processes. If it is viewed only as a series of required activities without consideration of the complexity of the system, it can become a burden on the project. This is not the intent of systems engineering nor this Guidebook. Systems engineering is also a mind-set called "systems thinking". The challenge is to use systems thinking to tailor these processes into a set of activities that will successfully develop and deliver Intelligent Transportation Systems in the most efficient way.

The following are a few examples of systems engineering principles that express “systems thinking” and are needed to tailor the process according to the project complexity:

  • First, understand the problem to be addressed.
  • View the problem and solution from the stakeholders' point of view – walk in the shoes of the system's owner and stakeholders.
  • Start at the finish line by defining the output of the system and the way the system is going to operate.
  • Address project risks as early as possible, when the cost impacts are lowest.
  • Make technology choices at the last possible moment by defining what is to be done before defining how it is to be done [form follows function].
  • Focus on interfaces of the system and of the project [organizational, teams and process interfaces].
  • Understand the organization of the system's owner and stakeholders to enable stakeholder participation.

This Guidebook is not intended to be a “one size fits all” guide for system's development. It is important to assess the amount of systems engineering needed for each ITS project based on its own risk and quality needs rather than to follow a “script”. Applying system's thinking to a project is essential to the tailoring of the processes to achieve the required level of system quality. This Guidebook will provide the best practices when applying the steps of the systems engineering process.

Are there any benefits gained by doing systems engineering on my projects?

Yes. The primary benefit of doing systems engineering is that it will reduce the risk of schedule and cost overruns and will provide a system of higher integrity. Other systems engineering benefits include as follows:

  • better system documentation
  • higher level of stakeholder participation
  • system functionality that meets stakeholders' expectation
  • potential for shorter project cycles
  • systems that can evolve with a minimum of redesign and cost
  • higher level of system reuse
  • more predictable outcomes from projects

Many studies show the importance of using systems engineering principles. These reports document how using systems engineering principles has reduced the risks of project overruns and schedule delays when applied correctly. [See the following references in chapter 8.2.2]: Standish research group study – Chaos 1994 and updated in 2000, 2] NASA studies, and 3] the INCOSE Center of Excellence].

Is Systems Engineering right for me, especially on my small projects?

Yes! Systems engineering should be applied on all projects: small, large, simple, or complex. The degree of formality and rigor applied to the systems engineering process will vary depending on the complexity of the project. This is called tailoring. All projects need to be assessed for the amount of formal systems engineering processes needed. Projects can be tailored up (more formality) for more complex projects as well as tailored down for simpler projects.

Systems engineering thinking is critical on all ITS projects. Systems engineering processes and techniques support systems thinking. Systems engineering processes and techniques must be scaled and tailored appropriately to each ITS project. This Guidebook gives guidance on tailoring for each step of the process and recommendations based on example projects.

The tailoring needed for a project depends on the following project risk factors:

  • system and institutional complexity [institutional issues, interfaces, technology]
  • number and type of stakeholders [integration of transportation and/or non-transportation agencies, scale of project] inter-agency decisions and agreements that need to be made [sharing of control and data]
  • existing and needed documentation for the evolution of the system [legacy and new systems documentation for maintenance, expansion, and replacement]

Can I leverage existing agency resources to help me with systems engineering on my project?

Yes. The extent of this leveraging will depend upon the size of and the expertise within the agency and/or cooperative agreements with other agencies, e.g. MPO, State DOT, adjoining public agency, federal resources, and systems engineering consulting services.

In organizations, often there are existing capabilities, processes, tools, and products that can be leveraged for the systems engineering support environment. For example, products from training, information technology, asset management, quality assurance, risk management, and legal organizations can be used as a starting point for ITS projects.

This Guidebook describes the roles, responsibilities, and activities of the system's owner, system's manager [Systems Engineering Technical Assistance, Independent Verification and Validation], and the development team [Systems Integrator] throughout the project life cycle. These activities may be performed by agency personnel, contracted personnel, or a combination of the two. However, there are certain activities that are important for the system's owner to perform. These activities are identified within each step of the systems engineering process by this Guidebook.

Can the systems engineering processes fit into the transportation project development cycle?

Yes. The systems engineering process is not new to the transportation domain. A systems approach has been used to build capital projects [highways] for years utilizing “systems thinking”. The basic phases used for transportation development projects [study, concept exploration, definition, implementation, operations & maintenance, and rehab/replace] are also the same phases used for Intelligent Transportation Systems [ITS] projects. Unique to ITS projects are the artifacts and the rapidly changing technology. As a result, the tasks and activities of the systems engineering process are different for ITS to accommodate this reality.

Are here different systems engineering development models that can be used for Intelligent Transportation Systems? Which one is the best?

Yes. The classic system development models include: Waterfall, Spiral, and the Vee development models. This Guidebook describes the various systems development models and delivery strategies with examples of types of ITS projects for each. The Vee Development Model is used as the overall framework for the project cycle as illustrated in

Figure 1‑3 below. The Guidebook uses the Vee model [tailored for ITS] originally developed by NASA, in the late 1980s, for software development and then adapted for system development by Kevin Forsberg and Hal Mooz in 1990. The Vee Development Model is the third generation of models that integrate the original Waterfall and the Spiral models. The Vee Development Model is recommended by the Federal Highway Administration as the preferred method for Intelligent Transportation Systems development and is taught by the National Highway Institute. Today, the Vee Development Model is part of systems engineering standards including EIA 632 and ISO 15288. It has become popular in a number of industries including automotive, banking, defense, and aerospace.

The Vee Development Model is popular because it illustrates the following key systems engineering principles not illustrated in the other two models:

  • the relationships of the outputs from early phases of the project to the later phases of the project
  • the illustration of control or decision gates
  • involvement of the stakeholders in the early phases of the project

The other models have a role in systems development. For example, the Spiral Development Model is widely used to reduce risk for some aspects of software development, such as user interfaces and algorithm development for processing information. When used in context of the Vee Development Model, the Spiral can be used in the individual phases before proceeding to the next phase.

Vee Development Model showing the lifecycle tasks in this guidebook.

Figure 1‑3 Adapted from the Vee Technical Development Model


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