Agile Configuration Management (4): Traceability is Not a Matrix!

In software development, Traceability is a very famous term, specially in companies implementing CMMI-based process improvement.  Usually the concept is substituted for another term, which is the 'traceability matrix'. Most probably it was originally proposed as example implementation of what is coined as 'Requirements Traceability'. Later on, it became the de-facto implementation of requirements traceability, and finally replaced the original concept in the heads of many!

The fact is, traceability is not a matrix! This is true, specially if you want to make value of this very important technique. Rather, it is a dynamic network of relationships, in which requirements have a grawing set of relationships to all other artifacts in the project. 

Traceability is a Dynamic Network, Not a 2-Dimensional Simple Matrix

Consider the following network of relationships, which is typical in any software development project:

  

As you can see, any requirements is related to so many other concepts, artifacts, or other workitems. Requirements entities can trace to each other (white), and trace to other information (green), and or trace to physical artifacts (gray). A single requirement may be traceable to tens of other artifacts, and in turn, each one may of them may be traceable to some others. 

What Value Does Traceability Add?

Traceability empowers the team to do three very important activities:

1. Root-cause Analysis:

If there is a defect reported by a customer, and we want to know its root cause. According to the scenario below, the defected code is traced back to the reasons of change, which is found to be a change requested by the customer sometime ago. Other information about the change request can be deduced.

This is also called Backward Traceability.

In healthy configuration management environments, defects can be easily traced back to the code, change requests, and many other information, which may enable the team to identify the real reasons behind the defect. 

2. Impact Analysis

Traceability enables the team to study the impact of a change and assess its costs and risks. In the scenario below, the customer requests a change on an already implemented user story. To assess the change, the team revisits the written code, the impacted design and products, etc.

The team assesses the cost of the change request, by evaluating the changes incurred on all artifacts which will possibly change due to this request.

This is also called Forward Traceability.

3. Requirement Completeness Assessment

The third value-add from traceability is to assess whether all requirements are complete with respect to some other artifact, like design or test cases. So, by simple query, we can deduce which user-story or change request which still do not have any related test cases or design artifacts. 

Implementing Traceability

Traceability can be implemented by special propose requirements management tools, like Rational RequisitePro, Doors, or Rational Requirements Composer. Another way which is more lean and equally effective is to use workitem tracking system capabilities like:

• Workitem-workitem links
• Workitem hyperlinks to external documents on version control or shared folders,
• Workitem links to code change-sets or code revision numbers

In fact, in Agile environments, implementing traceability takes very little overhead. There are techniques to minimize the overhead for linking artifacts and build the traceability network seamlessly. Many of these techniques are exercised in the Agile Configuration Management Workshop, which I deliver at SECC.