IEC 62304 2015 - impact on Class A software
The 62304:2015 updates change a few things for class A software. While it makes it easier to segregate between class A and class B/C, it adds a bit of documentation work.
Segregation
It was now clarified that a software system can stay class A if it contributes to risks but there are risk controls outside of the software system (either in hardware or for example also class B/C software running on another processor).
SOFTWARE SYSTEM is software safety class A if:
– the SOFTWARE SYSTEM cannot contribute to a HAZARDOUS SITUATION; or
– the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which does not result in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM.
Additional Requirements
Applying a new version comes with a price for the class A software. You need to do the following if you choose to use IEC 62304:
there must be tests cases for the software requirements
you need to manage issues found during testing
you need to do regression tests after changes
you need verify that the testing approach is good (e.g. that there is a complete and documented traceability to software requirements)
you need to maintain the test records (e.g. with pass fail information, tester etc.)
before releasing the device you need to make sure that the tests have been all done
you need to evaluate and report known issues when releasing the device
and finally analyze change requests before implementing them
Conclusion
The above actually looks like a quite a bit of additional work but if you follow any best practice or common approach for software development you will do most of the above work anyhow.
It seems the only exception would be highly agile processes where you move from one user story to the next until you think you are done. But in that case you can still easily extract some software requirements while you move along and link them to the user stories which you use for verification and you will be halfway there.