Requirements Traceability, What Are You Missing?

Chapters

Chapter 4: Requirements Traceability, What Are You Missing?

Chapters

Requirements Traceability – What are you missing?

For systems engineers, business analysts, and product owners, requirements traceability (the ability to trace requirements to downstream development, test, verification, validation, and risk activities) is an unquestioned good and an unquestioned need. Traceability is required to demonstrate compliance to relevant standards in industries such as medical deviceautomotivesemiconductoraerospace, and financial services. In addition to compliance requirements, traceability is quite helpful to assess the impact of change required on all relevant requirements and related downstream activities. But the largest potential value is missed by many organizations. 

After-the fact use cases 

The two main use casefor traceability noted above are both reactive to requests: the need to demonstrate standards compliance to third parties and the need to analyze the impact of a change request. Both use cases view requirements as static and passive. Requirements are documented and links created to downstream artifacts in software, hardware, and electrical development test and risk assessment — which are stored in a system. The system then waits until a request comes in from outside to document that a process has been followed or to identify which elements are impacted by a change. Both use cases reflect an after-the-fact mindset that limits the value that can be achieved from the effort put into establishing traceability. 

Analogies to other business-critical functions 

To view something we think we know well in a new light, it is often helpful to place it in a different context and look at it from a fresh perspective. So, let’s give it a try and compare traceability in the product development process to traceability in the new customer acquisition process.  

For engineers, these processes may at first appear to be too disparate for an apt analogy, but at a fundamental level, they are quite similar. Both start with a documented value (requirement vs. opportunity) that must transition through multiple phases and involve many other functions to reach the desired outcome (release vs. win) — and all sorts of things can go wrong along the way leading to delays, costs incurred, and failure. 

The aspect I want to focus on is how these two processes are managedIn the sales process, the element of value (the opportunity) is living — actively measured, analyzed, and tracked for exceptions on a daily basisThe key process metrics are defined with ranges for acceptable performanceCurrent process performance is automatically calculated based on the movement through stages of all opportunities. Alerts are raised for opportunities stuck in a process stage too long (relative to average dwell times) and predictions are made about future period performance based on the opportunities in the system.   

In contrast, for most product development organizations, requirement traceability is static and in after-the-fact analysis and not living — in the way opportunities are traced in sales as described aboveTo make requirement traceability living (like sales opportunity) traceability would require software-enabled best practices in the following areas:  

  • Process metrics must be defined 
  • Actual performance against process metrics must be captured 
  • Once standard metric performance is defined, current performance must be compared to the standard 
  • Exceptions need to be defined 
  • Alerts need to be set up to notify when exceptions occur 
  • Learnings need to be incorporated into process improvement 

Once these steps are taken to improve requirements traceabilitythen requirements become living, not static, and performance improvement is possible: the risk of negative product outcomes is reducedand process performance is improved; the product development process can then be data-driven, measured, and managed like all other business-critical processesWithout measurement, there is no way to benchmark performance against other organizations. There is no way to learn, no way to know, and no way to improve. 

Better to stay in the dark? 

There may be some who would prefer to keep the product development process shrouded in mystery and avoid data-driven analysis, measurement, and process performance improvementThere used to be chief revenue officers (CROs) that felt the same way. It is extremely hard to find any current CROs with that mindset. Those who can lead through data and drive performance improvements gain the support of leadership and elevate their careers. The same opportunity is now on the table for product leadership to turn requirements traceability into Live Traceability™ to reduce the risk of negative product outcomes and improve the performance of the end-to-end product development process. 

In This Webinar, Learn More About the High Cost of Poor Requirements Management

TRACEABILITY

Traceability: Relationships between items to show evidence of requirement decomposition and verification coverage.

Book a Demo

See Jama Connect in Action!

Our Jama Connect experts are ready to guide you through a personalized demo, answer your questions, and show you how Jama Connect can help you identify risks, improve cross-team collaboration, and drive faster time to market.