Of course, this only works to the extent where you can start TDD. In many larger projects, a significant amount of previous requirements specification and decomposition may still be necessary before TDD can commence. Even in these cases, the requirements decomposition activity creates larger-grained clusters which are then easily traced across the lifecycle via TDD and TBD. We should also mention Behavior-Driven Development (BDD). BDD is an evolution of TDD that also came from the Agile community in an attempt to address some of the weaknesses of TDD. It, too, can be a very effective means of providing this same form of traceability.
Still, there is lots of work to be done in querying and collating this information to produce any required reports, and once must be careful to strike a balance between constraining processes for the ease of tracing versus not being able to trace them. This is where databases and tracking tools give us the automation benefits that index cards alone simply cannot provide.
Simple Tools: Wikis, and Wiki-based Specification Frameworks
It is often easy to go overboard with hi-tech tools and their capabilities. Many tools today provide awesomely powerful environments that are specific to artifacts in just one portion of the overall lifecycle: requirements management, test-management, code management, model-driven design and code generation. They also add a lot of painful complexity when each of those tools uses its own archiving formats and versioning mechanisms. It may be easy to trace between related artifacts in the same repository and lifecycle. Tracing across them, though, can quickly become an even bigger headache than a very primitive means of simply creating all those artifacts in simpler, text-based formats in the same version control tool.
For this reason, a simple but powerful, text-based wiki-web with versioning capabilities can be a very capable traceability tool linking code artifacts with other text-based artifacts that can be readily created in a hierarchical fashion with simple hyperlinks to indicate traces to other related information. Building even more upon this are acceptance-testing frameworks like FIT and FitNesse.
FIT and FitNesse are attempts to use executable tests as the mechanism for specifying software requirements. Many an XP developer would like to say that they can use an executable test in place of a documented requirement. That's not strictly correct if the code is the only form of documentation of that requirement. However, if the requirement is stated in a way that is both simple and SMART (specific, measurable, attainable, relevant/realizable, time-bound) then it can be trivial to associate the requirements statement with the test-code.
FIT and FitNesse essentially provide a simplistic form of "domain-specific language" that can automatically generate, or help generate, automated executable acceptance tests for limited forms of requirements state. For a more state-of-the-art view on the lengths this can be taken to, look no further than Charles Simonyi's Intentional Software.
Event-Based Traceability (EBT)
Event-Based Traceability (EBT) is a means of automatically creating traces based on tight integration between versioning and tracking tools. It is based on work-context that can be deduced from what we are doing at the time in the development environment or IDE. Actions and events in the IDE can trigger actions and events in these other tools and, together with work-context information about the information (e.g., code) that was being edited and its structure (and, for example, a task-ID), these events and actions can be logged in some structural format (XML as one example). Queries and filters can be created to produce traceability reports and selectively decide which events and requirements to trace and to what granularity.
MS Visual-Studio TeamSystem has an event server and logging capabilities built in that can directly support this form of traceability. Events from the versioning tools, code IDEs, word-processors and spreadsheets, build tools, test tools, and more can all communicate with the event server and processes that "listen" for certain kinds of events can take corresponding actions. The Eclipse Application Lifecycle Framework (ALF) Project takes a similar event-based approach to integrating different tools in the lifecycle.
TDD/BDD + TBD + IDE = EBT 4 Free?
Looking more closely at the inter-relationships between Test-Driven Development (TDD), Task-Based Development (TBD), a spiffy interactive development environment (IDE) such as Eclipse: recall that if one is following TDD, or its recent offshoot Behavior-Driven Development (BDD), then one starts to develop a feature by taking the smallest possible requirement/behavior that can be tested and writing a test for it. The code is then made to pass the test. After, it is then refactored and the next testable behavior is developed, etc., until the feature is done.
- With TDD/BDD, a single engineering task takes a single requirement through the entire lifecycle: specification (writing the test for the behavior), implementation (coding the behavior), verification (passing the test for the behavior), and design.
- Traceability for a single requirement through to specs, design, code, and test is much harder to establish and maintain if those things are all splintered and fragmented across many disjointed tasks and engineers over many weeks or months.
- If the same engineering task is focused on taking just that one single requirement through its full lifecycle, and if I am doing task-based development in my version control tool, then...
- The change-set that I commit to the repository at the end of my change-task represents all of that work across the entire lifecycle of the realization of just that one requirement. The ID of that one task or requirement can then be associated with the change-set as a result of the commit operation/event taking place.
And voila! We have almost automatically taken care of much of the traceability burden for that requirement! If we had an IDE that gave us a more seamless development environment integration and event/message passing with our change/task tracking tool and our version-control tool, and also the interface we use to edit code, models, requirements, etc., then: