“If we conduct requirements tracing, then we can conduct change impact analysis, but we will need to maintain a Traceability Matrix.”
Where did that requirement come from, is that requirement satisfied, and how is that requirement being satisfied are three different questions that the PM needs to have an answer for. In the past, many methods have been used, but all approaches have similarities as well.
But, first we recognize all requirements are not the same. We have business requirements, source requirements, functional requirements, system requirements, technical requirements, test requirements, on and on it goes.
Where did that requirement come from? Regardless of the requirement type, we should be able to find this answer back in the project plan somewhere. Now, depending on the requirement type, the source requirement should be able to be identified.
The trick becomes identifying this source, and then tracking it from one requirement to another until it surfaces as perhaps a PERFORMANCE type of requirement or BASIC. The tracing method is designed this linking one requirement to the next, from head to tail.
Has the requirement been satisfied? Often referred to as the requirement portfolio. This question is normally addressed by a listing of the tail-end requirements’ status. Think of a tree, each tree branch represents a new level of requirement derivation. Requirements are traced through the tree all the way down to the leaves of the tree. These leaf requirements are thought of as the requirement tails. When all the tails of a branch are satisfied, then that branch is satisfied.
A Requirement centric WBS is a complete WBS developed through reductionism, each project task being a requirement for the delivery of a higher up deliverable. The parent task (or requirement) is completed when all children are completed or ‘Satisfied’. Notice that the project hierarchy provides the requirement tracing answering “where did that requirement come from?” within the project structure. “Has the requirement been satisfied?”, is also addressed by the parent task’s status.
How is that requirement being satisfied? Why this is just the tasked leading up to the completion of the parent task in the project plan. But, depending on the development process, you may not have all this powerful structure to lean on. In this case, “What to do?” You need to build a ‘Compliance Matrix’, which is easiest to describe if we go back and describe a tracing or ‘Traceability Matrix’.
The Traceability Matrix is simply a list of requirements in rows, and columns representing that requirement tree or hierarchy we reviewed already. In this way, source requirement will be placed in row one, column one, (1,1). Then in row one column two, (1,2) you might have a PERFORMANCE requirement that will satisfy the source requirement.
There are times that you will need two or even more PERFORMANCE requirements inserted into the structure to satisfy the source requirement. No problem, just insert the next PERFORMANCE requirement in row one, column two, (1,2) and the next requirement in (2,2).
For each PREFORMANCE requirement in column two you might need a set of BASIC requirements in column three. Place the BASICs in (1,3), (2,3), and (3,3) for three BASIC requirements needed for the single PERFORMANCE requirement in (2,1), then the next set of BASIC requirement will be placed in (4,3), and (5,3).
This matrix is referred to as a Traceability matrix, and traces the five Leaf-node requirements back to the source. It is normally used for change impact analysis, and indicates which BASIC requirements are suspect if a source requirement changes. Again, just want to point out that a proper WBS can add a lot of value to your project besides a task list.
The Compliance Matrix is much the same, but taken one step further, indicating the status of each requirement. In this way, not only can you conduct change impact analysis, but project completion, and value realization can easily be determined.