Shawn Coffman

Is Requirements Traceability Dead?

I grew up in IT as a mainframe software developer. Yes, I get it. I'm old.

The rule was to document every business requirement and map it to operational, functional and technical requirements. We managed and traced those requirements through design and all the various testing cycles. Mapping requirements to test scenarios was considered critical linkage. As the evolution of technologies and methodologies progressed, we continued to track requirements in the same way (requirements traceability matrix).

In a commercial software development environment, I like the idea of tracking client requirements throughout the lifecycle. At the end of the day, we get paid for delivering those requirements. However, in recent years I've noticed a shift in requirement review meetings with developers. I've also noticed a change during discussions with clients. Both groups are less concerned about the “traceability” of the original requirement.

I feel I'm about to get hit with the methodology stick, but this isn't about a Waterfall versus an Agile approach. We primarily leverage Agile; however, we have some unique client needs and have the "opportunity" to utilize both approaches. I've seen the focus on requirements traceability diminish regardless of the development approach.

So is Requirements Traceability Dead or Dying? Would love to get your thoughts and observations.