TRACEABILITY (Software / Firmware)

I have spent years with software V&V and documentation on US FDA submissions (IDE, 510(k) ..), remediations for other consultants, device, production and test equipment software and firmware V&V, et al, all reviewed by FDA personnel.   The key purpose of 'traceability', in the context of this discussion, is to prove that all the requirements have been addressed and proven to exist and function properly / repeatedly by means of the V&V test scripts / test cases. 

Traceability is required between the SRS (requirements) and other key documents in a SW V&V package, especially the test scripts/cases. This is always carefully reviewed by a reviewer / auditor. Whether COTS (commercial off-the-shelf) or custom SW. Traceability is required in glass box / white box reviews of code in custom SW V&V, usually defined by the developer in their test cases, but subject to review and questions by the FDA (or N-B) reviewer / auditor.  And where white box review / verification is conducted, black box also has to be conducted (to show software's proper operation in its platform / hardware / environment) in addition, which would also include additional traceability analysis / documentation.

The architecture block diagrams also provide a "traceability" function, in showing the interrelationships between the code modules, the hardware, the user interface(s), the output(s), any cloud interface, etc. 

I do traceability matrices routinely for my clients.  On some extremely complex software / firmware driven devices, the degree and depth is determined by risk to the patient / end-user. A hazard / risk analysis (device) is also an FDA requirement for software V&V (I use the ISO 14971 requirements for a Product Risk Managment File and Report to provide such analysis).  For a SW V&V documentation "model" see the FDA' guidance on 510(k) submissions for devices containing software - a useful overall SW V&V "model", which I discussed with the FDA author shortly after it was first published, and which is discussed briefly elsewhere in this blog. 

The US FDA states that SW V&V has to be a risk-based activity. The above form the basis of my many articles (peer reviewed), webinars and workshops on this subject. 

To answer this question from a different standpoint: The degree of importance placed on the traceability mentioned is not just based on patient risk. It also is based on the system's complexity, and the completeness of the other documentation in a SW V&V report, and may take on a greater or lesser role based on the depth of the other V&V activities documented. 

Please note that companies are given leeway as to approaches to take to satisfy the CGMPs and safety and efficacy issues, as long as those issues are, in fact, addressed. And acceptable solutions are not necessarily "rocket science", but just basic / methodical / appropriate testing / verification to prove all SRS (Software Requirements Specifications) have been met, including any applicable standards, guidance documents, and issues of safety / efficacy, properly documented. And yes, not everybody is doing the above as they should.

--  John E. Lincoln, jelincoln.com

Testing / V&V must not only prove requirements have been met (it does what it should do), but also that there are no "unintended consequences" (it doesn't do what it shouldn't do), a big issue with the FDA, and a major source of field problems. - JEL  05/12/24