3 ms·
Regulatory requirements usually does box you into a waterfall sdlc. However, that does not stop you from practicing an iterative sdlc internally. I like to con
by yshrestha 6y ago
Regulatory requirements usually does box you into a waterfall sdlc. However, that does not stop you from practicing an iterative sdlc internally.
I like to conceptualize it as having a "waterfall shell with an iterative core"
It is not uncommon for us to have new requirements added in the middle of a release. However, once safety testing and clinical validation are performed, changes are pushed to the next version unless a huge safety issue is detected.
- ska 6y ago> Regulatory requirements usually does box you into a waterfall sdlc. This really isn't true, at least not for this context.
- yshrestha 6y agoI am not articulating myself correctly :) As far as regulatory submissions go and the design outputs that get stored in your QMS, the SDLC appears waterfall because there are clearly defined design inputs, design outputs, and verification / validation checkpoints. In practice, however, the actual process can be agile.
- ska 6y agoOh, I see what you mean, and yes I agree. I would word it differently, that the set of documents in your DHF, MDR, 510(k) filing, etc. are identical regardless of the methodology you use to create them. Some of the language around them sounds "waterfall-y" but you are perfectly welcome to iterate on these documents. The documents themselves are more about engineering practice than process, and are an output of whatever process you use, much like the software is.