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

3.7.3 Changes & Upgrades



This step allows the system's owner to evolve the system to keep pace with changing needs, advancing and changing technology, and/or add system capabilities over time. These changes & upgrades will be performed in a systematic way to maintain or establish system integrity. Integrity in context of systems engineering means that the system's functional, performance, physical, and enabling products are accurately documented by its requirements, design, and support specifications. The system documentation is accurate and sufficient to the point where changes & upgrades can be performed by any competent development team. This gives the system's owner the freedom to have the widest possible selection of development teams for evolving the system.


The guidance in this step will address upgrades that are planned and ones that are based on new stakeholder needs. This step will also give guidance on implementing upgrades on a system that has not been well documented [see integrity as defined in the objective above ]. This step will also give guidance on handling COTS products and applications which may have:

  • become obsolete
  • changed in design
  • aged beyond its contracted support life



Shows the flow for Phase [4] Task 3, Changes and Upgrades Process. Summaries are described for inputs, constraints, and enablers into the task; activities of the task; and outputs from the task. The flow is described in detail in the accompanying text.



Legacy System is the existing system to which the upgrade or change will be applied.

Legacy System documentation includes the requirements, design, and support documentation.

Change Request identifies the new change, upgrade needs, or requirements for the system.


Systems Engineering Management Plan [SEMP] is used if the upgrade is a planned upgrade and part of the development strategy.

Configuration Management Plan describes how planned and unplanned upgrades & changes would be evaluated, coordinated, and inserted into the legacy system.


Stakeholder involvement is important when the system is being changed/upgraded, and is essential if the changes & upgrades will impact the stakeholders in some way.

Traceability ensures that the integrity is maintained through changes & upgrades as well as supports cost estimation for making changes & upgrades to system.


Documented legacy system products in the areas of change & upgrade. If the legacy system has not been well documented before the change & upgrade, documented legacy system products are employed.

Updated system products and documentation for the new capabilities, as well as the impacted areas of the legacy system.

Process Activities:

Analyze needed changes & upgrades

Planned upgrades are executed IAW the systems engineering management plan [SEMP]. The SEMP may have a development strategy that lays out a plan for the evolution of the system over time. The plan may have several phases to the system evolution. For example, phase 1 may deploy the communications network. Phase 2 may deploy the CCTV [camera system]. Phase 3 may deploy the detection system and so on; until the system has been fully implemented. Each of these phases should be implemented using the forward engineering process.

Unplanned changes may be the result of a change in needs, technology obsolescence, requirements, or new stakeholder participation. If the system was well documented, the changes should be implemented using the forward engineering process. The system's owner's configuration management process will lay out how the changes will be evaluated, coordinated, and inserted into the system. If the system was not well documented, the reverse engineering process should be performed as described below. An analysis of the legacy system and its documentation is needed to assess to what extent, if any, a reverse engineering process is needed.

Reverse engineering

Reverse engineering is documenting the legacy system [the system being upgraded/changed]. This includes the interfaces [both internal and external to the system], hardware, software, and support products [original development tools, test plans, and traceability matrix]. This process requires one to

  • analyze the system's functionality, examine the software [source code]
  • inspect the hardware
  • create or recreate a set of requirements and design documentation that matches the system as it currently exists

Forward engineering

Forward engineering is the process of following the Vee Development Model as defined in chapters 3.3-3.7 of this guidebook. All changes & upgrades to the system start with the update of the systems engineering management plan, concept of operations. They are followed by the requirements, sub-systems, high-level design, and detailed design. When evolving, upgrading, or implementing changes to a legacy system, it should be in a forward engineering approach as suggested in this guidebook.

Illustrates where Changes and Upgrades occur in the Vee Development Model. Changes and upgrades are defined in the Concept of Operations section. Changes and upgrades are performed in the Changes and Upgrades section as described in Chapter 3.2.1-3.7.1.

Where do the Changes & Upgrades take place in the project timeline?

Is there a policy or standard that talks about Changes & Upgrades?

This task would include all of the tasks from phase [-1] to 4 including all FHWA Final Rule requirements and standards.

Which activities are critical for the system's owner to do?

  • Perform the critical activities for the system's owner as described in Chapters 3.2-3.7
  • Elicit stakeholder involvement for the reviews of the products coming out of the reverse engineering process
  • Elicit stakeholder involvement in the workshops that are held during the reverse engineering process

