When people talk about traceability in enterprise software development and delivery, they’re generally referring to “requirements traceability”. Requirements traceability is about tracing the lifecycle of a requirement (i.e., what the end user expects from a new or modified product) and its related design elements (tests, commits, builds, etc.) as it moves downstream towards deployment following a customer request. It’s about ensuring the right thing is built the right way, and laying breadcrumbs so that the process can be accurately analyzed, improved and optimized. It’s about product validation.
How does traceability help IT organizations?
Traceability underpins three critical business management processes:
- Quality Management: enabling organizations to hit quality targets/meet customer expectations
- Change Management: tracking changes to product during development (before, during and after)
- Risk Management: tracking and verifying vulnerabilities to product integrity
What type of organization needs traceability?
For organizations in heavily-regulated industries such as finance, healthcare, insurance, and federal government, traceability is critical. All work simply must adhere to strict regulation and policy. Compliancy is everything. Requirements must meet comprehensive testing because outages and breaches carry serious implications (the inability to find a patient’s medical file, for instance, can be fatal).
And even for companies outside those sectors, if a critical test is missed, there is a serious danger that they risk deploying a wrong or malfunctioning product that undermines a quality delivery. Customers are unsatisfied, employees frustrated, and a company’s reputation takes a hit.
How are organizations approaching software delivery?
Traditionally, organizations could use Requirements Management tool (such as Doors and Jama) and Requirement Traceability Matrix (RTM) to track changes to a requirement during production, ideation to completion:
This approach, however, is inherently flawed: a spreadsheet or even a requirements traceability matrix (RTM) lacks the deep sophistication required to document and link all these moving parts from end-to-end. Such an approach is too narrow and static to capture the sheer volume and velocity of work – especially when you consider the spiraling network of specialists, tools, and artifacts involved in creating a single iteration.
It’s important to remember there isn’t just one version a requirement. Multiple tools for planning, building and delivering software all store their own fragment of each requirement so that the relevant specialist (developer, tester etc.) can work on that requirement in their own tool. Yet there’s no simple or practical way to cross-reference and verify this work.
Using a spreadsheet, therefore, provides limited traceability: it’s simply not dynamic or fast enough to keep track of all the fragments of requirements, the hierarchical relationships, dependencies, and other linked artifacts (such as test cases) that travel through multiple systems. It doesn’t trace the entire lifecycle of all elements in a product iteration, including all associated changes that validate that the right product was deployed.
What’s the solution?
Any traceability solution must link all teams and tools to provide a single source of truth and absolute transparency between systems. For that, there needs to be data integration across tools from both up- and downstream – from the teams that plan, design and create software, to the teams that build, deploy and maintain the software. That means automating the flow of all requirements and associated artifacts (and any modifications and changes) across all tools in real-time. Not only does this data improve specialists productivity and the quality of their work, but management and CIOs can create accurate reports and dashboards to monitor and optimize performance.
