The Trouble with Tracing: Traceability Dissected

• over working software and contract negotiation over customer collaboration
• It makes it harder to make necessary changes and encourages rigidity rather than flexibility
• It assumes a waterfall-based lifecycle with end-of-phase hand-offs to different functional groups,
• It increases the amount of “software waste” for time spent seeking information and increases the duration and amount of “inventory” (partially completed, “in progress” functionality)
• It doesn’t readily fit iterative development working in short-cycles with close customer collaboration

Eight Reasons for Traceability
If traceability is so much work, and if the return-on-investment is so hard for so many to see, then why do we bother? Or rather, why should we bother? Other than obvious contractual obligation, legal liability, or the fact that various CM and software engineering tomes declare “thou shalt have traceability,” what real needs does it serve? What does it let me do that I couldn’t otherwise do very easily? Several reasons commonly given are:

• Validate we built what the customer actually agreed to pay us to build, that we built the “right thing” and that we “did things right” when building it
• Verify that we delivered every file and feature/fix that we said we would, and nothing that we said we wouldn’t
• Identify and isolate a set of changes that were made, and be able to either back-out the change from an existing version, and/or reintroduce the change to other versions
• Assess the impact upon the design, code, tests and other aspects of the system for a proposed change-request (this in turn helps us determine effort, risk, cost, and the other affected groups)
• Maintain an audit trail about who did what, when, where, why and how - so we can prove what we should and shouldn’t be held accountable for when the customer, or management or some other formal authority demands to know, or claims that we didn’t something we shouldn’t have, or for invalid reasons
• Capture everything necessary to identify exactly what was delivered and repeat the steps necessary to reproduce it again
• Report status of our activities to the customer and to management for the features and fixes that we are currently working on, so they can evaluate the progress and risks in delivering the project
• Retrace our steps regarding something we did poorly, or that we simply didn’t know to pay attention to before, so we can identify root causes and learn how to prevent and/or correct it in the future

Those are all some pretty good reasons. Does that really justify why some of us have to maintain a traceability matrix? Is that really the most effective way?

Even agile development is 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 through 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.

The Seven Functions of SCM
To revisit why any of those reasons are valid, it may help to revisit just exactly what Software Configuration Management is and what functions it fulfills. Most standard definitions of CM will cite the basic four elements of hardware and software CM as defined by IEEE and military/government standards:

• Identification: identifying and defining the structure of and relationships between the items or components that we must build

• Control: controlling the release of a product and changes to it throughout the lifecycle

• Status Accounting: recording and reporting the status of components and component changes

• Audit and Review: verifying the correctness and completeness of a product delivered and the consistency of its components

More