Select Page

Traceability Matrix Methodology

In the Traceability Matrix, each requirement, or group of requirements in the Business Requirement Document are mapped to the functional specifications relating to it.

Industry Awards

Global Locations

Certified QA Professionals

Happy Clients

Completed Projects

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.

The goal of a good Traceability Matrix is to ensure that all requirements are traceable to the functional specification, design documents, and test plan.

Request More Information

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

Minimize requirement-related defects

Help identify requirement inconsistencies

Allow easy analysis of requirement changes

QA Mentor Traceability Matrix Methodology

Business Requirement Document

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.

Steps in creating a matrix

Create a Business Requirement Document (BRD)

Translate BRD into a functional specification (FSD)

Create Internal and External Design Reports (IDR and EDR)

Start Test Planning including mapping to requirements

All of this gives the entire team insight into the impact
of changes, status of testing, and defects.

We’re here when you need us. If you have questions about anything on our site or our services, or if you are ready to start a consultation, we want you to contact us so we’ve tried to make it easy.

GET IN TOUCH

Please complete the form and one of our QA Expert Specialists will be in contact within 24 hours.
Alternatively, drop us an email at support @qamentor.com or give us a call at 212-960-3812

Form Submitted Successfully.