Published November 25, 2022
by Doug Klugh

Tracing Compliance

Establish navigable links (relationships) between artifacts to provide visibility into the software development process and contribute to a better understanding of the software under development.  This insight is often achieved through change impact assessment, coverage analysis, and dependency analysis.  Artifact types can include models, requirements, designs, implementations, test cases, tests, test results, changesets, builds, deployments, etc.  An artifact can be a whole object or any internal delineation within an object.  Hence, the granularity of artifacts often varies greatly, even within a single system.

Whenever a feature fails, traceability enables your team to quickly determine how the requirements for that feature were defined, designed, coded, tested, and deployed.  This will greatly enhance Defect Localization — your ability to quickly determine what went wrong and where.

Traceability will also help to determine the impact of a given change to the system.  For example, if you were to change the signature of a controller, service, or API, you could easily determine which methods, components, or integrations would need to be modified.  You could also quickly determine if that change would violate any requirements and which tests would need to be rewritten.

Discovering gaps in the design, implementation, or testing of requirements is greatly enhanced with traceability.  While the design may be complete, there may be gaps in the implementation.  Or the implementation may be complete, but it never got tested.  Having traceability is a good way to ensure due diligence in your software development process.

Tracing artifacts to and from requirements can often be a little tricky and somewhat tedious.  Each requirement must be uniquely and persistently identified.  So once a suitable identifier has been chosen, it cannot change for the life of the requirement.  Therefore, it is important that you not rely on automated, hierarchical headings in Microsoft Word^® for requirement identifiers.  They change automatically when you add or delete a requirement, breaking the persistence.

It is also important that requirements are written as concisely and simply as possible, ensuring that each requirement expresses only one function or idea.  For example, although the following requirement seems to be simple, it will not facilitate effective traceability:

1.2.3  Feature XYZ must be fast and easy to use

Besides the fact that it uses unmeasurable, weak terms, this statement contains two distinct requirements.  These requirements need to be separated and labeled with unique (and persistent) identifiers.

Changing the identifiers (for any type of artifact) will break traceability, causing it to become corrupted and worthless.