When a solution has been created, how do you know that the developers have created one specific to the original business requirements, no more and no less? A requirements traceability matrix is a simple documentation tool that can be used to help align the various kinds of requirements throughout the course of a project. A traceability matrix is a table of information that lists the business requirements in the left-most column, the functional requirements that make up the business requirement in the next column, and the testing requirements in the right-most column. This helps the project team visually determine the genealogy of a specific requirement. If a functional requirement can’t be traced to a specific business requirement, then it should be removed from the project. The traceability matrix can be extended to include nonfunctional requirements and technical specifications as well. Note: Scope creep is the uncontrolled growth of a project’s scope and objectives. Scope creep occurs when requirements drift in meaning, new requirements are added to the project in an uncontrolled fashion, or the technology stakeholders add features to the solution that are not defined by the requirements. One of the most useful tools in keeping track of the project scope is the requirements matrix. While the requirements matrix outlines the project’s scope and objectives, the requirements traceability matrix outlines the origin or the genealogy of the technical requirements that are part of the project’s scope.

The requirements traceability matrix, as shown in Table 4-2, is a simple table with four columns. The first column on the left lists the high-level requirements; the next column adds refined and detailed requirements; the third column records the method for testing and validating the requirement; and the fourth column points to the technical documentation describing the solution for each requirement. This matrix gives the project team a tool that helps to ensure that all of the business requirements have been addressed by the technical specification. It also helps make sure that the technical team has not inadvertently added a new feature or capability that the business did not in fact request. This method for recording requirements therefore helps to prevent scope creep.