New product Introduction- Software Requirements

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

 

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!

 

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...

 

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.

 

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

 

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

 

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?

 

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?

 

Hi Peter,

Thanks for your feedback, very useful and much appreciated!

 

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