Figure 1  - Overview of the Traceability Model

Figure 1 – Overview of the Traceability Model

Requirements traceability has always been a special passion of mine.  The process saved my bacon at least once when I managed projects.  Agile methods have complicated how one approaches the concept of traceability.  I do not think it reduces the need but changes the palette of approaches.  ‘Traceability:  A Radical Approach Based on User Involvement’  is my approach to sorting out the ramifications of customer involvement, complexity and criticality.  Your comments and thoughts are welcome as I try to sort this out.


Traceability is a core tenant of the requirements management process area in the CMMI.  Why is the effort to ensure traceability worth the investment? While there are many uses and benefits, at its most fundamental, traceability allows projects to know that what was planned was installed and what was installed was planned.  In one shape or another, the concept is hard to argue with; the problem is that “doing it” is not very easy and construed to be expensive. Many of the trappings of process discipline are viewed as overhead.  Many of these items are concentrated on the side of controlling behavior.  There is a need to create versions of tracking, planning and status reporting that meets the requirements of the model while facilitating work rather than slowing it down.  When the CMMI is interjected into the process landscape traceability becomes a lightening rod for the overhead discussion.

Even when traceability meets the overall organizations needs, the perceived value of traceability depends on the individual groups involved.  The burning question is whether (assuming a benefit really exists) that the benefits accrue to all groups involved equally?  Is the effort equivalent to the value?  Can the value proposition be scaled so that all projects all groups can derived more value than effort?  Scalability has become even more a burning issue as IT groups have embraced Agile methodologies. Traceability is a difficult concept to define for all types of projects and equally difficult concept to sell to all stakeholders in the world of projects.   ‘Traceability:  A Radical Approach Based on User Involvement’ suggests an approach to scalability based on balancing user involvement, risk and control needs.  This approach seeks to balance the effort required to trace requirements with the value of doing it.  This approach makes traceability less of a lightening rod for process improvement and a salable concept.

A Proposed Model To Scale Traceability

The model scalability is driven by the evaluation of these common attributes:

  • Customer Involvement
  • Complexity
  • Criticality

The evaluation of customer involvement need to encompass not only quantity (how much they are available) as well as quality (are they correct kind, can they make decisions).

Questions I am posing include:

  • What are the components of complexity that you would perceive as impacting the level of traceability?
  • What is the qualities of customer involvement must be incorporated into the discuss (covariance with involvement axis)?
  • Super customers only . . . How does the quality of the customer enter into the discussion?
  • What would using customer involvement (and complexity and criticality) as a means of scaling traceability satisfy REQM SP  in an assessment?