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


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.9.11 Traceability

 

OBJECTIVE:

Traceability ensures that user needs and concepts are addressed by a set of requirements and that the requirements are fulfilled by the high level and detailed design. Traceability also ensures that system and sub-system requirements are fully verified. Traceability supports impact analysis and configuration management for long term maintenance, changes & upgrades, and replacement to the system.

DESCRIPTION:

Traceability follows the life of a requirement throughout the life of the system. Each requirement is traced to its parent requirement and to its allocated sub-system requirement [bi-directional traceability]. User needs and requirements are also traced to their associated verification & validation plans. The following are three aspects of traceability:

1) Pre-Requirements Specification traceability [Pre-RS traceability] in which user needs are traced to a set of system requirements

2) Post-Requirements Specification traceability [Post-RS traceability] in which traceability ensures compliance after the system requirements baseline has been established

3) Post delivery traceability [Post-Delivery traceability] in which traceability is maintained after delivery of the system;  supporting changes & upgrades, and replacement activities.

CONTEXT OF PROCESS:

 

Shows the flow for cross-cutting activity Traceability 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.

TRACEABILITY PROCESS

Inputs:

User needs/requirements the initial needs and wants of the stakeholders.

Concept of Operations & Validation artifacts detailed concepts needed by the system and associated validation that will meet the stakeholder needs.

System and sub-system requirements, verification plans, and procedures requirements, associated verification cases for each requirement to be verified,  and the procedures for verification

Detailed Design & Implementation artifacts "build-to" products used for implementation and fabrication of the system elements and associated Software and Hardware implementation artifacts [source code, fabrication drawings]

Support artifacts related documentation needed to maintain and operate the system [users & maintenance manuals, external requirements e.g. traceability to the regional architecture, safety requirements]

Control:

Project Plan/SEMP defines the extent of traceability needed for the project. For example, safety critical systems will need more comprehensive traceability to ensure compliance with safety requirements.

Enablers:

Requirements Management Tools enable the management of traceability through compliance and changes

Configuration Management supports management decisions using traceability

Outputs:

Traceability Matrix documents the traceability of the requirements and related artifacts

Compliance reports analyze all links to ensure that there is no orphan or unsupported requirements.

Disposition of orphan and/or unsupported requirements all orphan and unsupported requirements are identified and the disposition determined for each [e.g., remove or add new requirements]

Process Activities:

Pre-RS Traceability

Traces user needs/requirements and concepts to system requirements. When user needs/requirements are prioritized, this tracing enables the system requirements to inherit the priority of the user needs, supporting system requirements prioritization schemes. When user needs/requirements change, traceability supports technical, budget, and schedule impact assessments. Traceability is bi-directional, in that not only all the user needs and requirements trace to system requirements, but that all system requirements can be traced back to an associated user need/requirement that unsupported requirements are not inadvertently inserted. This bi-directional traceability is applied to all requirements at every level.

Define extent of Traceability

Determine the extent of traceability needed based or the criticality or regulatory issues of the system.

Post-RS Traceability

Post Requirements Specification traceability activities begin when a requirement baseline established. This includes tracing system requirements through sub-system requirements, design, implementation, and verification. Traceability enables the system owner to determine if all requirements are being implemented and verified. Traceability is used to determine the development team’s compliance to the requirements and that all contracted functionality is verified. Changes occur during development, traceability supports the technical, budget, and schedule impact assessments. Traceability supports the impact of changes during the verification by determining how much regression testing is needed to satisfy the changes. Bi-directional traceability shows that system requirements are addressed by sub-systems, and that all sub-systems have supporting system requirements. Traceability can be used to trace to other supporting project artifacts as well, such as user & maintenance manuals, training, deployment, logistics, and production products.

Post-Delivery Traceability

Post-Delivery traceability is used to maintain the system. This activity continues though-out the life of the system. Traceability supports technical, budget, and schedule impact assessments when changes and upgrades are needed, and extends into replacement and retirement of the system. Traceability is used to demonstrate integrity of the systems by verifying that the functional and physical characteristics are traceable to its associated requirements and design documentation.

Illustrates where Traceability Process occurs in the Vee Development Model. The extent of traceability is defined in the Systems Engineering Management Plan Framework section. Pre-RS traceability occurs in the Concept Exploration; Systems Engineering Management Plan Framework; and Concept of Operations sections. Post-RS traceability occurs in the System Requirements; High-Level Design (Project Architecture) Subsystem Requirements; Component Level Detailed Design; Software Coding Hardware Fabrication; Unit Testing; Subsystem Verification; System Verification and Initial Deployment; and System Validation sections. Post-delivery traceability occurs in System Validation; Operations and Maintenance; Changes and Upgrades; and Retirement Replacement sections.

