SECTION 3.

CONTEXT FOR SOFTWARE VALIDATION Many people have asked for specific guidance on
what FDA expects them to do to ensure compliance with the Quality System regulation with regard to
software validation. Information on software validation presented in this document is not new.
Validation of software, using the principles and tasks listed in Sections 4 and 5, has been conducted in
many segments of the software industry for well over 20 years. Due to the great variety of medical
devices, processes, and manufacturing facilities, it is not possible to state in one document all of the
specific validation elements that are applicable. However, a general application of several broad
concepts can be used successfully as guidance for software validation. These broad concepts provide an
acceptable framework for building a comprehensive approach to software validation. Additional specific
information is available from many of the references listed in Appendix A. 3.1. DEFINITIONS AND
TERMINOLOGY Unless defined in the Quality System regulation, or otherwise specified below, all other
terms used in this guidance are as defined in the current edition of the FDA Glossary of Computerized
System and Software Development Terminology. The medical device Quality System regulation (21 CFR
820.3(k)) defines "establish" to mean "define, document, and implement." Where it appears in this
guidance, the words "establish" and “established” should be interpreted to have this same meaning.
Some definitions found in the medical device Quality System regulation can be confusing when
compared to commonly used terminology in the software industry. Examples are requirements,
specification, verification, and validation. 3.1.1 Requirements and Specifications While the Quality
System regulation states that design input requirements must be documented, and that specified
requirements must be verified, the regulation does not further clarify the distinction between the terms
“requirement” and “specification.” A requirement can be any need or expectation for a system or for its
software. Requirements reflect the stated or implied needs of the customer, and may be market-based,
contractual, or statutory, as well as an organization's internal requirements. There can be many different
kinds of requirements (e.g., design, functional, implementation, interface, performance, or physical
requirements). Software requirements are typically derived from the system requirements for those
aspects of system functionality that have been allocated to software. Software requirements are typically
stated in functional terms and are defined, refined, and updated as a development project progresses.
Success in accurately and completely documenting software requirements is a crucial factor in successful
validation of the resulting software. Page 6 Guidance for Industry and FDA Staff General Principles of
Software Validation A specification is defined as “a document that states requirements.” (See 21 CFR
§820.3(y).) It may refer to or include drawings, patterns, or other relevant documents and usually
indicates the means and the criteria whereby conformity with the requirement can be checked. There
are many different kinds of written specifications, e.g., system requirements specification, software
requirements specification, software design specification, software test specification, software
integration specification, etc. All of these documents establish “specified requirements” and are design
outputs for which various forms of verification are necessary. 3.1.2 Verification and Validation The
Quality System regulation is harmonized with ISO 8402:1994, which treats “verification” and “validation”
as separate and distinct terms. On the other hand, many software engineering journal articles and
textbooks use the terms "verification" and "validation" interchangeably, or in some cases refer to
software "verification, validation, and testing (VV&T)" as if it is a single concept, with no distinction
among the three terms. Software verification provides objective evidence that the design outputs of a
particular phase of the software development life cycle meet all of the specified requirements for that
phase. Software verification looks for consistency, completeness, and correctness of the software and its
supporting documentation, as it is being developed, and provides support for a subsequent conclusion
that software is validated. Software testing is one of many verification activities intended to confirm that
software development output meets its input requirements. Other verification activities include various
static and dynamic analyses, code and document inspections, walkthroughs, and other techniques.
Software validation is a part of the design validation for a finished device, but is not separately defined in
the Quality System regulation. For purposes of this guidance, FDA considers software validation to be
“confirmation by examination and provision of objective evidence that software specifications conform
to user needs and intended uses, and that the particular requirements implemented through software
can be consistently fulfilled.” In practice, software validation activities may occur both during, as well as
at the end of the software development life cycle to ensure that all requirements have been fulfilled.
Since software is usually part of a larger hardware system, the validation of software typically includes
evidence that all software requirements have been implemented correctly and completely and are
traceable to system requirements. A conclusion that software is validated is highly dependent upon
comprehensive software testing, inspections, analyses, and other verification tasks performed at each
stage of the software development life cycle. Testing of device software functionality in a simulated use
environment, and user site testing are typically included as components of an overall design validation
program for a software automated device. Software verification and validation are difficult because a
developer cannot test forever, and it is hard to know how much evidence is enough. In large measure,
software validation is a matter of developing a “level of confidence” that the device meets all
requirements and user expectations for the software automated functions and features of the device.
Measures such as defects found in specifications documents, estimates of defects remaining, testing
coverage, and other techniques are all used to Page 7 Guidance for Industry and FDA Staff General
Principles of Software Validation develop an acceptable level of confidence before shipping the product.
The level of confidence, and therefore the level of software validation, verification, and testing effort
needed, will vary depending upon the safety risk (hazard) posed by the automated functions of the
device. Additional guidance regarding safety risk management for software may be found in Section 4 of
FDA’s Guidance for the Content of Pre-market Submissions for Software Contained in Medical Devices,
and in the international standards ISO/IEC 14971-1 and IEC 60601-1-4 referenced in Appendix A. 3.1.3
IQ/OQ/PQ For many years, both FDA and regulated industry have attempted to understand and define
software validation within the context of process validation terminology. For example, industry
documents and other FDA validation guidance sometimes describe user site software validation in terms
of installation qualification (IQ), operational qualification (OQ) and performance qualification (PQ).
Definitions of these terms and additional information regarding IQ/OQ/PQ may be found in FDA’s
Guideline on General Principles of Process Validation, dated May 11, 1987, and in FDA’s Glossary of
Computerized System and Software Development Terminology, dated August 1995. While IQ/OQ/PQ
terminology has served its purpose well and is one of many legitimate ways to organize software
validation tasks at the user site, this terminology may not be well understood among many software
professionals, and it is not used elsewhere in this document. However, both FDA personnel and device
manufacturers need to be aware of these differences in terminology as they ask for and provide
information regarding software validation. 3.2. SOFTWARE DEVELOPMENT AS PART OF SYSTEM DESIGN
The decision to implement system functionality using software is one that is typically made during
system design. Software requirements are typically derived from the overall system requirements and
design for those aspects in the system that are to be implemented using software. There are user needs
and intended uses for a finished device, but users typically do not specify whether those requirements
are to be met by hardware, software, or some combination of both. Therefore, software validation must
be considered within the context of the overall design validation for the system. A documented
requirements specification represents the user's needs and intended uses from which the product is
developed. A primary goal of software validation is to then demonstrate that all completed software
products comply with all documented software and system requirements. The correctness and
completeness of both the system requirements and the software requirements should be addressed as
part of the design validation process for the device. Software validation includes confirmation of
conformance to all software specifications and confirmation that all software requirements are traceable
to the system specifications. Confirmation is an important part of the overall design validation to ensure
that all aspects of the medical device conform to user needs and intended uses. Page 8 Guidance for
Industry and FDA Staff General Principles of Software Validation 3.3. SOFTWARE IS DIFFERENT FROM
HARDWARE While software shares many of the same engineering tasks as hardware, it has some very
important differences. For example: · The vast majority of software problems are traceable to errors
made during the design and development process. While the quality of a hardware product is highly
dependent on design, development and manufacture, the quality of a software product is dependent
primarily on design and development with a minimum concern for software manufacture. Software
manufacturing consists of reproduction that can be easily verified. It is not difficult to manufacture
thousands of program copies that function exactly the same as the original; the difficulty comes in
getting the original program to meet all specifications. · One of the most significant features of software
is branching, i.e., the ability to execute alternative series of commands, based on differing inputs. This
feature is a major contributing factor for another characteristic of software – its complexity. Even short
programs can be very complex and difficult to fully understand. · Typically, testing alone cannot fully
verify that software is complete and correct. In addition to testing, other verification techniques and a
structured and documented development process should be combined to ensure a comprehensive
validation approach. · Unlike hardware, software is not a physical entity and does not wear out. In fact,
software may improve with age, as latent defects are discovered and removed. However, as software is
constantly updated and changed, such improvements are sometimes countered by new defects
introduced into the software during the change. · Unlike some hardware failures, software failures occur
without advanced warning. The software’s branching that allows it to follow differing paths during
execution, may hide some latent defects until long after a software product has been introduced into the
marketplace. · Another related characteristic of software is the speed and ease with which it can be
changed. This factor can cause both software and non-software professionals to believe that software
problems can be corrected easily. Combined with a lack of understanding of software, it can lead
managers to believe that tightly controlled engineering is not needed as much for software as it is for
hardware. In fact, the opposite is true. Because of its complexity, the development process for software
should be even more tightly controlled than for hardware, in order to prevent problems that cannot be
easily detected later in the development process. · Seemingly insignificant changes in software code can
create unexpected and very significant problems elsewhere in the software program. The software
development process should be sufficiently well planned, controlled, and documented to detect and
correct unexpected results from software changes. Page 9 Guidance for Industry and FDA Staff General
Principles of Software Validation · Given the high demand for software professionals and the highly
mobile workforce, the software personnel who make maintenance changes to software may not have
been involved in the original software development. Therefore, accurate and thorough documentation is
essential. · Historically, software components have not been as frequently standardized and
interchangeable as hardware components. However, medical device software developers are beginning
to use component-based development tools and techniques. Object-oriented methodologies and the
use of off-the-shelf software components hold promise for faster and less expensive software
development. However, component-based approaches require very careful attention during integration.
Prior to integration, time is needed to fully define and develop reusable software code and to fully
understand the behavior of off-the-shelf components. For these and other reasons, software engineering
needs an even greater level of managerial scrutiny and control than does hardware engineering. 3.4.
BENEFITS OF SOFTWARE VALIDATION Software validation is a critical tool used to assure the quality of
device software and software automated operations. Software validation can increase the usability and
reliability of the device, resulting in decreased failure rates, fewer recalls and corrective actions, less risk
to patients and users, and reduced liability to device manufacturers. Software validation can also reduce
long term costs by making it easier and less costly to reliably modify software and revalidate software
changes. Software maintenance can represent a very large percentage of the total cost of software over
its entire life cycle. An established comprehensive software validation process helps to reduce the long-
term cost of software by reducing the cost of validation for each subsequent release of the software. 3.5
DESIGN REVIEW Design reviews are documented, comprehensive, and systematic examinations of a
design to evaluate the adequacy of the design requirements, to evaluate the capability of the design to
meet these requirements, and to identify problems. While there may be many informal technical reviews
that occur within the development team during a software project, a formal design review is more
structured and includes participation from others outside the development team. Formal design reviews
may reference or include results from other formal and informal reviews. Design reviews may be
conducted separately for the software, after the software is integrated with the hardware into the
system, or both. Design reviews should include examination of development plans, requirements
specifications, design specifications, testing plans and procedures, all other documents and activities
associated with the project, verification results from each stage of the defined life cycle, and validation
results for the overall device. Design review is a primary tool for managing and evaluating development
projects. For example, formal design reviews allow management to confirm that all goals defined in the
software validation plan have Page 10 Guidance for Industry and FDA Staff General Principles of Software
Validation been achieved. The Quality System regulation requires that at least one formal design review
be conducted during the device design process. However, it is recommended that multiple design
reviews be conducted (e.g., at the end of each software life cycle activity, in preparation for proceeding
to the next activity). Formal design review is especially important at or near the end of the requirements
activity, before major resources have been committed to specific design solutions. Problems found at
this point can be resolved more easily, save time and money, and reduce the likelihood of missing a
critical issue. Answers to some key questions should be documented during formal design reviews. These
include: · Have the appropriate tasks and expected results, outputs, or products been established for
each software life cycle activity? · Do the tasks and expected results, outputs, or products of each
software life cycle activity: ¸ Comply with the requirements of other software life cycle activities in terms
of correctness, completeness, consistency, and accuracy? ¸ Satisfy the standards, practices, and
conventions of that activity? ¸ Establish a proper basis for initiating tasks for the next software life cycle
activity?