Traceability for Software Validation Activities 

In the framework of software validation, it is of fundamental importance to maintain full traceability during the whole entire project and in this context the requirement traceability matrix is the right tool to achieve this goal.  Traceability has the double function of: 

  • Ensure that all the requirements are met and can be traced to the appropriate configuration or design elements 
  • All the requirements are verified and traced to the related verification activities that demonstrate that the specific requirements have been met. 

As for other elements related to software validation, the rigor of the traceability activity shall be based on risk, complexity and novelty associated to the computer system under validation. 

There are different ways to achieve traceability, including specific tools. The standard and probably the most straightforward method is the so-called Requirements Traceability Matrix. 

The Requirement Traceability Matrix is not a specific requirement clearly mentioned by the FDA or other regulators; however, in the FDA guidance related to software validation, it is clearly mentioned that “Software validation includes confirmation of conformance to all software specifications and confirmation that all software requirements are traceable to the system specifications”. This requirement is typically covered with the covered through the Requirement Traceability matrix. 

Main Characteristics of the Requirements Traceability Matrix

The requirement traceability matrix is one of the easiest tools used to achieve traceability. For simpler systems, traceability can be reached through a consistent numbering of requirements, design and testing documentation, as shown in the example below: 

The level of traceability shall be different based on the category of software, if we take in consideration the GAMP-5 categories. For example, for non-configurable software systems, traceability between user requirements and verification tests may be sufficient. However, for software applications of Category 4 (Configured), it might be necessary to have traceability between user requirements, configuration and verification activities. Lastly, for custom applications, full traceability within all the levels of the lifecycle, from requirements to verification activities shall be documented. In this latter case, a full requirement traceability matrix shall be documented. 

The following items shall be included in a Requirements Traceability Matrix. Obviously, not all the items mentioned below are mandatory, thus it is responsibility of the organization of have a Requirements Traceability Matrix which is functional to the organization. 

The Requirements Traceability Matrix may contain: 

  • Link between Requirements, Design Elements (Functional and Design Specifications) and Testing Activities. 
  • A section to include a brief description of the specific requirements
  • A section dedicated to change control number, to ensure full traceability after a modification is implemented. 
  • A column for the criticality of the specific requirements, in order to plan a level of testing that is proportional to the level of criticality of the requirement. 
  • In case a requirement is met by a specific procedure, there may a column to indicate reference of the procedure and the dedicated version number. 

There are different types of traceability matrix: 

  • Forward traceability
  • Backward or reverse traceability
  • Bi-directional traceability ( Forward+Backward)

In forward traceability the RTM is used to keep traceability between requirements and test cases. This RTM is helping to make sure that all the requirements will be verified thourgh a specific test. 

In the so-called backward or reverse traceability, the test cases are mapped back to the requirements. This basically helps to make sure that no extra unspecified functionalities are added and thus the scope of the project is affected.

A more complete traceability matrix has references from test cases to requirements and vice versa (requirements to test cases). This is called as ‘Bi-Directional’ Traceability. It ensures that all the Test cases can be traced to requirements and each and every requirement specified has accurate and valid Test cases for them. 

Conclusions

In conclusions, we have been going through the Requirement Traceability Matrix, an essential tool which is used in the framework of Software Validation. The different types of Traceability Matrix, and the related contents, have been discussing extensively. 

Subscribe to 4EasyReg Newsletter

4EasyReg is an online platform dedicated to Quality & Regulatory matters within the medical device industry. Connect with us on LinkedIn and Twitter to stay informed about the latest news in regulatory affairs.

As one of the leading online platforms in the medical device sector, 4EasyReg offers extensive support for regulatory compliance. Our services cover a wide range of topics, from EU MDR & IVDR to ISO 13485, encompassing risk management, biocompatibility, usability, software verification and validation, and assistance in preparing technical documentation for MDR compliance.

Do not hesitate to subscribe to our Newsletter!

You have successfully subscribed to the newsletter

There was an error while trying to send your request. Please try again.

4EasyReg will use the information you provide on this form to be in touch with you and to provide updates and marketing.