Where does traceability take place in the project timeline?

Is there a policy or standard that talks about Technical Reviews?

FHWA Final Rule does not specifically mention the practice of traceability. However to show compliance that the project is implementing a portion of the regional architecture, traceability can be a key method to show this compliance. CMMI lists traceability as an effective practice and an industry best practice.

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

  • Ensure that appropriate requirements management tools are in place.
  • Ensure that staff is trained to manage the traceability over the life of the system.
  • Review of the traceability compliance reports.
  • Lead the review decisions and actions, on any orphan or unsupported requirements issues
  • Lead in determining the extent of traceability needed for the project.

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

Tailoring the traceability activity is dependent on the extent of the requirements and verification and the extent that traceability is needed to other documentation.

In small projects, traceability can be achieved by using a simple spreadsheet as a tool for traceability e.g., fewer than 100 user needs/requirements and system requirements.

For larger projects [ a 100 or more requirements], it is recommended that a commercial off the shelf requirements management tool be used for traceability.

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

Technical and project management:

  • Track the number of unsupported and orphaned requirements.
  • Track the trend in the number TBD requirements. [un-traced needs/requirements]
  • Track the trend in the completeness of requirements traced to appropriate user needs/requirements and high level design.

Checklist: Are all the bases covered?

  • Is a requirements management tool needed for the project?
  • If a requirements tool is needed, has it been procured and configured for the project?
  • Is the staff trained on the use of the tool?
  • Is access to the requirements management tool available to all stakeholders and the development team?
  • Has the extent of traceability been defined?
  • Are all user needs/requirements traced to system requirements?
  • Have the concept of operation scenarios been traced to the system requirements and the validation plan?
  • Have the system requirements been traced to the system verification plan?
  • Have the system requirements been traced to the high level design?
  • Has the high level design been traced to the sub-system verification plans?
  • Has the high level design been traced to the detailed design?
  • Has the detailed design been traced to the unit verification plan/procedures?
  • Has the detailed design been traced to implementation artifacts [SW source code, HW documentation etc]?
  • Have the verification procedures been traced to the verification plans at all levels?
  • Has all needed supporting project documentation been traced?
  • Has traceability been maintained during the operations & maintenance, changes & upgrades, and retirement & replacement?

Are there any other recommendations that can help? For projects that have 100 system requirements or more, procure and use a requirements management tool to capture, trace, and manage the project requirements.

  • The tool should be installed and configured in the early stages of the project
  • Staff should be trained in the use of the tool
  • The tool should have the capability such that the staff in all districts have access to the tool
  • The tool should be able to trace within and between classes of the schema.
  • The tool should support document generation, or interface with a document generation tool.
  • The tool should provide a change management capability where stakeholders can recommend changes to requirements and traceability.

For small project [less than 100 requirements], a spreadsheet may be used to capture and trace requirements. A schema must be defined on what are the naming conventions and how the links will be identified. This is a low cost approach but in the long term it may be more labor intensive. The choice of the tools should be determined on the long term growth of the system.

A closer look at using requirements management tools for traceability.

There are a number of requirements management tools on the market.[see appendix 7.2.5 for a list of requirements engineering tools] A basic capability of all these tools is traceability. Requirements management tools need a database to support the tool. Most of them today use a commercial database such as Oracle, but a few requirements management tools still uses their own proprietary databases. This can be an issue for portability and agency standards. These tools require an up front investment in procuring a license and in staff training. The range in cost from $10K-$15K dollars [license & training] plus staff time in the set up for each project. In most tools a database scheme needs to be developed for each project [A couple tools provide a generic project set up that can be used or modified.].

Part of the project planning and definition is the identification of the requirements attributes. The requirements management tool supports this by allowing the systems engineer to define as part of the tool, the classes that the project wants to capture for example, Systems Requirement, Systems Verification, and the bi-directional links between these classes allowing traceability.

Once a requirements management tool is set up it will require staff to maintain and keep it up to date. The tool will also require an on-going maintenance contract to receive updates and support. In the long term, requirements management tools can be a good investment in saving time and budget when assessing changes to a system, required testing, and verifying compliance of the system to requirements.

 

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