How do I fit these activities to my project? [Tailoring]

In the reverse engineering process, first identify the areas which are going to be impacted by the upgrades and changes. Those areas should be the focus of the reverse engineering activities. This will tailor the activity to only the affected areas of the legacy system. [See below – Are there any other recommendations that can help?]

In the forward engineering activities, apply the tailoring guides identified in Chapters 3.2-3.7.

What should I track in this process step to reduce project risks and get what is expected? [Metrics]

On the technical side:

  • For reverse engineering, identify and track the extent of impact [e.g. number of software modules that need to change, number of interfaces that need to change] to the legacy system. This will help in estimating the effort to implement the changes
  • For forward engineering activities, all of the technical metrics identified in Chapters 3.3 -3.6 are recommended for tracking

On the project management side:

  • Reverse engineering is a discovery and a documentation effort. A task order contract with milestones is a way to track progress for this type of project. For example, the task is to document the software architecture in 6 weeks. By week 2: document the top level software structure. By week 4: document interfaces between major software modules. By week 6, document the next level software modules.
  • For forward engineering activities, all of the project management metrics identified in Chapters 3.2-3.7 are recommended

Checklist: Are all the bases covered?

check Is there a change management process in place?
check Is the documentation for the legacy system available?
check Have the upgrades and changes been clearly identified?
check If this has been a planned upgrade have the systems engineering management plan, concept of operations, requirements, and test plans been reviewed and updated?
check If this is a new capability that is added to the system, have the systems engineering plan, concept of operations, requirements, and test plans been developed for this new capability?
check Does the upgrade/change impact the project architecture? If so, is the updated project architecture consistent with the regional architecture?
check Prior to applying changes/upgrades, have the impacted areas of the legacy system been documented to a level that the changes/ upgrades can be applied using the forward engineering process? [as described in Chapters 3.2-3.7

Are there any other recommendations that can help?

Tip.Recommendation.If reverse engineering on a legacy system is needed, it should be done only to the areas that will be affected by the changes/upgrades. On major systems it may be too costly to document the entire legacy system for minor upgrades and changes. The cost effective approach is to document as needed. Over time, as changes are made, more of the system will be documented. Those areas that never get changed will not be documented.

Continue the reverse engineering process through the implementation of the changes. The reverse engineering process will document the obvious impacted areas of the legacy system that changes/upgrades will be applied to. As the changes are applied to the affected areas, the implementer must check and continue the documentation effort. Changes to a system may impact areas not intended for change or affect these areas in a subtle, unanticipated way.

It will be the implementer and test support that will most likely uncover these types of issues. They must be ready to identify and document these areas.

A closer look at reverse engineering and COTS products and applications

Reverse Engineeringis documenting an existing Intelligent Transportation Systems functional requirements [what it does], physical characteristics or design [how it does it], and the way it was built and maintained [enabling products]. Legacy system documentation may not have been complete, lost or over time, or was not kept up to date. Traditionally, system's owners would use the system to the end of its life and start over. Today there is a regional focus on multiple agency involvement, fast-paced changes in technology, and constrained budgets. Systems owners are being driven to evolve their systems and to have greater latitude in development team choices [whether this is done in-house and/or contracted]. In such situations, reverse engineering may be a good alternative to starting over.

Reverse engineering for COTS products and applications focuses on interfaces and modularity. Examples of some common elements: workstations and operating systems, databases, changeable message signs, cameras, communications, and detection & traffic control systems. Custom developments focus on user interfaces, data structures, distribution, and applications that analyze, exchange, and translate information. Both the forward and reverse engineering activities should focus on allowing these COTS products to be updated/changed as they become obsolete, have changes to design, or reach the end of their service life. Database management system [DBMS] is a good example of this. When the DBMS reaches the end of life, the system's owner can choose to stay with the existing DBMS now unsupported, or move to the latest version of the DBMS. If the system's owner chooses to upgrade, the impact may affect the current operating system and computer hardware. This, then, would impact other applications like the user interface, drivers for the camera system, changeable message signs, and communications. By keeping the applications modular, and interfaces [both internal and external] well defined, the impacts of obsolescence can be minimized.



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