Traceability defined
I first was introduced to traceability years ago by Karl Wiegers in Software Requirements (First Edition) and was immediately sold on the impact it brings to a project. As important as it is, I noticed that few projects actually did it. I’m in a position now where I do apply it, and I find the basic fundamentals are still the same.

Traceability is nothing more than being able to define and track the relationship between two objects. Typically, there is a “derived from” relationship between the two objects, and you trace the link from the original item to the thing that was created from it (or vice versa).

Common traces
In software development, traceability provides a link within and between the objects that capture business needs, use cases, requirements, design, code, test cases, etc. For illustration, some common traces we see are between business needs and use cases, between use cases and requirements and within requirements to other requirements. In theory, you can also link from the requirements to the downstream software work products, such as design, code and tests, but I think it is significantly less common to see projects do that.

It goes both directions
There are two ways to trace – forwards and backwards. Forward traceability answers the question “What objects are derived from this object?” For example “What use cases address this need?” or “What requirements are impacted by changing this use case?” Backward traceability answers the question “Why is this object here?” For example “What use case makes this a requirement?” or “Why do we have this code?”

Why trace?
In deciding whether to trace or not to trace, it is important to understand the value behind it, because it can be time consuming. An appropriate approach is to think about the actual use cases for the traceability to understand what questions need to be answered on your project.

Here are some common suggested use cases for traceability. I’ve also captured the direction of tracing you need to accomplish each trace.

• Product manager needs to identify missing requirements (forward)
• Product manager needs to identify requirements that are out of scope (backward)
• Developer needs to determine what requirements are not coded yet (forward)
• Project manager needs to ensure developers are not putting development efforts into non-requirements (backward)
• QA needs to identify what requirements are not yet tested (forward)
• Developer needs to determine what code is impacted by a change in a requirement (forward)
• Product manager needs to determine what need is not met when a requirement cannot be developed (backward)
• Product manager needs to ensure there are no missing use cases that lead to missing requirements (backward then forward)
• Business sponsor needs to ensure all requirements are included in the release (forward)

If you need to be able to answer any of these questions, then it’s that simple, you should set up the appropriate tracing.

I need it, but now what?
To implement traceability on a project, it is important to start as soon as is possible in the project. Ideally the infrastructure will be put in place during the planning phase.

A few fundamental rules should to be followed for traceability to work:

• All elements to be traced must be labeled uniquely (UI Screen IDs, Use Case IDs, Requirement IDs, etc.)
• The team members must have time allocated to fill in the actual traces, each filling in the trace information for their respective artifacts
• The elements must each be clearly defined (with clean boundaries), so that there are obvious traces forward and backward
• If tracing from requirements to testing, the requirements must be testable

Tools
Traceability can be implemented with a variety of tools. Specialized requirements management tools make it easier to maintain and analyze the large number of traces that exist in any project of moderate or large size. Spreadsheets require a tremendous amount of manual effort, but they can be used when necessary.

One way to represent traceability in a spreadsheet is to do all traces in one matrix. In this traceability format, one object type is traced to many other object types. This will work best for simple tracing, where there is a one-to-one or one-to-many relationship to be analyzed. For example, in this case, the requirements are traced to test cases, and it is easy to see that there is a requirement that does not yet have a test case.

In the following table, I’ve added another column, to represent tracing from requirements to use cases. We are really only looking at the one-to-many relationship here of requirements to use cases (even though it is actually a many-to-many relationship), and therefore we can quickly see if there are requirements that do not map to use cases. However, in this view, it is challenging to see what use cases are missing requirements. If you set it up so that you can filter by each use case ID, then it will identify those holes more clearly.

Another way to easily represent this many-to-many trace in a spreadsheet is to do each trace in its own matrix. In this traceability format, you trace one object type to one other object type. If you want to do additional traces to other types of objects, you use a different matrix for each of those pairs. In this example, it is still easy to see that one requirement does not map to any use cases, but furthermore it is obvious that one use case appears to not have many requirements. That would be a trigger to look more closely at the use case to ensure a full set of requirements were captured for it.
Why traceability is valuable
Much of the value in doing traceability comes from the ability to identify holes – such as missed functionality or tests. Tracing also helps ensure you are building only the true requirements. Many organizations are not putting the effort into defining the traceability mappings during the requirements gathering phases, and therefore, are going beyond budget and timelines, or worse just deploying the wrong software.

Check back soon for a post on the different object types and their relationships used in requirements gathering!