How to use traceability and what’s the value of traceability? In this part, let’s look at what traceability can be used for and where it delivers value to application, system or product development.
Why is traceability necessary/important? Isn’t traceability just an overhead, an onerous documentation task that’s only done in industries where it’s mandated? It’s true that requirements traceability practices have originated from industries like aerospace & defense, where one use of traceability is to show that contractual requirements have been addressed, but it also has so much more value to bring when used effectively, and you have the right tools to maintain it and report on it. The following lists some of the ways that traceability delivers value:
- Context: If you can trace back from a design or test to a user requirement, you then have the reason for the existence of that design or test and through the information in the user requirement (and through any related requirements you can trace to), you have more supporting context to help create the optimal design to meet the requirement or the most effective test to verify that the requirement is met
- Audit trail & compliance: Taking an example of a new person joining a project, traceability can help them navigate the project and see why particular requirements, designs, tests, etc. exist. This is also of upmost value and importance when you need to demonstrate compliance to a regulation or standard to an auditor – the traceability trail can help you quickly show you are addressing the regulation or standard.
- Coverage: How do you know whether you’ve covered all the user requirements in the derived systems requirements, designs, tests, etc.? Traceability can help you here – you can see gaps indicated by where a higher level artifact doesn’t have any relationships to lower level artifacts. Of course even if a relationship exists you still need to follow it and examine the lower level artifact to ensure it does what the traceability relationship says it should, but at least you had a signpost to direct you to the right place to look.
- Gold plating: As well as highlighting coverage gaps, traceability can help you investigate possible ‘gold plating’ or over-engineering. If you have a lower level element without any relationships to a higher level then you can ask the question – why does this exist if it’s not apparently satisfying a requirement? There might be a perfectly valid reason but this gives the opportunity to identify and eliminate anything that could bring unnecessary additional time and cost to the project.
- Impact analysis: This is the most valuable reason for traceability. If you have traceability relationships in place you can following those relationships when say a user requirement changes, to identify all the related system-, sub-system-, component requirements, design elements, tests, work items, etc. that are potentially impacted by the change. This will enable you to fully scope out the impact of the change before it’s made, giving you far more control over the cost and time impact of change requests. This can of course also work in reverse – if a design change is necessary, say because the original design proves infeasible, you can more easily see what impact that has if any on your ability to still meet the requirements. Both of these scenarios have great project management benefits – you can have informed discussions in the development team and with your customer/stakeholders about whether to make the change.
What about agile? Aren’t traceability and the benefits it’s proposed to have only necessary/of value in waterfall development? Well, take another look at that list of benefit scenarios – don’t you always want to be able to do these things, regardless of development methodology? If you’re in a fast changing, evolving project don’t you need to be more informed, have the right information at your fingertips, in order that you can respond quickly but effectively? I argue that if you have the right tools in place to create and utilize traceability, that it is even more essential if you’re adopting agile practices.
Speaking of the right tools, tools can automate the various types of traceability reporting and analysis described above. For impact analysis, tools can quickly display all of the related artifacts connected to a particular requirement. And more than that they can detect changes in a requirement that has links and automatically mark those links as suspicious. This is very effective where you have different people working on different parts of the application/system and you need to be aware of changes in other areas that might impact your work. A suspect link indicates that a change has been made to the artifact at either end of the link and that you should check that the link still holds true – i.e. if the user requirement has changed, does the linked system requirement still satisfy it? This proactive impact notification mechanism helps to avoid inconsistencies across your specifications.
Next closing topic of the requirements management 101 will be about revisiting requirements elicitation.
About the Author
