The Trouble with Tracing: Traceability Dissected

through these rings, across the drawbridges and into the fortresses.

Great! Now we know more about the 4 levels of scale/diversity of our stakeholders, the 5 orders of information to track, the set of 6 stakeholder views and concerns to target, the 7 functions of SCM to serve, 8 good reasons for, 9 common complaints against, and 10 commandments of traceability. That still doesn’t tell us what makes it so darn painful!

The Three Driving Forces for Traceability

If trust is the motivating goal, transparency is the means to achieve it, and traceability is a mechanism to provide transparency, what is it that makes traceability a necessary mechanism rather than simpler alternatives that might yield transparency without all the pain of traceability?

If everything could just be simple, we’d need only one team, have only one target audience, immediate visibility or status/results, and easily understood information in small batches. The reality is that things often aren’t that simple. Issues of scale and diversity rear their ugly head along all these different dimensions (SCM functions, stakeholder facets, communication rings, etc.). As projects, systems, and organizations get larger and more diverse, the following issues always seem to rear their ugly head:

• Organizational Boundaries -- the more layers of organizational hierarchy or bureaucracy I have, the less direct visibility there is to those in the position of greatest-decision making power and control. The less visibility I have into the "goings on" of the project, the less likely I am to trust it. People often do not readily trust what they cannot readily see.
• Feedback Cycle-time -- the more time that passes in between the time that I ask for something (or from when I know the work starts) and the time to when I receive it or hear about its status, the less likely I am to trust it.
• Knowledge Complexity -- the more complex something is, the less confidence I have that it does what I expect.

All of these impede the ability to efficiently and accurately communicate and respond to change. And they reduce the visibility, transparency, and frequency of available information. It becomes harder to see what we care about, and harder to locate those concerns among what limited information we can see.

Two Overarching Objectives – Transparency & Identification
That’s what traceability is really trying to accomplish in a nutshell:

• Transparency: the ability to readily view all the information we are concerned with, and then …
• Identification: the ability to identify our concerns so we can separate independent sets of concerns and cohesively associate the related ones.

Traceability aims to provide transparency by tracing the linkages through the complex quagmire of requirements through all intermediate artifacts and finally running and tested code. Transparency is what ultimately helps us resolve the issue of visibility issue, and the information structure is what organizes and identifies the set of concerns to track and navigate:

• Architectural (structural) transparency helps us identify and analyze change-impac
• Functional (behavioral) transparency helps us identify and analyze product conformance
•  Process (procedural) transparency helps us identify and analyze process compliance
• Project (managerial) transparency helps us identify and analyze project accountability
• Build/Baseline (physical) transparency helps us identify and analyze reproducibility
• Decision-making (logical) transparency facilitates organizational learning and root-cause analysis

The Role of Tools
Executing traceability reports surfaces the invisible, opaque and translucent and presents them to us while letting us select, sort, and filter on the entities vital to our role or perspective: requirements, designs, code, tests, requests, changes, projects, configurations, etc.

Tools play a crucial role in achieving traceability and transparency. Tools help us both create and maintain