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

Skip to content U.S. Department of Transportation/Federal Highway AdministrationU.S. Department of Transportation/Federal Highway Administration

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.2 Systems Engineering Management Plan Template

Purpose of this Document

The SEMP [Systems Engineering Management Plan], may be needed to supplement the details of the Project Plan. When used, the SEMP focuses on the technical plan of the project and the systems engineering processes to be used for the project. Its purpose is to detail out those engineering tasks; especially to provide detailed information on the processes to be used. Preparation of a SEMP is most important if the project involves development of custom software. The engineering tasks of producing custom software [from requirements, through design implementation, integration, and verification] are very complex, and are new to many transportation engineers.

Given the level of process detail needed in the SEMP, it often written in two steps. In the first step, the framework for the document is prepared, usually by the project management staff. Enough detail is included to identify all the needed tasks [including analysis tasks] and any important constraints on the performance of a task [such as use of a specific systems engineering and design methodology]. In the second step, the various sections of the SEMP framework are completed, this time by the team that will perform each task. For instance, the requirements team provides details on the analysis and the tools used to manage requirements. The design team provides details on use of the software design methodology. The software coder provides details on configuration management of the software code. The verification team provides details on their verification methods.

These SEMP template were adapted from guidelines prepared by the Caltrans Office of Local Assistance.  See the web page at: http://www.dot.ca.gov/hq/LocalPrograms/lam/prog_g/g12othr.pdf .

Tailoring this Document to Your Project

The simplest ITS projects may not need a SEMP; the Project Plan may be sufficient. Among the project complexities that make preparation of a SEMP desirable are:

  • Inexperience of the system’s owner’s project team in the systems engineering tasks and processes
  • A larger number of stakeholders and the degree of their involvement in the various systems engineering processes and tasks
  • The need to develop custom software applications
  • A project where the solution is not well understood and is not generally obvious

Checklist: Critical Information

check Are all the technical challenges of the project addressed by the systems engineering processes described in the SEMP?
check Does the SEMP describe the processes needed for requirements analysis?
check Does the SEMP describe the design processes and the design analysis steps required for an optimum design?
check Does the SEMP clearly identify any necessary supporting technical plans, such as a Verification Plan or an Integration Plan? Does it define when and how they will be written?
check Does the SEMP spell out stakeholder involvement when it is necessary?
check Does the SEMP identify all the required technical staff and development teams? Does it identify the technical roles to be performed by the system’s owner, project staff, stakeholders, and the development teams?
check Does the SEMP cover the interfaces between the various development teams?




Title Page

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

  • SYSTEMS ENGINEERING MANAGEMENT PLAN FOR THE [insert name of project] AND [insert name of transportation agency]
  • Contract number
  • Date the 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

This section is a brief statement of the purpose of this document and the plan for the systems engineering activities with special emphasis on the engineering challenges of the system to be built.

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 complexities and challenges that must be addressed by the systems engineering efforts.

This section also describes the environment in which the project will operate. It identifies the organization structures that encompass all stakeholders. It gives a brief description of the role to be played by each stakeholder. This includes ad hoc and existing management work groups and multi-disciplinary technical teams that should be formed or used to support the project. Such teams are critical to reaching successful system deployment.

This section defines the general process for developing the SEMP, including the draft framework version prepared by the transportation agency or their Systems Engineer and the complete version prepared in conjunction with the Systems Engineer and Development Teams.

3.0 Technical Planning and Control

This section lays out the plan for the systems engineering activities. It must be written in close synchronization with the project’s Project Plan. Unnecessary duplication between the Project Plan and the SEMP should be avoided. However, it is often necessary to put further expansion of the systems engineering effort into the SEMP even if they are already described at a higher level in the Project Plan. Even within the SEMP, an effort may need to be described at a higher level in the draft SEMP framework. Then it may need to be expanded further in the final version of the SEMP. An example would be the Configuration Management Plan, to be described below.

The purpose of the section is to describe the activities and plans that will act as controls on the project’s systems engineering activities. For instance, this section identifies the products of each systems engineering activity, such as, documentation, meetings, and reviews. This list of required products will control the activities of the team performing the activity and will control the satisfactory completion of the activity. Some of these plans may be completely defined in the SEMP [in the framework or the complete version]. For other plans, the SEMP may only define the requirements for a particular plan. The plan itself is to be prepared as one of the subsequent systems engineering activities, such as may be the case with a Verification Plan or a Deployment Plan. Almost any of the plans described below may fall into either category. It all depends on the complexity of the particular plan and the amount of up-front systems engineering that can be done at the time the SEMP is prepared.

