The goal of a good Traceability Matrix is to ensure that all requirements are traceable to the functional specification, design documents, and test plan. By doing so, missing a requirement becomes quite difficult and the process aids in three very important parts of QA. It minimizes requirement-related defects, helps identify requirement inconsistencies, and allows easy analysis of any requirement changes. If done or managed ineffectively, the matrix could prove to be more of a burden than a boon, so it’s important to do it right in order to reap the full benefits.

The first step in creating a traceability matrix is to create the Business Requirement Document (BRD). All of the business needs are outlined in the BRD, in the format most suitable for the team. Generally speaking, the BRD is an easy read, lacking in technical terminology. Since this is the core document, it’s important that the BRD be both comprehensive and unambiguous, and it’s helpful if the requirements are numbered or ordered in some way.

From there, the business requirements are translated into a functional specification (FSD). This specification document is where some of the finer details are laid out. In the Traceability Matrix, each requirement, or group of requirements in the BRD are mapped to the functional specifications relating to it. By doing this, we can ensure that each requirement is transformed to a functional specification. In far too many cases, we have seen functional specifications that don’t include all business requirements, or some were misinterpreted along way.

Next, the design team joins in with their design document. This architecture roadmap is a sister document to the functional specification, with pointers to the more detailed specifications in the FSD added to the Traceability Matrix. By adding mapping between the functional specification and the design documents, we are once more ensuring that every specification is covered by the Internal Design Report (IDR) and the External Design Report (EDR).

The next step is the test planning. The developers use the BRD, FSD, and design documents to create their unit tests while the testers use them to create the functional and acceptance tests. Test scenarios are created with one or more test cases in them, each one with a unique ID. At this stage, the Traceability Matrix already has the mapping from the BRD to FSD to the Design. The testers just need to plug the test scenario and/or test case IDs into the matrix document to finish the job. Tests are even mapped to each other. The unit tests created by the developers are mapped to corresponding functional tests, and those mapped to user acceptance tests, and finally those are mapped to production validation scenarios.

A Good Matrix Can

What the team has at this stage is a grid document with multiple columns representing BRD sections, FSD sections and Design points, Test Scenario IDs, and Test Case IDs. With this full mapping, it’s easy to see any empty areas on the Matrix and identify requirements that do not have corresponding test cases. To complete the document, test case status and defect columns are often added. This helps create a comprehensive picture of the status of the project from initial requirement to any associated defects. With this document in hand and accurately updated on a daily basis, a change in any requirement can be traced to all areas in multiple documents that would be affected by the change. This gives the entire team insight into the impact of changes, status of testing, and defects.