EN 
DE 
Do you remember working for the first time with a tool that supported traceability? What a change going from, say, word for capturing requirements to DOORS. And do you remember the moment when the honeymoon was over? There are many things that can make requirements traceability frustrating: What exactly is the meaning of a trace? What is worth tracing? How do you take advantage of the traceability, once established? And how to keep the traceability up to date? If these questions are not answered correctly, and if there is the wrong cost-benefit expectation of traceability, frustration can appear quickly.
Traceability – like requirements management in general – is not an end in itself. We have to be very clear about what its purpose is. Brenda Kerton has a nice summary that outlines both the benefits and pitfalls, the benefits being scope management (where does each requirement come from?), testing (make sure everything is tested, but not more than necessary) and change management (impact of changes on everything). She also points out the pitfalls – from overdoing it to lack of proper tool support.
To make traceability successful, we’d like to add to this:
Put traceability in context – If you do traceability right, but everything else is neglected, you have a problem. This includes like structuring of requirements: if the structure of requirements is not appropriate for the problem at hand, then you can forget traceability. For user-driven systems, use cases may be the right form. For embedded systems, IEEE 830 may be better. Once you have a structure, you can decide what to – and what not to – trace.
Use the right traceability granularity – No need to trace every single requirement – maybe it makes sense to group them? For instance, one Use Case consists of multiple elements. Still, just tracing to nothing finer but individual use cases may be sufficient?
Define what you trace – as we said earlier, you need to know whether your trace means “realizes” or “tested by”. Define categories, and make sure that a trace is assigned a category. Make sure that each category serves a purpose that saves time and money in the long run.
Use the right tools – and this is the reason why we developed ProR and made it part of the Eclipes RMF project: The tool must be powerful enough to support traceability, but should not be over-engineered for the job at hand. ProR may be just right: But if it’s more than what’s needed, maybe Excel is sufficient after all. On the other hand, maybe a heavy-weight like DOORS or IRQA is needed after all.
And the last one is the most important one:
Plan for the resources you need to get it right – An outdated or partial traceability can be worse than no traceability at all! The benefits are longterm. If you don’t have the resources to support what you plan, then reduce it.
Managing traceability is – let’s be honest – not the most exciting work in the world. But that means that it’s actually not that expensive. If done right, the benefits can be immense.