Bidirectional Requirements Traceability

Backwards traceability helps ensure that the evolving product remains on the correct track with regards to the original and/or evolving requirements (that we are building the product right). The objective is to ensure that we are not expanding the scope of the project by adding design elements, code, tests or other work products that are not called out in the requirements (i.e., “gold plating”). If there is a change needed in the implementation or if the developers come up with a creative, new technical solution, that change or solution should be traced backwards to the requirements and the business needs to ensure that it is within the scope of the desired product. For example, if there is a work product element that doesn’t trace backwards to the product requirements one of two things is true.

The first possibility is that there is a missing requirement because the work product element really is needed. In this case, traceability has helped identify the missing requirement and can also be used to evaluate the impacts of adding that requirement to project plans and other work products (forward traceability again). The second possibility is that there is “gold plating” going on – something has been added that should not be part of the product. Gold plating is a high risk activity because project plans have not allocated time or resources to the work and the existence of that part of the product may not be well communicated to other project personnel (e.g., tester doesn’t test it, it’s not included in user documentation).