Thanks for everyone that participated in the "Beyond FDA Compliance Webinar: 5 Hidden Benefits of Your Traceability Matrix" webinar. The webinar recording
is now available if you weren’t able to attend or if you would like to watch it again. Transcript from the webinar Q & A follows.
Q & A
Q: I clearly see the need for robust traceability in Class II and III device development, but is there a general rule you use by class of device?
A: (Steve) My experience is that you would want to demonstrate traceability from software requirements to test cases for Class I devices. For Class II devices you would want to demonstrate requirements mapped to design documents and then those design documents mapped to test cases. And for Class III devices you need to go all the way down to source code. So again, the idea is that the higher the risk of the device the more traceability information you are going to be expected to demonstrate. The lower the risk, the less information traceability you are going to need to demonstrate. That is the general rule of thumb that I have used with respect to how much information you need to show in the trace matrix.
Q: We maintain our design documents (SDDs in this presentation) outside of TestTrack. Would you recommend adding these documents to TestTrack for traceability?
A: (Michael) Absolutely! When you add these documents to TestTrack, you are then able to break them down into smaller objects by document sections and associate those sections to your system requirement spec, your product requirement document, marketing requirements, and so on. You can associate the sections with work items to track development progress. If you don’t store your design documents in TestTrack, you are missing out on automatic traceability, which only requires a small amount of configuration work upfront.
Q: You mentioned not including an issues log for the FDA. Can you elaborate more on that?
A: (Steve) If you have a tool that you are using to track issues, whether it is bug tracking or something like that, that is not information that you are required to submit as part of a 510 (k) for example. If you want to include an issue tracking column in your trace matrix, you should. However, when it comes time to prepare the documents for submission I would remove that column because the reviewer does not have the need or the right to look at that information as part of reviewing your submission. It is generally a good practice to only submit the information that you are required to submit. Just following that practice, I would say your trace matrix needs certain connections and those connections are shown in the guidance documents that I referred to earlier. As long as your trace matrix shows those connections that is all that you are required to do.
Q: Can TestTrack link to an external software repository such as SVN or SourceSafe?
A: Yes, that integration is built into TestTrack. More information about supported integrations is available in our knowledgebase: www.seapine.com/kb/questions/1451/
Q: What kind of effort is involved with creating a trace matrix earlier in the process, and could you rehash some of the benefits you talked about?
A: (Steve) Creating a trace matrix from the beginning of the project and maintaining it all the way through provides you with many more benefits than if you simply wait till everything is done and then frantically try to put together a matrix. If you wait until the last minute, all you’re doing is busy work to help satisfy a regulatory requirement. It makes a lot more sense to get some value out of your matrix—the way that you do that is by creating it at the start of a project and using it to do some of the things that I discussed, such as estimating tests and test coverage or demonstrating that mitigations have been implemented.
Q: Our traceability is set up a little differently from what Michael showed with the TestTrack reports. Are those reports configurable in TestTrack?
A: (Michael) Yes, the traceability report is configurable in TestTrack and you can set it up to meet your needs. The other thing with the report is people are not just using it for the traceability; they are also using it for some of the gap analysis purposes.
Q: Why is severity not included in the FMEA for residual risk?
When completing an FMEA, severity is usually assessed once because it is the severity of the problem occurring. Even after proper mitigation measures the severity of the problem does not decrease or change—the problem is still as severe as it was at the beginning. Decreasing the likelihood and increasing detectability in an FMEA is how to decrease and mitigate risk.