I have been asked this question many times and wanted to hear the opinions of the group. Should RTM’s be controlled documents with QA oversight? Or should they be uncontrolled project documents (like a working spreadsheet) which can easily maintained and updated? Your thoughts?
During my period working as Qualification Officer with an engineering company, I had the chance to work with and for different pharma companies. They all had a different appoach to it.
Some did not use a TRM some used it as a personal follow up doc and some had the TRM formalised as a separate doc or as an attachment to a qualification report.
In my opinion, the TRM is an added value if your spec docs are thoroughly and correctly set up.
Since most of the times systems are bought with validation included, I find the TRM a doc with little added value.
Hence I understand why companies tend to test critical functions more than others. This might be the reason of the current big focus on the use of risk assessments and the consequential (scientifically based) testing.
RTM can be working documents during the project phase, but, as an auditable document,should be controlled documents by the end of the project and prior to system release to Production. It should also be a living document throughout the system life-cycle and be kept up to date.
Aside from being an audit-support document, a well managed RTM can also provide business and project efficiencies, enabling quick tracking of requirements and tests and also minimising duplication of requirements and tests, which can be particularly challenging for complex systems (eg ERP).
[quote=keval_t@yahoo.co.uk]RTM can be working documents during the project phase, but, as an auditable document,should be controlled documents by the end of the project and prior to system release to Production. It should also be a living document throughout the system life-cycle and be kept up to date.
Aside from being an audit-support document, a well managed RTM can also provide business and project efficiencies, enabling quick tracking of requirements and tests and also minimising duplication of requirements and tests, which can be particularly challenging for complex systems (eg ERP).[/quote]
I agree with this answer (keval_t). You should manage it during the project but it needs to be “frozen” before system release as the ultimate instantiation of tracing.
Agreed that if it’s a stand-alone document, it should be baselined and revision controlled.
If, though, you’re using RTM tools like ReqPro or DOORS, the reports can be generated on the fly. In such cases, specific reports may be part of other documents that are baselined. For example, when we generate a verification protocol and are using a tool, we generate the report showing the test objectives and tracing UP to parent requirements. That gets stuffed into the protocol and gets approved with the protocol. When creating the (system level) test report, we generally generate the trace report from the top-level requirements (down through all trace layers) to test objectives. That gets baselined (approved) with the test report.
[quote=yodon]Agreed that if it’s a stand-alone document, it should be baselined and revision controlled.
If, though, you’re using RTM tools like ReqPro or DOORS, the reports can be generated on the fly. In such cases, specific reports may be part of other documents that are baselined. For example, when we generate a verification protocol and are using a tool, we generate the report showing the test objectives and tracing UP to parent requirements. That gets stuffed into the protocol and gets approved with the protocol. When creating the (system level) test report, we generally generate the trace report from the top-level requirements (down through all trace layers) to test objectives. That gets baselined (approved) with the test report.[/quote]
I think hte RTM is an important quality document that provide a summary of all requirementsbeing tested and traced to the test cases, therefore it must be approved by QA and put under change control.
RTM is a controlled project document. We need to keep this document in a configuration management tool. If there is any changes in the requirement we need to update the test design document and update the RTM accordingly & make the updated RTM as new version. So we can able to track all the changes during project life cycle.
I’ll add a user perspective to this.
Since we will typically be asked during an inspection is we have one (your procedure may list it as a validation deliverable or not), we are seeing that more an more (even if it is not part of your process) that we have one…the expectation has been set,
We often use the RTM to demonstrate that we did, in fact, test all the items to meet our URS. And that we can associate a test to function/feature/criteria/parameter…and more. Additional, the RTM will point to the specific test that we used to demonstrate we were successful.
Since this our “secret decorder ring”, it is very advisable to make it a control document, since it will appear to be the core of how we didn’t loose sight of our goal. So yes, it should be a controlled document.
When we perform any changes to a system, we can use this matrix to see what areas and what tests were done previously to the system, modify them or write new ones and continue the traceability to the new requirements. And if you took the time to assign a requirement as a CP (critical parameter, i,e, to satisfy a GMP need) and/or NCP (non-critical parameter), you can use this document to determine what goes into your scope of change (for validation purposes) and those that do not. Example: You have a report that is part of the batch record, it has to be GMP and you have a report on raw material usage (for inventory), You will test both, but you need to provide test evidence of the GMP record. You can also tie this to your configuration management, to ensure you have a backup routine that reflects the current configuration and matrix.
In addition, when we perform our periodic review of the system, this document becomes crucial to ensure that all your change controls, equal you current configuration and user requirements.
So easy answer - yes.
[COLOR=#0077B5]David Hawley
[/color]
Life Sciences Director, North America
[COLOR=#333333]This is a subject which comes up quite regularly and there are usually opinions both ways. Possibly the key is what is in your matrix and at what point in time do you mean?
If it is a very simple document that leads you to the other documents where the real information is stored then I would say probably no, then during the project they do not need to be controlled documents with QA oversight (i.e. changes do not require the companies formal change control process to be followed) .
After the project may be a different matter, but still this sort of trace matrix isn’t a document which contains validation information - it just leads you to those that do, so it’s your call, on whether you place it under change control or not.
In contrast if you use a trace matrix that combines other information such as risk assessment then there is s stronger case for making it a controlled document.
Personally I tend to prefer inherent traceability in Validation documents, especially for simpler projects, but if I’m using a matrix I prefer the simpler type and I don’t place it under change control before the end of the project for the simple reason that it changes too often. That’s not to say anyone can go and alter it, it’s kept under review but to go through a formal approval procedure each time a new document is added would be a huge waste of time.
I have even worked on projects where the trace matrix was written on a steel partition wall with a dry marker! It certainly made it easy to see traceability and could be changed easily. Not until the end of the project was it committed to paper. It worked and we had no adverse comments from QA.[/color]