The first set of required activities/plans relates primarily to the successful management of the project. These activities are likely to have already been included in the Project Plan, but may need to be expanded here in the SEMP. Generally, they are incorporated into the SEMP; but, on occasion, may be developed as separate documents.

  • Work Breakdown Structure [WBS] [also included in the Project Plan] a list of all tasks to be performed on a project, usually broken down to the level of individually budgeted items
  • Task Inputs is a list of all inputs required for each task in the WBS, such as source requirements documents, interface descriptions, and standards.
  • Task Deliverables is a list of the required products of each task in the WBS, including documents, software, and hardware
  • Task Decision Gates is a list of critical activities that must be satisfactorily completed before a task is considered completed
  • Reviews and Meetings is a list of all meetings and reviews of each task in the WBS
  • Task Resources is identification of resources needed for each task in the WBS, including for example, personnel, facilities, and support equipment
  • Task Procurement Plan is a list of the procurement activities associated with each task of the WBS, including hardware and software procurement and, most importantly, any contracted services, such as systems engineering services or development services
  • Critical Technical Objectives is a summary of the plans for achieving any critical technical objectives that may require special systems engineering activities. It may be that a new software algorithm needs to be developed and its performance verified before it can be used. Or a prototyping effort is needed to develop a user-friendly operator interface. Or a number of real-time operating systems need to be evaluated before a procurement selection is made. This type of effort is not needed for all projects
  • Systems Engineering Schedule a schedule of the systems engineering activities that shows the sequencing and duration of these activities. The schedule should show tasks [at least to the level of the WBS], deliverable products, important meetings & reviews, and other details needed to control and direct the project. An important management tool is the schedule. It is used to measure the progress of the various teams working on the project and to highlight work areas that need management intervention

The second set of plans is designed to address specific areas of the systems engineering activities. They may be included entirely in the SEMP or the SEMP may give guidance for their preparation as separate documents. The plans included in the first set listed above are generally universally applicable to any project. On the other hand, some of the plans included in this second set are only rarely required. The unique characteristics of a project will dictate their need.

  • Software Development Plan describes the organization structure, facilities, tools, and processes to be used to produce the project’s software. Describes the plan to produce custom software and procure commercial software products
  • Hardware Development Plan describes the organization structure, facilities, tools, and processes to be used to produce the project’s hardware. It describes the plan to produce custom hardware [if any] and to procure commercial hardware products
  • Technology Plan if needed, describes the technical and management process to apply new or untried technology to an ITS use. Generally, it addresses performance criteria, assessment of multiple technology solutions, and fall-back options to existing technology
  • Interface Control Plan identifies the physical, functional, and content characteristics of external interfaces to a system and identifies the responsibilities of the organizations on both sides of the interface
  • Technical Review Plan identifies the purpose, timing, place, presenters & attendees, subject, entrance criteria, [a draft specification completed] and the exit criteria [resolution of all action items] for each technical review to be held for the project
  • System Integration Plan defines the sequence of activities that will integrate software components into sub-systems and sub-system into entire systems. This plan is especially important if there are many sub-systems produced by a different development team
  • Verification Plan almost always required, this plan is written along with the requirements specifications. However, the parts on test conduct can be written earlier
  • Verification Procedures are developed by the Development Team and this defines the step by step procedure to conduct verification and must be traceable to the verification plan
  • Installation Plan or Deployment Plan describes the sequence in which the parts of the system are installed [deployed]. This plan is especially important if there are multiple different installations at multiple sites. A critical part of the deployment strategy is to create and maintain a viable operational capability at each site as the deployment progresses
  • Operations & Maintenance Plan defines the actions to be taken to ensure that the system remains operational for its expected lifetime. It defines the maintenance organization and the role of each participant. This plan must cover both hardware and software maintenance
  • Training Plan describes the training to be provided for both maintenance and operation
  • Configuration Management Plan describes the development team’s approach and methods to manage the configuration of the system’s products and processes. It will also describe the change control procedures and management of the system’s baselines as they evolve
  • Data Management Plan describes how and which data will be controlled, the methods of documentation, and where the responsibilities for these processes reside
  • Risk Management Plan addresses the processes for identifying, assessing, mitigating, and monitoring the risks expected or encountered during a project’s life cycle. It identifies the roles & responsibilities of all participating organizations for risk management
  • Other plans that might be included are for example, a Safety Plan, a Security Plan, a Resource Management Plan, and/or a Validation Plan

This second list is extensive and by no means exhaustive. These plans should be prepared when they are clearly needed. In general, the need for these plans become more important as the number of stakeholders involved in the project increases.

4.0 Systems Engineering Process

This section describes the intended execution of the systems engineering processes used to develop the system. These processes are generically described in the Guidebook and identified in the VEE life cycle technical development model. The SEMP describes the processes specifically needed for a project. It defines them in sufficient detail to guide the work of the systems engineering and development teams.

