Is traceability of requirements throughout the lifecycle important? If so, why?
Traceability of requirements is critically important to assuring a successful product or project. This importance is usually acknowledged at the start of a project, or for one-time-only projects -- but it is even more important for ongoing operations.
Traceability provides benefits in two primary areas: providing context for the implementation (development AND testing) team, and enabling the entire team to assure that we are not just building the product right, but also building the right product. Context answers questions like: "Why am I being asked to do this?" and addresses concerns like: "I don't see how this is worth doing." My experience has been that providing context helps to motivate team members, too. With a sense of perspective, team members can give themselves reasons to try harder or be better. With context, they are individual contributors (to achieving the traced objectives), not just cogs in the machine spinning mindlessly "because I said so."
To build the right product, you have to demonstrate how what you're asking people to do supports the traced goals. In the opposite direction, to assure completeness of requirements, you have to assure that you have defined all of the requirements that are needed to achieve each goal. In the initial stages of a project, this communication is usually front-of-mind and widespread. Over time, it is easy to forget.
Even if you assume that requirements don't change (and they always change), you still need traceability throughout the life of your product or system. A year after you initially launch your product, you will consider making changes to the product. Without traceability, you have no good way to know why what you're about to change (or remove) was put there in the first place. You run the risk of "breaking" the product, by removing support for one of the original, and still valid, goals. When you introduce bugs (regressions that break something that was previously working) during future development, without traceability you have no way of knowing the impact of those bugs on your users. The best you can do without traceability of requirements is a shallow triage analysis. Traceability lets you know the potential impact on your users of a broken piece of functionality.
When you acknowledge that requirements change over time, because the goals of your users change, traceability becomes even more valuable. When a requirement is no longer relevant, you can use traceability to determine which parts of your product (and testing suite) you can deprecate and which ones you need to augment.
Imagine that you've just inherited responsibility for a product or system that has a lot of "quality problems." What do you fix first? Traceability can tell you -- fix the code (and create tests for the code) that supports the most important goals. Traceability tells you why that Byzantine function exists, and lets you manage the risks associated with refactoring or replacing it. Traceability lets you be intentional about how you improve a product over time, by allowing you to choose to focus on the most important things first.
You may think of this ongoing maintenance and development of a large product as an "eating the elephant" exercise - just start somewhere, and work at it until you're done. That would be a bad approach, because you'll never finish eating -- because the elephant is always growing and changing, as the underlying requirements change. Traceability allows you to always be focusing your team's energy on the "next most important thing to do."
Using the old model-driven software development methodology for new ideas
Dig Deeper on Topics Archive
Related Q&A from Scott Sehlhorst
'Continuous development' is still a relatively new and confusing term. Find out what it means beyond the hype. Continue Reading
Expert Scott Sehlhorst identifies three mobile app types and explains the unique challenges each poses around software requirement specifications. Continue Reading
SearchSoftwareQuality expert Scott Sehlhorst discusses how to avoid writing a software requirements specification that is too vague to be tested. Continue Reading