Thorough software development planning is vital to success. The foundations for an efficient development cycle can be established by using tools that can facilitate structured requirements definition, such that those requirements can be confirmed as met by means of automated document (or artifact) generation. IEC 62304 dictates that medical device software must include appropriate risk control measures in its system requirements.

The preparation of a mechanism to demonstrate that the requirements have been met will involve the development of detailed plans. A prominent example would be the software verification plan to include tasks to be performed during software verification and their assignment to specific resources.

5.2 Software Requirements Analysis

Once each system requirement has been identified in such a way as to make it possible to demonstrate traceability right from the system requirement through to software system testing, and to show this risk control measures have been accounted for, the next step is to derive and document the software requirements from the system requirements.

Achieving a format that lends itself to bi-directional traceability will help to achieve compliance with the standard. Bigger projects, perhaps with contributors in geographically diverse locations, are likely to benefit from an application life cycle management tool such as IBM® Rational® DOORS®, Siemens® Polarion® PLM®, or more generally, similar tools offering support for standard Requirements Interchange Formats. Smaller projects can cope admirably with carefully worded Microsoft® Word® or Microsoft Excel® documents, written to facilitate links up and down the V model.5–7

Fig. 3 Automating requirements traceability with the TBmanager component of the LDRA tool suite.

Requirements rarely remain unchanged throughout the lifetime of a project, and that can turn the maintenance of a traceability matrix into an administrative nightmare. A requirements traceability tool alleviates this concern by automatically maintaining the connections between the requirements, development, and testing artifacts and activities. Any changes in the associated documents or software code are automatically highlighted such that any tests required to be revisited can be dealt with accordingly (see Figure 3).

5.3 Software Architectural Design

The software architectural design activity requires the manufacturer to define the major structural components of the software, their externally visible properties, and the relationships between them. Any software component behavior that can affect other components should be described in the software architecture, such that all software requirements can be implemented by the specified software items. This is generally verified by technical evaluation.

Since the software architecture is based on the requirements, developing the architecture means defining the interfaces between the software items that will implement the requirements. Many of these software elements will be created by the project, but some may be brought in from other projects even in the form of third-party libraries. Such code must be shown to comply with the project’s functional and performance requirements.

In addition, some architectural elements may need to be segregated for risk management purposes, such that their connections to the other elements then become part of the overall architecture. Tools can help in many elements of the architectural design process, including requirements specification, design model traceability, and verification.

If a model-based approach is taken to software architectural design — for example, using MathWorks® Simulink®, IBM Rational Rhapsody®, or ANSYS® SCADE — then a tool suite that is integrated with the chosen modelling tools will make the analysis of generate code and traceability to the models far more seamless.8–10

5.4 Software Detailed Design

Once requirements and architecture are defined and verified, detailed design can be built on this foundation. Detailed design specifies algorithms, data representations, and interfaces between different software units and data structures. Because implementation depends on detailed design, it is necessary to verify the detailed design before the activity is complete, generally by means of a technical evaluation of the detailed design as a whole, and verification of each software unit and its interfaces.

Fig. 4 Diagrammatic representations of control and data flow generated from source code by the LDRA tool suite aid verification of software architectural and detailed design.

Later in the development cycle, a tool suite can help by generating graphical artifacts suited to the review of the implemented design by means of walkthroughs or inspections. One approach is to prototype the software architecture in an appropriate programming language, which can also help to find any anomalies in the design. Graphical artifacts like call graphs and flow graphs, are well suited for use in the review of the implemented design by visual inspection (see Figure 4).

Part 2 of this article will look at the second part of the project life cycle involving the implementation of the now-established design in the form of source code. It will consider how static analysis can help to ensure that coding rules are adhered to, helping to minimize errors in the developed application. It will discuss how dynamic analysis in the form of system and unit tests show that the design has been implemented correctly and completely, and that the software has been properly exercised during test and prior to release. Finally, it will outline how the influence of IEC 62304 extends to the maintenance and modification of the product once out in the field.

This article was written by Mark Pitchford, Technical Specialist for LDRA (Wirral, UK).