In our last post Become a Master of Your Domain I talked about the four major domains of the Design Authority (DA) V-model and how together they help ensure that our systems are designed as architected, and that the systems are implemented as designed. Throughout the V-Model, and I will discuss each of the domains in later posts, we have a key weapon in the DA’s arsenal: Traceability.
Managing design decisions in a program across multiple work streams is a tough task. Even knowing which critical decision trade-offs are being made is a challenge. Furthermore, subtle design trade-offs between local (work stream) and optimal (program) optima cannot be easily understood by a single mind. We humans tend to search for options until we find one that satisfies a minimum set of acceptance criteria, we are not very good at optimizing choices in complex programs, and if in addition to complexity, we have tight couplings between work streams and functionality, we are at high risk of delivery failure!
How then, to maintain confidence in delivery, do we ensure we know what trade-offs are being made, what impacts these decisions have on other work streams, or if these decision satisfy not only a local, but a global program optimum?
We know the Design Authority has the objective to ensure on a proactive and continued basis, that the design decisions taken by each work stream in the program reflect the needs of the customer. We also know that design evolves from the initial definition of requirements (and for those of you agile gurus, yes, user stories and tasks are requirements!) for a given system, through a series of iterations following a top down (demand-driven) approach, to a firm system configuration ready for implementation.
Therefore, from a DA perspective, traceability is a must have program requirement in terms of increasing transparency and delivery confidence. The image below depicts the key traceability layers, from business strategy to capabilities all the way through to test results:
For this post I have listed benefits to your program from investing time and effort in implementing traceability:
- Traceability allows the program to demonstrate to the business that the requested capabilities have been implemented.
- Traceability enables coverage analysis and gives the program and understanding of how and why the system meets the needs of the business
- Traceability facilitates requirements change management and enables impact analysis on changes to projects already in progress
- When using a proper requirements management tool, traceability allows for reuse of requirements and test cases
- Understanding traceability enables optimal iteration planning
- Traceability helps ensure that developers are not creating features that no one has requested
- Traceability supports resource management – the limited time and personnel is focused on the most important areas in development and Validation (doing the right things) &Verification (doing things right) activities
- Through traceability the program can ensure that all requirements are correct and included in the test plan and the test cases
- Traceability helps reduce rework by helping ensure all work is against current requirements, and that requirements are complete
- Traceability helps simplify maintenance by mapping changes to other, potentially impacted parts of a system
- Traceability provides the data to help us “optimize” rather than “satisfy” when making design trade-off decisions.
In our next blog I will discuss the perennial issue of rework, understanding the causes and how this can be managed and reduced for the benefit of your program. Traceability will more than pay for itself by helping us reduce the rework cycle and all those negative dynamics that arise from expensive rework.
Andre Michel Vargas