What are the biggest problems you face with Requirement Traceability Matrices (RTM’s)?
We would like to open a discussion on what people feel are the biggest problems associated with RTM’s.
For example some if the key pain points seem to be.
- Having clear requirements to trace.
- Lack of collaboration between different departments.
- Updating the RTM’s when changes occur
- Maintaining the RTM’s after project close out.
- RTM’s been done retrospectively.
What do you think are the biggest issues that face you today when working with RTM’s
All input is welcome.
Best Regards
Nice thread you have started here…In general there will be a business analyst responsible for collecting and managing the requirements.If that business analyst leaves their task to someone else who has to then manage that project, it becomes impossible to know where requirements came from. A document of hundreds of requirements will be developed and nobody knows for sure where certain requirements came from.I think this is the main problem with RTM.I eager to
know another problems with RTM…
Matt Damick
• [COLOR=#000000]The biggest problems I see…
-
Managing the many-to-many relationships David speaks about above. I tend to think this is due to ambiguous/overlapping requirements and/or a failure to calssify/group requirements in a sensible fashion. Minimizing the overlap is no easy task. Some of this can be mitigated by enforcing requirements and design specifications templates. Templates’ outlines and associated content procedures/guidance need to be carefully worded so as to avoid/minimize many-to-many relationships. Also, consciously choosing to limit RTMs to (especially) Critical-to-Quality requirements and their associated testing can help mitigate this as well.
-
The unwillingness of many companies to try/adopt/adapt tools like HP Quality Center to requirements & testing management and trace-ability in general. As long as such database tools remain almost entirely in the IT realm, we’ll be stuck with an essentially paper-based system, where spreadsheets are used as little more than a word processor. The unwillingness to utilize such tools is really a type of voluntary IT-hand-cuffing. I don’t suggest that HP QC et al are panaceas, per se, but they’re generally more tailored to the kind of information handling we’re looking to accomplish with RTMs than just a spreadsheet.
-
Not establishing clear rules* for maintenance of RTMs. One method that I saw withstand auditors/inspectors was to require an RTM (usually system-based) for new implementation. It was not updated after initial qualification. To establish/maintain traceability, subsequent validation (i.e., change control / validation maintenance) analyzed the requirements and design impacted by the change and the need for new and regression testing accordingly. All such subsequent validation required specific references to the requirements/design documentation driving the testing. This was basically a protocol-by-protocol extension of the RTM without actually updating it, too. Not perfect, but with a decent doc mgt. & change control mgt. solution, certainly traceable enough to ensure ready retrieveability of documentation.
-
Not establishing clear rules for RTM management during initial implementation and validation of a system. A best practice is to draft the RTM continuously throughout implementation and initial qualification - as various testing (Development testing, commissioning, qualification, etc.) is drafted and approved. Waiting to draft RTMs after qualification is problematic just in terms of project management and schedule compression. What testing gaps are found, the PM mayhem ensues.
*clear rules = SOPs/policies etc.[/color]
Thanx gokeeffe for providing biggest problems of RTM…It’s really informative post…