| Related: |  |
Traceability is a cross-cutting activity that connects the various systems engineering activities with each other. Traceability is a key principle of systems engineering; it documents bi-directional relationships of project artifacts that allow backwards traceability to points of origin and forward traceability to the final system. The goal of traceability is to provide better quality and consistency of system/product development. It brings the ability to verify the history, location, and application of an item by means of documented identification.
A non-SE example of traceability is the food supply chain. If there is a problem with a food product, there is documented traceability back to the source of origin of that food product as it traversed the food supply chain. This may result in a food recall that goes beyond that particular food products creation.
Traceability follows the life of a requirement throughout the life of the system. The user needs are traced or related to the requirements which are traced or related to the design, which are traced or related to the implementation, which are traced or related to the testing, which are traced or related to the final system. The traceability is bi-directional; the initial items are traced forward to the latter items and conversely, the latter items are traced backward to the initial items. User needs and requirements are also traced to their associated validation and verification plans. Traceability is maintained after delivery of the system, supporting changes and upgrades, as well as replacement activities.
The following checklist can help answer the question “Are all the bases covered?” once the activities above have been planned or performed. The checklist is not sufficient by itself.
R Has the extent of traceability been defined?
R Are all user needs traced to system requirements and vice versa?
R Have the concept of operation scenarios been traced to the system requirements and the validation plan?
R Have the user needs been traced to the system validation plan?
R Is a requirements management tool needed for the project?
R If a requirements tool is needed, has it been procured and configured for the project?
R Is the staff trained on the use of the tool?
R Is access to the requirements management tool available to all stakeholders and the development team?
R Have the system requirements been traced to the system verification plan?
R Have the system requirements been traced to the design?
R Has the design been traced to the verification plans?
R Has the design been traced to implementation artifacts [SW source code, HW documentation etc.]?
R Have the verification procedures been traced to the verification plan?
R Have the validation procedures been traced to the validation plan?
R Has all needed supporting project documentation been traced to?
R Has traceability been maintained during the operations & maintenance, changes & upgrades, and retirement & replacement?
For projects that have roughly 100 system
requirements or more, procure and use a requirements management or a database
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 all staff 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.
| Related: | |
