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