Should Requirements Traceability Matrices (RTMs) be formally controlled documents?

IB_S_BASIC_COPYRIGHT =

Should Requirements Traceability Matrices (RTMs) be formally controlled documents?

At the beginning of last year (2014), I posed the above question “Should Requirements Traceability Matrices (RTMs) be formally controlled documents?” on LinkedIn because I wanted to get thoughts from people working in the pharmaceutical industry regarding how they went about it. I thank all those that have taken the time to respond. In essence, while these responses have been varied, they pretty much all agreed on one thing i.e. Requirements Traceability should be carried out.

What is an RTM?

Requirements Traceability Matrix (or more commonly referred to as RTM) is a method used to establish the relationship between documents. Its purpose is to ensure that requirements have not only been traced to the appropriate design elements but also that requirements have been met through test or other means of verification.

What do the regulations say?

FDA (Code of Federal Regulations Title 21) and TGA (PE 009-8 – 15 January 2009) currently do not have any specific regulation around requirements traceability. However, the European Commission (Volume 4 Annex 11 Clause 4.4 (part)) and PIC/S Guide to Good Manufacturing Practice for Medical Products (PE 009-11 1 March 2014 Annex 11 Clause 4.4) do state “User requirements should be traceable throughout the life-cycle.”.

What is industry’s current thinking?

Based on my experience and also from the LinkedIn responses, everyone has their own interpretation of how it should be done. See table below for examples:

Some Companies…While others …
Use automated Commercial-Off-The-Shelf packages like DOORS, ReqPro, etc.Do it in a manual way, often in the form of an MS Excel spreadsheet.
Require it to be a formally approved document (including QA) against the company’s approved template complete with revision history.Have treated it more like a project management tool in an MS Excel spreadsheet format without needing any approvals.
Have specifications with unique requirement numbers and test documents with unique test ID and then produce a standalone RTM showing traceability.Have simply kept the specification requirement numbers unique and used these same numbers as the Test ID which meant RTM was not required.
Have kept it controlled and updated it at major stages of a project.Have kept it as working copy and only approved as an attachment to the Validation Summary Report at the end of the project.
Have used a standalone RTM to show traceability between specification and test documents.Have incorporated the traceability within these documents themselves and so, a separate RTM document is not necessary.
Have traceability for all requirements.Only have traceability for “Critical” requirements while leaving “Non-critical” requirement untraceable.

 

None of the approaches are necessarily wrong or right but whichever strategy you choose, it needs to be done in a way that will make it easily manageable and maintained in an up-to-date format by anyone. Otherwise, the time, money and resources invested to get it right at the start is all but wasted if it is left with those who have not necessarily agreed, understood or been taught how to keep it up-to-date especially, when they haven’t been involved during its infancy.What do I think?

What lessons have I learnt?

I’ve been involved with different kinds of RTMs on many varied projects, so here are some of the lessons that I’ve learnt along the way:

  1. By having RTM prepared early, the following benefits will be realized:
    • Time saving because if any requirement needs to be updated, it can quickly be determined what test documents need to be updated.
    • Minimize unnecessarily testing any requirement more than once.
  2. RTM needs to start as soon as possible, preferably as soon as the URS is approved. Otherwise, the following issues may arise:
    • It may get too complicated and challenging to start later on
    • If you find that something hasn’t been designed or tested, it will take more time and effort to include them later on.
  3. Either an approved SOP or a plan should be written right at the start to explain how RTM will be documented. Otherwise, there is little chance that one will even be done at all.
  4. If it is complicated to get the first RTM prepared, then it is likely to never be maintained. At the same time, it cannot be so lean and vague that it needs time for someone to analyze whether the requirements have been met. Finding this balance should be based on risk, complexity and novelty of the product.
  5. Without an RTM or even having an RTM that is not technically reviewed, user requirements will most definitely not be met! Thus it’s important to get one prepared and independently technically reviewed.
  6. RTM does not necessarily need to be in the form of a stand-alone document. If the project is small enough and there are only a handful of documents requiring traceability, it is acceptable to have requirements traceability within the documents themselves. For example, a Functional/Design/Configuration Specification can have sections or columns which state which specific user requirement is being met. The test documents can also be divided into sections that state at the start which requirements are being verified.
  7. Responsibility for maintaining the RTM should lie with the Subject Matter Expert (SME) who not only has an in-depth technical knowledge of all documents listed in the RTM but is also informed when the traceable documents have been updated so as to ensure that the RTM is updated where necessary.
  8. The RTM should be aligned with the URS and other associated documentation.

 

What guidance documents are out there?

For specific guidance on requirements traceability, the following documents provide a good starting point:

 

Is QA formal approval required?

As for obtaining QA approval via a formal QA signature on the RTM, you need to ask yourself what the intent of such signature is and how you are treating this document. If it’s a document that is going to be managed internally by SMEs (and not provided in a regulatory inspection) and anyone can use it as a guide to confirm traceability to a requirement, then I would say no. If the RTM will become part of the site’s Quality Management System (QMS), and elements of the RTM have a potential impact on GMP processes and systems, obtaining QA approval should be considered. Note that the European Commission Code of GMP mentioned above only says that user requirements should be traceable so how that is done is up to the regulated companies.

My Final Words on RTM?

In conclusion, I believe as long as you have an SOP or documented plan that states how you do it and you follow it, regulatory inspectors are unlikely to have any issues with that approach. In the end, regulators want confidence that you are in control of your process and if you can easily and quickly show where any requirements have been designed in and tested (in other words, traceability), what more can they ask? In the end, it’s a tool used to assist regulated companies in making sure they get what they ask for.

Read more on similar topics here.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.