U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
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.
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:
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]
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.
Requirements Management Tools enable the management of traceability through compliance and changes
Configuration Management supports management decisions using traceability
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]
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 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 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.
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?
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:
Checklist: Are all the bases covered?
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.
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.