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

8.4.8 Integration Plan Template

A project’s integration and verification strategy is closely tied to the design of the system and its decomposition into sub-systems. The factors that are considered when developing the sub-system design are covered elsewhere in this Guidebook. Whatever the goals were [and they vary from project to project], the Integration Plan needs to be structured to bring the components together to create each sub-system and to bring the various sub-systems together to make the whole system. Further, this needs to be done in a way that supports the deployment strategy. That is the first purpose of an Integration Plan.

The second purpose is to describe to the participants in each integration step what has to be done. The integration team has to assemble various resources for each integration step. The Integration Plan identifies the needed resources. In addition, it identifies when and where the resources will be needed.

Tailoring this Document to Your Project

An Integration Plan, at least as a separate written document, is not always needed. The complexity of the system, the complexity of the eventual deployment of the system, and the complexity of the development effort influence the decision to prepare an Integration Plan. For instance, a deployment strategy that calls for multiple installations at multiple locations can require a complex sequence of integration activities. Another common complexity of integration arises when different teams are developing the sub-systems. This is especially true when the different development teams are comprised of different contractors, each with their own contract. In this case, they need to know more about their required work to support integration than would be the case if the same development team were working both sides of the integration effort. The same type of complexity comes into play when an integration step involves external systems owned by other agencies, or at least other organizations within the agency.

If a separate Integration Plan is not warranted, the necessary planning information can be included in: the Project Plan, the SEMP, the Verification Plan and the software development plans of the development team.

Checklist: Critical Information

check Does the Integration Plan include and cover integration of all of the components and sub-systems, either developed or purchased, of the project?
check Does the Integration Plan account for all external systems to be integrated with the system [for example, communications networks, field equipment, other complete systems owned by the agency or owned by other agencies]?
check Does the Integration Plan fully support the deployment strategy. For example, when and where the sub-systems and system is to be deployed?
check Are the integration steps defined in the Integration Plan consistent with the verification activities defined in the Verification Plan?
check For each integration step, does the Integration Plan define what components and sub-systems are to be integrated?
check For each integration step, does the Integration Plan identify all the needed participants and define what their roles and responsibilities are?
check Does the Integration Plan establish the sequence and schedule for every integration step?
check Does the Integration Plan spell out how integration problems are to be documented and resolved?




Title Page

The title page should follow the Transportation Agency procedures or style guide. At a minimum, it should contain the following information:

  • INTEGRATION PLAN 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

1.0 Purpose of Document

A brief statement of the purpose of this document. It is, the plan for integrating the components and sub-systems of the project prior to verification.

2.0 Scope of Project

This section gives a brief description of the planned project and the purpose of the system to be built. Special emphasis is placed on the project’s deployment complexities and challenges.

This section may be lifted from earlier documents. It is important only to people [stakeholders] who will be introduced to the project for the first time by this document.

3.0 Integration Strategy

This section informs the reader what the high level plan is for integration and, most importantly, why the integration plan is structured the way it is. As mentioned before, the Integration Plan is subject to several constraints, sometimes conflicting constraints. Also, it is one part of the larger process of build, integrate, verify, and deploy. All of which must be synchronized to support the same project strategy. So, for even a moderately complex project, the integration strategy, based on a clear and concise statement of the project’s goals and objectives, is described here at a high, but all-inclusive, level. It may also be necessary to describe the analysis of alternative strategies to make it clear why this particular strategy was selected.

The same strategy is the basis for the Build Plan, the Verification Plan, and the Deployment Plan. So, it may only be necessary to justify this strategy once, perhaps in the Project Plan, or in the SEMP.

This section covers and describes each step in the integration process. It describes what components are integrated at each step and gives a general idea of what threads of the operational capabilities [requirements] are covered. It ties the plan to the previously identified goals and objectives so the stakeholders can understand the rationale for each integration step. This summary level description also defines the schedule for all the integration efforts.

4.0 Phase 1 Integration

This, and the following sections, define and explain each step in the integration process. The intent here is to identify all the needed participants and to describe to them what they have to do.

In general, the description of each integration step should identify:

  • The location of the activities
  • The project-developed equipment and software products to be integrated Initially this is just a high level list but eventually the list must be exact and complete, showing part numbers and quantity
  • Any support equipment [special software, test hardware, software stubs, and drivers to simulate yet-to-be-integrated software components, external systems] needed for this integration step. The same support equipment is most likely needed for the subsequent verification step
  • All integration activities that need to be performed after installation, including integration with on-site systems and external systems at other sites
  • A description of the verification activities [as defined in the applicable Verification Plan] that occur after this integration step
  • The responsible parties for each activity in the integration step
  • The schedule for each activity

5.0 Multiple Phase Integration steps [1 or N steps]

This, and any needed additional sections, follow the format for section 3. Each covers each step in a multiple step integration effort.


Related Task Examples Checklist  


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