Traceability and TRUST-ability

Traceability is one of those words that evokes a strong "gag" reflex among many hardcore agilists. They are all in favor of tracing tests to features, which is extremely straightforward when one is doing test-driven development (TDD). When it comes to tracing requirements thru to design and code, images of manually maintained traceability matrices that are hopelessly effort-intensive and never quite up-to-date seem to spring to mind.

So what are the main goals that traceability supposedly serves? Based on sources like CMMI and SWEBOK, and several others, I think the goals of traceability are to assist or enable the following:

1. change impact-analysis: assess the impact and risk of a proposed change to facilitate communication, coordination and estimation [show the "know-how" to "know-what" to change, "know-where" to change it, and "know-who" will change it]


2. product conformance: assure that necessary and sufficient requirements were implemented, and ensure the implementation of each requirement was verified/validated [prove we "did the right things" and "did the things right"]


3. process compliance: assure that the necessary procedural activities (e.g., reviews and tests) were executed for each feature/requirement/code-change and ensure they were executed satisfactorily [prove we "walk the walk" and not just "talk the talk"]


4. project accountability: assure that each change of each artifact was authorized and ensure that they correspond to requested functionality/business-value [safeguard against "gold plating"]


5. baseline reproducibility: assure that the elements necessary to reproduce each baseline have been captured and ensure that the baselines can be reproduced [so "all the king's horses and all the king's men" can put your fallen "humpty-dumpty" build back together again]


6. organizational learning: assure that the elements necessary to rediscover the knowledge of the system have been captured and ensure that the rationale behind critical decisions can be reproduced -- e.g., for root-cause analysis, or to transfer system knowledge to a deployment/support team. ["know-why" you did what you did when you did it]

Many would argue that these all boil down to questions of trust, and communication:

• Do I trust the analysts/architects to do what I said and say what they did?


• Do I trust the product or its producers to correctly realize the correct requirements?


• Do I trust the process or the engineers following it?


• Do I trust the project or the people managing it?


• Do I trust the environment in which it is built and tested?


• Do I trust the organization to be able to remember what they learned and learn from their mistakes?

Whether or not traceability efforts successfully achieve any of these goals is another matter entirely. Often, traceability efforts achieve at most one of these (conformance), and sometimes not even that. Many question whether the amount of effort required actually adds more value than what it subtracts in terms of effort (particularly when traceability efforts themselves may create additional artifacts and activities that require tracing).

Traceability is often desired because it's presumed to somehow alleviate fears and give us "TRUSTability." I suspect that's really an illusion. Traceability is useful to the extent that it facilitates more effective communication & interaction between individuals, teams, and stakeholders. And traceability can be useful to the extent that its helps us successfully convey, codify and validate system knowledge.

So to the extent that traceability helps us more quickly identify the right people to interact with and the right information to initiate that interaction, it can be extremely useful. It is the people and the quality of their interactions that provide the desired "trustability." Beyond that, unless unintrusively automated, it can quickly turn into "busy work" with very high "friction" on development of new functionality realized as "working software".

To that end, I have a few slides in a presentation I gave on Agile Configuration Management Environments (see slides 24-25) that talk about "Lean Traceability", and a big part of that is using encapsulation, modularity, and dependency management (a.k.a refactoring) to track at the coarse-grained level rather than a fine-grained one. This alone can reduce the traceability burden by 1-2 orders of magnitude. A more detailed discussion is near the end of the paper The Agile Difference for SCM.

The LoRD Principle is also mentioned (LoRD := Locality of Reference Documentation). You can read more about LoRD on the Wiki-Web, in Volume 3 of the Agile Times (pp. 37-40), and in Scott Ambler's essay Single Source Information. For automating traceability, there is some interesting work from the DePaul University Applied Requirements Engineering Lab and the SABRE Project (Software Architecture-Based Requirements Engineering) on the subject of dynamic event-based traceability.