formance requirements. The medical device
manufacturer needs to ensure the proper op-
eration of any SOUP items and that they meet
the functional and performance requirements.
The IEC 62304 software development process
begins with the software development planning,
which includes a detailed plan on the SOUP
items to be used. These details define how
SOUP items are to be integrated within the
existing system, how to manage the risk asso-
ciated with the SOUP, and how software con-
figuration and change management affect the
system. This is then followed by software re-
quirement management, architecture design,
integration testing, system testing, risk man-
agement, maintenance and change manage-
ment phase. At each phase of the software de-
velopment life cycle there is a need to maintain
the traceability between each phase.
The traditional view of software development
shows each phase flowing into the next, perhaps
with feedback to earlier phases, and a sur-
rounding framework of configuration man-
agement and process. Traceability is assumed
to be part of the relationships between the
phases. However, the mechanism by which
trace links are recorded is seldom stated. In re-
ality, however, while each individual phase may
be conducted efficiently thanks to investment
in up-to-date tool technology, these tools sel-
dom contribute automatically to any traceability
between the phases. As a result, the links be-
tween them become increasingly poorly main-
tained over the duration of projects. The net
result is absent or superficial cross-checking
between requirements and implementation
and consequent inadequacies in the resulting
system. To gain true automated traceability re-
quires a requirements traceability matrix (RTM)
since the RTM sits at the heart of every project
and is a key deliverable within many develop-
ment standards, including IEC 62304.
The requirement traceability matrix - a widely
accepted practice to manage and trace require-
ments - plays a vital role in managing the soft-
ware requirements as well as the SOUP items
to be used in the system. RTM helps to establish
traceability between the high-level requirements
pertaining to SOUP with the architectural de-
sign of the medical device application.
To ensure SOUP can meet the system-level re-
quirements outlined by IEC 62304, the medical
device manufacturer needs to specify: 1) func-
tional and performance requirements for the
SOUP item necessary for its intended use, 2)
manufacturer specifications for the system
hardware and software necessary to support
the proper operation of the SOUP item, and
3) details to verify that medical device archi-
tecture supports proper operation of any SOUP
items. In most cases, the SOUP items are de-
livered in source, but without design docu-
ments, which makes it difficult to analyse
them. Use of modern test tools helps in visual-
ising the legacy code design. The system visu-
alisation facilities provided by modern test
tools are extremely powerful, whether applied
to statement blocks, procedures (or classes),
applications and/or system wide. The static
call graphs shown in figure 3a depict a hierar-
chical illustration of the application and system
entities, and the static flow graphs shown in
Figure 3b show the control flow across program
blocks. The use of colour-coded diagrams pro-
vides considerable benefit in understanding
SOUP. Such call graphs and flow graphs are
just part of the benefit of the comprehensive
analysis of all parameters and data objects
used in the code.
Requirement management and traceability
have already proven their advantage in the
software development lifecycle to ensure that
all requirements are implemented and that all
development artefacts can be traced back to
one or more requirements. Similarly, require-
ment management and traceability ensure that
SOUP items are added and verified based on
system requirements. RTM provides traceability
between the architectural design and the SOUP
items. Since these items are delivered in source
code and are now required to fulfil system-
level testing for compliance to IEC 62304, it
becomes the manufacturer responsibility to
verify the code. The sloppiness of most SOUP
items adds stress to the requirement of rigorous
verification and risk analysis for the system in-
tegrator. Because verifying SOUP is so time-
consuming, developers typically address a sub-
set of the coding standard initially, gradually
adopting additional rules. While test tools only
identify, not correct, the violation and latent
errors present in the code, they do speed cor-
rection of code by pinpointing problem areas.
IEC 62304 expects the medical device manu-
facturer to evaluate the software anomaly lists
published by the supplier of the SOUP item to
determine if any of the known anomalies could
result in a sequence of events that could result
in a hazardous situation. Static analysis capa-
bility of the test tools identifies the anomalies
and their impact on the software system, and
if any additional anomalies, which are not part
of the list published by the supplier of SOUP
are identified, they should be conveyed to the
respective vendor to address the problem.
After static analysis and correction of anomalies
is complete, dynamic analysis (including system,
integration and unit testing) is performed to
verify the functional and structural coverage
of the SOUP items. Although system-wide
functional testing provides the functional
overview of the SOUP items, it does not test
all code paths. Test tools identify the exercised
parts of the software highlighting the area
which requires attention, and these areas are
put through unit test to ensure each unit func-
tions correctly in isolation.
Figure 3. The static call graph (a) and flow graph (b) represent the structure and the logic of the
code in graphical form.
S
OFTWARE
D
EVELOPMENT
22
October 2013
