1. Hello and Welcome to The Quality Forum Online...Continuing in the spirit of People Helping People !
    Dismiss Notice
Dismiss Notice
You must be a registered member in order to post messages and view/download attached files in this forum.
Click here to register.

Traceability in Medical Sofware Development Process

Discussion in 'IEC 62304 - Medical Device Software' started by MrTetris, Oct 29, 2018.

  1. MrTetris

    MrTetris New Member

    Joined:
    Oct 29, 2018
    Messages:
    2
    Likes Received:
    0
    Trophy Points:
    1
    Dear All,


    At the moment I am working on a feasibility study about moving from TFS to PTC Integrity for a Class B medical software company, and I am trying to define the basic requirements to guarantee traceability in the sw development process. We identified these items so far:


    Project (the highest level element)

    Backlogs (a whishlist from the PdM)

    Design Input (defined by PdM and SA)

    User Interface specifications (defined by PdM and SA)

    Risks (defined by PdM and PjM)

    Requirements (defined by SA)

    Tasks (defined and implemented by the SE, when he thinks that the Requirement item is not detailed enough or if he prefers to split it up in multiple parts)

    Test cases (defined and executed by QA)

    Bugs (opened by QA, resolved by SE)

    Change Requests (opened and approved by PdM and PjM)


    The answer appears to be not so trivial, related standards leave some freedom and probably there is no “one size fits all” solution, which instead depends on our QMS and Risk Analysis


    At the moment, my proposal is the following (please consider that all elements are tracked to the “Project” item):

    http://depositfiles.com/files/t2w09mgar


    In words:

    Backlogs do not need to be traced, since the real starting point is Design Input (where Backlogs are analyzed, rephrased and eventually deleted).

    UI specifications should be traced to higher level DI, Change Requests to the original DI/UI spec and to the Requirement defined from them.

    Each DI, UI spec and CR shall be linked to at least one requirement, and vice-versa (this is actually a critical point, because other colleagues propose that a Requirement does not imply a higher level item, but I cannot imagine any case of this type).

    Tasks are created by SE when they want to decompose or further detail a Requirement, but only the latter is tested through Test Cases.

    Each Requirement is traced to at least a Test Case, but Test Cases can be created also when a Bug is found during Exploratory Testing (in this scenario, we create the test case only if the Bug is related to a Risk).


    I would be curious to know what you think about my proposal and how you would manage Risks, considering that all links between items needed to create the Traceability Matrix have to be manually defined (generally by the SA), so the fewer the better to avoid forgetfulness.
     

Share This Page