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.”
My first experience with Requirements Traceability Matrices (RTM) dates back to proposal work I performed in the late 1980’s. 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.
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.
Number of views (4623)
*The views, opinions and positions expressed within these posts are those of the author alone and do not represent those of Seavus Group.
We accept no liability for any errors, omissions or representations.
The copyright of this content belongs to the Seavus Group and any liability with regards to infringement of intellectual property rights remains with them.
Communicating Project Scope | Project Ma
1/4/2010 5:05 AM
[...] requirements back to your scope definition. We’ve discussed this previously in the form of the requirements traceability matrix. This trace will help ensure a complete requirement coverage as well as helping to prevent [...]
11/16/2011 1:02 PM
I liked your personal experience , i am struggling to design a good RTM, looking for how to sort requirements.
5/30/2014 4:55 PM
Check IEEE 830 - a nice guide to defining software requirements - available here - http://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
mac eyeshadow pallet 533143
1/25/2015 7:48 AM
mac eyeshadow pallet 533143...
wholesale mac eyelashes 242514 mac fluid foundation 530545 peuterey piumini 131102 Makeup Mac 013452 buy isabel marant online 453111 giubbotti moncler 2014 125152...
studio fix mac ingredients 555434
2/23/2015 10:23 AM
stivali donna hogan 021403 ebay moncler 013430 ray ban wayfarer square 001010 peuterey shop online 304220 spoon straws 111455 oakley sideways red 515521
studio fix mac ingredients 555434 http://www.yorkshirenetwork.co.uk/blog/cheapmacmakeupwholesaleuk/studio_fix_mac_ingredients_555434.asp
If you are interested in conveying your message to your target market, please contact us at firstname.lastname@example.org!
Share you project management knowledge and expertise with the hundreds of thousands readers of PMTips.net. Apply here!