Requirements – the detailed descriptions that capture the necessary functionality in a piece of software – are the heart and soul of a development project.
Once a client signs off of the requirements, they are the basis for all the project team’s efforts, and they become the “truth” document. In the agile development world, requirements evolve through the collaborative effort of self-governing, cross-functional teams.
The Importance of Requirements
A valid and important question for any agile development team is, “How do we manage evolving requirements to ensure efficiency, completeness, and overall quality?”
This is an important concern, considering that requirements are used by all members of a cross-functional team for a different purpose. Business analysts and architects use the requirements as a record of what has been collected and agreed upon with the client; project managers use the requirements to create various tasks that plan and track efforts; developers use them as a set of rules for the code they develop; and testers use the requirements to develop various test artifacts that will improve the application’s quality.
Teams also use requirements – and their evolution – to estimate their overall effort and plan sprints. So, it is easy to see that there is a direct relationship between the quality of the requirements and the project’s overall success.
Managing Evolving Requirements
How can a team be certain that sufficient tasks and artifacts exist, and that the team can efficiently react to evolving project requirements? An RTM – Requirements Traceability Matrix – creates traceable relationships between the requirements and all other project development artifacts included in the development process, from requirements to defects.
In the research article “An Analysis of the Requirements Traceability Problem,” Orlena C. Z. Gotel & Anthony C. W. Finkelstein of the Imperial College of Science describe traceability as:
“… the ability to describe and follow the life of a requirement, in both forwards and backwards direction (i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases).’ 
A sample RTM with test data is pictured below, produced with a report from the JIRA Zephyr plugin. The concept is the same for a spreadsheet, although you may choose to organize it a bit differently. Notice how the matrix lists the requirement, the test(s) for the requirement, any test executions, and any defects found in testing.
Below is a sample RTM in a spreadsheet. The X and Y axis contain the Use Case ID and the Requirement ID, respectively. An X in a cell of the table indicates a relationship where the use case tests the requirement, and a count is kept and displayed for reference as well. Note that, in this example, UC (Use Case) is synonymous with test case.
Benefits of a Requirements Traceability Matrix
For the team as a whole, RTMs give the ability to ensure requirements completeness, identify the potential consequences of a change to the requirements, and to estimate what needs to be modified to accomplish a change (requirements, code, test artifacts, tasks).
From a project management perspective, RTMs are an effective means to ensure that the customer’s requested product was successfully built. It enables all requirements changes to be tracked and traced, and it helps the PM quickly zero in on defects related to the most important requirements for triage.
Developers and Architects
For developers and architects, the RTM enables them to see defect rates for all system components and identify the problem areas. During the design phase, the team can keep track of what happens when changes are implemented before a system has been completely redesigned.
Traceability requires the documentation of all requirements, but it also ensures that testing will reveal any missed or incorrect requirements, and it gives business analysts the ability to easily identify the requirements that need updating.
As for testing, the RTM aids in risk assessment, or determining exactly which tests need to be run, resulting in right-sizing the test effort. Testing every requirement can be an unnecessarily time-consuming and expensive process. Traceability allows managers to estimate efforts where requirements changes are needed. They can easily see test coverage, test assignments, and test execution statuses for a project.
Whether your team uses spreadsheets, a varied collection of tools, or a suite of integrated tools for project tracking, RTMs can be accomplished. An RTM can be a simple spreadsheet matrix, or a report that can be produced via the tools that your company already uses. A little research and trial and error will be required, but it will be well worth the effort.