1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. 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.

New product Introduction- Software Requirements

Discussion in 'IEC 62304 - Medical Device Software' started by QAengineer13, Oct 1, 2015.

  1. QAengineer13

    QAengineer13 Member

    Joined:
    Aug 3, 2015
    Messages:
    47
    Likes Received:
    13
    Trophy Points:
    7
    I would really appreciate ,if I can get some guidance related to a new product introduction - DHF requirements for Software. My question is that our project team has recently started the sprint planning, from a DHF requirements what are the deliverable would be better to have to save time retrospectively in the very early stage of software development? any help!

    FYI: We already have the Requirements in place, I need to know do we need to have a SDP, etc?

    Also I have another question, our software team writes the test cases using first person reference example) I should see the dialog box etc... which I feel is not the correct thing , inorder to make them not continue writing test cases with "I" and first person reference, I need a strong supporting evidence from FDA or regulations to support my claim ... Any medical device software guru in this forum , please help me on best practice ...thanks
     
    Last edited: Oct 1, 2015
  2. Candi1024

    Candi1024 Well-Known Member

    Joined:
    Jul 30, 2015
    Messages:
    121
    Likes Received:
    80
    Trophy Points:
    27
    Location:
    Pennsylvania
    I'm not sure that there would be any regulations about using "I". How about a good technical writing resource. It's not necessarily wrong, just not right, lol!
     
    QAengineer13 likes this.
  3. Eric Twiname

    Eric Twiname Well-Known Member

    Joined:
    Jul 31, 2015
    Messages:
    197
    Likes Received:
    155
    Trophy Points:
    42
    Location:
    Northeast USA
    FWIW being that I am not in Medical at all....

    Back when I was teaching Technical Writing (Graduate assistant...not for a living), the general rule was that all technical reports and instructions should be written in third person, passive voice.

    Don't know if it helps or not...but figured I'd put it out there...
     
    QAengineer13 likes this.
  4. yodon

    yodon Member

    Joined:
    Aug 3, 2015
    Messages:
    46
    Likes Received:
    19
    Trophy Points:
    7
    A good source for regulatory expectations is IEC 62304. Unfortunately, it's written more aligned with a waterfall approach rather than more modern practices.

    That said, I believe there can be reasonable mapping.

    First, though, what are your release-to-public plans? In other words, when does product go on the market and be available for public use? And how frequently will you be updating? (And I specifically say release-to-public to minimize confusion with sprint releases). Changes to a fielded product are costly which is probably why the standards are more waterfall-y.

    I'd suggest start with the Software Development Plan. Expectations are that you define your lifecycle (including aftermarket activities) so this can be used to drive the team through the sprints and ensure that required information is captured along the way.

    You have software requirements which is good and so just make sure they are continuously up-to-date.

    The (safety) class of the software will drive the remaining activities. Do you know what class? (Note that 62304 has Class A, B, C and the device classes are I, II, (IIb,) and III). There's a whole discussion about safety class and partitioning that may be needed but too much for now.

    If you're going to use your testing at each sprint to build up the case for verification (i.e., incremental verification instead of a big bang verification prior to release) then you'll want to make sure those procedures are signed off and controlled at each sprint.

    In the end, you need the required documentation so use the Plan to define how you get there. It's a big topic so if you have specific questions / needs, holler back.
     
    Atul Khandekar and QAengineer13 like this.
  5. QAengineer13

    QAengineer13 Member

    Joined:
    Aug 3, 2015
    Messages:
    47
    Likes Received:
    13
    Trophy Points:
    7
    I'm laughing at their test cases as well, and I'm sure you can relate when everyone in the team looks at RA/QA and view them as enemy and protest whatever RA/QA says ....and raise a silly question...example) how can you prove that test case written in active voice is not good practice.... "Common sense is not common for people" which makes the job all the more challenging! I'm sure ..I'll find a way :)
     
    Last edited: Oct 5, 2015
  6. QAengineer13

    QAengineer13 Member

    Joined:
    Aug 3, 2015
    Messages:
    47
    Likes Received:
    13
    Trophy Points:
    7

    Thank you, Yodon. I really appreciate your input...and I'll get back to you for more specific questions as my work progress.
     
  7. pdzip

    pdzip New Member

    Joined:
    Jan 21, 2016
    Messages:
    4
    Likes Received:
    1
    Trophy Points:
    2
    Location:
    Pacific Northwest, USA
    If "I" has the same meaning for them as "The user", I don't see a problem with that. It may actually be a stroke of genius to do that. I would focus on what comes after the "I". Does that meet the requirements for a good SW requirement? Is that unambiguous, unique, verifiable etc?
     
  8. Peter Selvey

    Peter Selvey Member

    Joined:
    Nov 9, 2015
    Messages:
    13
    Likes Received:
    8
    Trophy Points:
    2
    It's probably to late to make a comment, but from a regulatory perspective, there is no "I", rather there is only the medical device. Technically, the requirement or specification should be written in a way which objectively states the expected action of the software, not the user whether they are first or third person.

    Press the software blue button X and a green light A turns on - it's OK;

    I press a blue button X and check that I see a green light A - it might sound the same but it is not actually saying that the software followed the expected action. Subtle, I agree, but there a point. It is not whether "I" perceive the software acted according to a specification, someone must make a judgement that the software did act according to specification. If a specification is written in terms of "I", it is possible that the tester could hide behind a defence that they perceived it as OK. But in a regulatory context, prior to release of the software to market, someone must judge that the "software" performed according to specification, not what "I" perceived the software to do. Subtle but important?
     
    QAengineer13 likes this.
  9. QAengineer13

    QAengineer13 Member

    Joined:
    Aug 3, 2015
    Messages:
    47
    Likes Received:
    13
    Trophy Points:
    7
    Hi Peter,

    Thanks for your feedback, very useful and much appreciated!
     
  10. Naveen Goyal

    Naveen Goyal New Member

    Joined:
    Mar 20, 2017
    Messages:
    1
    Likes Received:
    0
    Trophy Points:
    1
    I would agree with Peter, The requirement should be written in terms of outcome expected from the software not from User perspective and they should always be written with a "shall" if they are necessary requirements. The other type of requirements are written in terms of "should" or "may" which are good to have

    E.g. On Pressing the software blue button X, green light A shall turn on - This should be the requirement
    Test case against this -

    Steps
    -Press the software blue button X.
    Expected outcome
    -A green light A turns on
    Actual outcome
    - (Record, if the green light A turns on or not)
    Pass/Fail
    -Document as per results from Actual outcome
     

Share This Page