tools to use, what your documents need to be called (or even
their format or content), and what kind of software development path (waterfall, incremental, etc.) you should follow.
IEC62304 does, however, provide a framework. It identi-fies requirements on what needs to be done and documented
for each activity and task. It indicates which parts apply to
the three classes of device (A through C, where the failure of
class C software could result in serious injury or death). At its
core, IEC 62304 gives developers the freedom to use relevant,
state-of-the-art tools, in the context of a well-defined process.
It assumes that manufacturers know more about their products
than regulators and implicitly puts the onus on manufacturers
to use their best development practices. The standard recognizes that one size does not fit all.
So where is the intersection of “specified” and “not specified?” For example, the standard doesn’t specify the development method and thus leaves it up to the manufacturer. But
the manufacturer needs to choose a development method
that maps the processes, activities, and tasks defined by the
standard. Put another way, the manufacturer can’t select a
development method that doesn’t have traceability, because
traceability is fundamental to the requirements of the standard.
As a software developer, being on the hook for someone’s life
is a serious responsibility. Hacking together some software
and saying “good enough, ship it” is not an option. Coming up
with your own criteria for when the software is “good enough”
is also not a good idea — you’re likely to miss a key test or development methodology that will then be found to contribute
to a patient’s death. Lawyers love that kind of stuff.
Minimizing the Scope of Certification
IEC 62304 provides a provision to partition the software
system and allows the system designer to assign the partitions
IEC 62304 helps with a risk-based approach for the software
development life cycle, making development more stringent, but