In the context of System Engineering, “traceability” is ancillary information establishing a trail of breadcrumbs from an Engineering output backwards to the input material from which it came. The concept is analogous to the manufacturing practice of the same name.
In this context, “Engineering output” includes both intermediate and final outputs. Types of intermediate outputs include, but are not limited to, requirements, trade studies, and design decisions. Because the list of candidate outputs is nearly infinite, no project applies traceability in an exhaustive manner1.
As a crude generalization, traceability is more frequently important at higher layers of a system’s architecture than at lower layers. However, it should be noted that lower layers usually contain the “Point of Implementation“: critical issues will often resolved there, for which traceability may prove important and useful. The imposition of traceability requires substantial judgment by Engineering Staff and Management.
If traceability includes rationale, it provides the following features:
– Auditability, which is important for all the usual reasons.
– Decisions can be re-visited when, as, or if the inputs change2.
– A contextual basis is available to resolve residual uncertainties of intent and interpretation during subsequent stages of development3.
– Closeout data can be traced backwards for publication in the form, combination, and context of each source. This is often useful to convince the individual authorities that their material has been dealt with from the correct perspective. It also relieves them of the need to comprehend an unfamiliar presentation of the material.
Traceability that does not include rationale is of little use other than scamming people into believing we did something that we might not actually have done.
Footnotes- Because the schedule, budget, and Engineering staff would all be exhausted before anything useful got done![↩]
- That is, the trail of breadcrumbs can be followed in both directions[↩]
- This can be a two-edged sword: making the rationale too readily available can also cause excessive turmoil when compiled and derived requirements are challenged for biased reasons. That’s why we do not usually include any rationale in the body of a requirement.[↩]