3.9.11 Traceability

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.