The FHWA’s Final Rule [23 CFR Part 940 part 11] places requirements on the minimum description of the systems engineering analysis for projects funded with highway trust funds. For all projects, the following factors should be discussed in the SEMP:

  • Identification of portions of the regional ITS architecture being implemented. Or, if a regional ITS architecture does not exist, the applicable portions of the National ITS Architecture
  • Identification of participating agencies and their roles & responsibilities
  • Requirements definitions
  • Analysis of alternative system configurations and technology options to meet requirements
  • Procurement options
  • Identification of applicable ITS standards and testing procedures
  • Procedures and resources necessary for operations & maintenance of the system

This section will contain a description of the systems engineering procedures tailored to the specific project. There are four areas of analysis that need to be described:

  • System Requirements Analysis describes the methods to be used to prepare the Concept of Operations and the top-level system requirements documents. The analysis techniques that may be used include: peer reviews, working groups, scenario studies, simulation, and prototyping. The amount of analysis required increases with the risk of the specific requirement. The process for approving the resulting documents will be described, including who is involved, whether technical reviews are necessary, and how issues and comments are resolved so the baseline can be defined
  • Sub-system [Functional] Analysis describes the methods to be used to identify sub-systems and to allocate the system [top-level] requirements to the sub-systems. It is often necessary, at this step, to expand the top-level requirements into a complete description of the functions of the system, for instance, details of an operator interface. It also may be necessary, at this time, to define internal interfaces [sub-system to sub-system] to the same level of detail as the external interfaces [interfaces to other systems]. The SEMP should describe the methods for analysis and the tools required. Budget and schedule constraints, as well as completion criteria, should be included
  • Design Synthesis describes the methods to be used by the development teams to translate the functional requirements into a hardware and software design. A number of tools and methodologies exist for this. The specific ones to be used by the development team should be identified, along with the necessary resources. Describe the products to be produced as this process unfolds and the design review steps to be taken
  • System Analysis describes the methods to be used for any required technical trade-off studies, cost/benefit decisions, and risk mitigation alternative analysis. The methodologies used should provide a rigorous basis for selecting an alternative, a quantifiable basis for comparing the technical, cost, and schedule impacts of each alternative, and comprehensive description of the risks involved with each alternative.

5.0 Transitioning Critical Technologies

This section will describe the methods and processes to be used to identify, evaluate, select, and incorporate critical technologies into the system design. Since this may represent an area of considerable impact to the project, this is one of the major efforts of risk management.

The need for a critical technology may be based on a performance objective. It may also be based on other factors; the desire to reduce acquisition or maintenance costs; the need to introduce standard compliance; or the need to meet an operational objective. In some cases, the need may move away from a technology that is obsolete and no longer supported by industry.

Identification of candidate technologies hinges on a broad knowledge of the technologies and knowledge of each technology’s status and maturity. In other words, build on a thorough understanding of the pros and cons of each available technology. Obtaining the resource[s] capable of performing this step is one of the major risks encountered by project management.

Sufficient analysis of the risks and benefits of a particular technology may become a major effort involving acquiring the technologies, modifying the technology to meet system requirements, and developing methods to test and evaluate the various technologies that need to be considered. Each of these steps can introduce considerable risk.

Finally, incorporation of a technology into an operational system may involve considerable work, especially establishing the support and maintenance environment for the technology.

All of these aspects of technology introduction, especially introduction of novel technology, need to be carefully and fully addressed in the SEMP.

6.0 Integration of the System

This section describes the methods to be used to integrate the developed components into a functional system that meets the system requirements and is operationally supportable. The systems engineering process steps to be detailed here include: integration, verification, deployment, and the training necessary to support operations & maintenance. Plans for validation of the system should also be covered. For each step, the resources [tools and personnel] are identified and products and criteria for each step defined.

7.0 Integration of the Systems Engineering Effort

This section addresses the integration of the multi-disciplinary organizations or teams that will be performing the systems engineering activities. Obviously, the larger the number of such organizational teams, the more important the integration of their efforts is. Each team will have both primary and support tasks from the WBS. Each team will have to be aware of the activities of other teams, especially those activities that immediately precede or follow their own primary tasks. Representatives of most teams will have to be involved in critical technical reviews, and in the review of baseline documentation. Likewise, up-front teams [e.g. requirements and design] must be available to support the ending activities, such as, integration, verification, deployment, and training.


8.0 Applicable Documents

This section lists the applicable documents which are inputs to the project [i.e., needed but not produced by the project]. Such documents may include: the regional ITS architecture description, planning documents describing the project, agency procedures to be followed, standards & specifications, and other descriptions of interfacing external systems. Other applicable documents may be required by a specific project.

Related Task Examples Checklist  


Return to top
Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000