Wikipedia defines Requirements Traceability as “a sub-discipline of requirements management within software development and systems engineering. Requirements traceability is concerned with documenting the life of a requirement.”
Proposal Use
My first experience with Requirements Traceability Matrices (RTM) dates back to proposal work I performed in the late 1980s. Working for an organization that specialized in financial aid processing contracts through the U.S. Department of Education, I started as an application developer and moved into Project and Program Management after 5-6 years. In both of these roles, I worked on large proposals as needed – sometimes on a team, sometimes leading a team. We utilized a Requirements Traceability Matrix to ensure that we properly responded – in our proposal – to every possible requirement extracted from the customer’s Request for Proposal (RFP). When tens of millions of dollars are on the line, we wanted to make sure every base was covered and it definitely seemed to help.
In the RFP-Proposal case, documenting requirements in a matrix like this gave us an edge in the proposal review process. It made it clear to the customer that we understood the RFP, successfully extracted the requirements from the text of this large Request for Proposal (and they were VERY large), and every incident of response in the proposal to each specific requirement was also captured in the matrix identifying section and page number. It’s probably unfortunate that after winning the contract it was not taken any further. Once the contract was awarded the matrix was left to die. We should have continued to use it to ensure that the system was built to proper specifications and that is what would happen today, but it was a different time and because we were winning contracts that we were usually the incumbent for, we were really just updating the current software solution rather than building a new one from the ground up.
Using for the Entire Solution
My more recent experiences with Requirements Traceability Matrices are in Functional Design Documents (FDD) responding to both customer Statements of Work (SOW) as well as any documented and supplied customer-specified requirements (both high-level and detailed). Using a matrix has helped me as the Project Manager as well as the rest of my delivery team members accurately identify all customer requirements by extracting them from the SOW and other customer provided requirements, documenting them in a spreadsheet and tracking them to matching requirements in the FDD and Technical Design Document (TDD). We initially publish the matrix in the FDD – after that, it becomes it’s own document and the life of each requirement is tracked through the TDD, design, development, and testing. This type of documentation gives the customer confidence that all requirements have been accounted for and can be traced through to the solution. It also gives the delivery team confidence that they have covered all requirements and are building a solution that will meet the customer-specified requirements and therefore provide the customer with a useable solution.
The big difference these days is that we do use the RTM to develop from. Not directly, but the RTM traces requirements through to the Technical Design Document and that is the basis for the development work that is performed and the basis, ultimately, for the final developed solution.
Summary
Customer requirements are obviously critical to the project and meeting those requirements is critical to project success. Anything that can be done to ensure that requirements are in place and that the system is being developed well to those requirements not only gives the customer greatly increased confidence in the delivery team, but the final solution is much more likely to actually meet the business needs of the customer.