The Traceability Relationship

A traceability relationship is a relationship between two project elements.

The first definition above is a statement regarding the relationship of one element in the process to a successive element; the second is intended to assure that no superfluous elements (requirements, design, and so on) exist. In order to relate these elements, we need to introduce a third element, which is simply the element that relates the other two elements to each other. We call this element the traceability relationship . In other words, a traceability relationship is a relationship between two project elements.

There is no standard for exactly how a traceability relationship is constructed , how it is represented, what rules apply to it, and what attributes it exhibits. In highly complex, high-assurance systems developed under extreme software process rigor, this relationship can take on many facets. It may be navigable via tooling; it may contain a history of its existence; there may be many different types of such relationships (for example, "is fulfilled by," "is part of," "is derived from"); and there may be different types of relationships based on the types of related elements (for example, an explicit " tested by" relationship between A and B means that B exists to test A). If your team is operating in one of these environments, you will likely have process definitions, special tooling, and specific procedures you use to support traceability.

A traceability relationship is a type of dependency relationship between elements.

However, for most project teams , this overcomplicates the matter. It is usually adequate to think of the relationship in terms of a simple "traced" model. In UML terms, we would simply be looking in one direction or the other (upstream or downstream) at a type of dependency relationship ^[1] (Figure 27-1).

^[1] In the UML, a dependency indicates a semantic relationship between two or more model elements.

Figure 27-1. A trace dependency relationship

A dependency relationship states that a change in one element (for example, a use case) may affect another element (such as a test case), but the reverse is not necessarily true (a change to the test case would not necessarily imply that a use case needs to be changed). In other words, what happens upstream (a boat placed in the water) affects what happens downstream (the boat goes over the waterfall), but the opposite case is not true (no matter how many boats we place in the water downstream, the upstream system behavior is unaffected).

As another example, we can envision how a specific requirement in the system is created in order to support a given feature specified in the Vision document. Thus, we can say that a software requirement (or use case) is traced from one or more features (see Figure 27-2). In this manner, the traceability relationship fulfills both halves of the definition since it both describes the predecessor-successor relationship and establishes the reason the second element exists (to implement the feature).

Figure 27-2. Traceability link from Vision document to software requirement

Without complicating matters much further, additional meaning can be inferred from the context of the types of requirements being related. For example, even without a specific "tested by" relationship type, a software requirement that is traced to a test case would suggest that the software requirement is "tested by" the test case that it is "traced to." A use-case realization that is traced from a use case would imply that the requirement is "implemented by" the referenced collaboration.