IVTJVT1107.qxd
10/8/07
3:27 PM
Page 54
System Definition:
Defining the Intended
Use for a System
B Y R O B E RT W. S TOT Z , P H . D.
❖
INTRODUCTION
The author first met Mr. Chapman in June 1987 as a
new member of the PhRMA's (formerly the PMA's)
Computer Systems Validation Committee (CSVC) which
had reconvened to address the source code issue1 and
eventually launch the “Staying Current” series of articles.2 This was the start of a long term collaboration between Mr. Chapman and the author that included a
number of years on the CSVC followed by co-authoring,
as part of the Parenteral Drug Association (PDA) Committee on Validation of Computer-Related Systems, the
computer-related system requirements section of their
Technical Report No. 183 and subsequently an article4
published in the October-November 1992 Journal of Parenteral Science and Technology entitled “Validation of
Automated Systems - System Definition.” The following
is an update of that article.
BACKGROUND
The term associated with the document that defines
the intended use for a system has become a confusing one
because it depends upon individual and/or company preferences and the chosen lifecycle model. For the CSVC's
System Development Life Cycle (SDLC) model5 (Figure
1) defining a system's function and structure, i.e., system
definition, is equivalent to intended use for both new and
existing systems. In the PDA's Technical Report No. 18
lifecycle (Figure 2) the equivalent document is the
54
Journal of Validation Technology
“Computer-Related System Requirements,” in the
GAMP 4 Guide for Validation of Automated Systems6
(Figure 3) it is “User Requirements Specification,” and in
the Institute of Validation Technology's Proposed Validation Standard VS-27 lifecycle, which is similar to the
PDA's model, it is “Functional Requirements.”
Although variations exist, all versions of the lifecycle
models such as those below involve the same fundamentals, are compatible with each other, and all have contributed significantly to understanding how to cope with
defining requirements for systems operating in an environment subject to regulations. For the purpose of this article system definition = computer-related system
requirements = user requirements specifications = functional requirements = the intended use for a system.
THE NEED FOR SYSTEM DEFINITION
The following three paragraphs quoted from the original article have proven to be as true today as they were
fifteen years ago:
“An automated (computerized) system can
be defined as an assembly of multiple units
consisting of one or more microprocessors,
and associated hardware and software that
controls and/or monitors without human intervention a specific set of sequential activities such as a plant process, laboratory
function, or data processing operation.
IVTJVT1107.qxd
10/8/07
3:27 PM
Page 55
Robert W. Stotz, Ph.D.
Figure 1
Upper Part of PhRMA's System Development Life Cycle
New Computer
Define System
Function Structure
Existing Computer
Define System
Function Structure
Define
Software
Design/specify
Hardware
Qualify
System
Develop
Software
Install
Hardware
Review Operating
Experience
Verify
Software
Qualify
Hardware
Defining that system in terms of its requirements (what the system must do) and specifications (how the system will meet its
requirements) are the first, and probably
most important, steps in building a quality
system. Clear definition of requirements and
specifications results in systems that are
more straightforward to construct, easier to
operate, better documented, and more reliable. As a result of being more reliable, they
are easier and less costly to maintain. If outside vendors are involved, vendor/user relationships improve and vendors are better
able to determine and meet user needs.
“Defining and validating automated systems
require close teamwork and effective communications among many, diverse disciplines.
This multidisciplinary team should include
system users and others involved with its design and implementation, and subsequent
maintenance. The eventual users of the system are often overlooked at the early planning stage of system development. This
oversight often results in automated systems
that are difficult to operate and costly to
maintain.
“The multidisciplinary team may consist of
representatives from most. if not all, of the
following disciplines: manufacturing, automation engineering, technology developN ove m b e r 2 0 0 7 • Vo l u m e 1 4 , N u m b e r 1
55
IVTJVT1107.qxd
10/8/07
3:27 PM
Page 56
Robert W. Stotz, Ph.D.
Figure 2
Upper Part of PDA's Life Cycle
1
Plan
Validation
Activities
2
Define
Computer-related
System Requirements
Validation Policies
Validation
Project Plan
Validation SOPs
Functional
Requirements
Design
Requirements
ment, quality assurance and quality control,
information services, systems analysis, programming, and other software, hardware,
and equipment consultants. Teamwork is essential since it is almost impossible for one
person or one discipline to have all the expertise required to develop today's automated system and also assure its quality.”
Failure to adequately define the intended use of a system at the beginning of a project has been, and continues
to be, universally recognized as the most frequent reason
for failure involving computer system design and/or validation. In the 15 years that have elapsed since the original article published the importance of a
multidisciplinary approach to clearly defining a system's
intended use, it has become even more evident. For ex56
Journal of Validation Technology
Computer-related
System Requirements
ample, the following was excerpted from a 1995 article8
on the subject:
“The significance of system definition is acknowledged by the Food and Drug Administration. Indeed, when inspecting a
computer-related system, FDA officials most
often request system definition documentation, along with a project validation plan. In
May 1993, Sam Clark, a former FDA administrator and an expert on national computer
systems validation, reinforced this point.
During a roundtable discussion of computer
systems validation, he commented that 'failure to adequately define computer systems is
the most common problem found in FDA inspections.' Former FDA investigator Ron
IVTJVT1107.qxd
10/8/07
3:27 PM
Page 57
Robert W. Stotz, Ph.D.
Figure 3
GAMP 4 Basic Framework for Specification and Qualification
Performance
Qualification
User Requirements
Specification
Verifies
Functional
Specification
Operational
Qualification
Verifies
Installation
Qualification
Design
Specification
Verifies
System Build
Tetzlaff agrees. In the second of a three-part
series of articles9 entitled 'GMP Documentation Requirements for Automated Systems,'
he stated that specifications are 'reliable predictors of GMP documentation problems.'
Tetzlaff went on to say that it 'may seem obvious that specifications should be complete
and meaningful, but many firms have been
unsuccessful in their efforts to define them.
There are several reasons that this task is so
difficult, including the many variables, diverse operations, and controls that can function independently or be interrelated.”
Note: Tetzlaff defines “specifications” as
“written documents that clearly and completely describe what the system is supposed
to do. Specifications apply to both hardware
and software and describe applicable functions, requirements and procedures.” This
definition is consistent with the term “system
definition” used in this article.
The following FDA events (It is recognized that there
have also been significant events in the international regulatory and professional organization sectors that have
impacted the topic of system definition, but to keep this
article to a manageable size, its focus is limited to FDA
events.) since the original article published in 1992 have
further emphasized the importance of system definition:
N ove m b e r 2 0 0 7 • Vo l u m e 1 4 , N u m b e r 1
57
IVTJVT1107.qxd
10/8/07
3:27 PM
Page 58
Robert W. Stotz, Ph.D.
• 21 CFR Parts 808, 812, and 820, “Medical Devices;
Current Good Manufacturing Practice (CGMP);
Final Rule” published in October 1996.
• 21 CFR Part 11 became effective in August 1997,
policy guide 7153.17 issued in July 1999 followed
by five Part 11 guidance documents in 2001/2002.
The policy guide and five guidance documents were
subsequently withdrawn in February 2003, and replaced in September 2003 with Docket No. 2003D0060, “Guidance for Industry, Part 11, Electronic
Records; Electronic Signatures - Scope and Application.”
• FDA published their systems-based inspectional
program (Compliance Program Guidance Manual
Program 7356.002) in February 2002, and in September 2004 a draft guidance subsequently replaced
by the final guidance in September 2006, both entitled: “Quality Systems Approach to Pharmaceutical
Current Good Manufacturing Practice Regulations”
that defines the role of quality systems in the pharmaceutical current good manufacturing practice regulations. Both the draft and the final guidance were
developed by the quality systems working group
(now the Council on Pharmaceutical Quality)
formed as part of the Pharmaceutical CGMPs for the
21st Century: A Risk Based Approach initiative.
• FDA issued their new GMP initiative in August
2002 that described an increased focus on those aspects of manufacturing that pose the greatest potential risk, and their intent to integrate quality systems
and risk management approaches into its existing
programs with the goal of encouraging industry to
adopt modern and innovative manufacturing technologies. The final report on the new initiative published in September 2004.
• Publication of several guides/guidances relevant to
computer systems such as “Design Control Guidance for Medical Device Manufacturers” in March
1997, “Off-The-Shelf Software Use in Medical Devices” in September 1999, and “General Principles
of Software Validation; Final Guidance for Industry
and FDA Staff” in January 2002.
Section 820.1(z) of the medical devices CGMP defines validation as “confirmation by examination and
58
Journal of Validation Technology
provision of objective evidence that the particular requirements for a specific intended use can be consistently
fulfilled,” and 820.25(c) covering design input states in
part:
“Each manufacturer shall establish and
maintain procedures to ensure that the design requirements relating to a device are
appropriate and address the intended use of
the device, including the needs of the user
and patient… The design input requirements
shall be documented and shall be reviewed
and approved by a designated individual(s).
The approval, including the date and signature of the individual(s) approving the requirements, shall be documented.”
A common error found in many “system definition”
documents is a description of a system's capabilities,
often extracted from vendor provided information, rather
than a definition of intended use. The impact of this type
of error is particularly acute relative to Part 11 requirements when a system has extensive capabilities for generating or maintaining electronic records and/or utilizing
electronic signatures and only a portion of these capabilities are intended to be used. The end result is wasted
time and resources in extensively testing a system's capabilities rather than the portion of those capabilities that
are intended to be used.
The Facilities and Equipment section of the Quality
Systems Approach to Pharmaceutical Current Good
Manufacturing Practice Regulations guidance states:
“Under a quality system, the technical experts (e.g., engineers, development scientists), who have an understanding of
pharmaceutical science, risk factors, and
manufacturing processes related to the product, are responsible for defining specific facility and equipment requirements,” The
Glossary section defines validation as:
“Confirmation, through the provision of objective evidence, that the requirements for a
specific intended use or application have
been fulfilled.”
IVTJVT1107.qxd
10/8/07
3:27 PM
Page 59
Robert W. Stotz, Ph.D.
The Quality Systems guidance also addresses outsourced services. The section titled Control Outsourced
Operations states in part:
“Under a quality system, the manufacturer
should ensure that a contract firm is qualified before signing a contract with that firm.
The contract firm's personnel should be adequately trained and monitored for performance according to their quality system, and
the contract firm's and contracting manufacturer's quality standards should not conflict.
It is critical in a quality system to ensure that
the management of the contractor be familiar
with the specific requirements of the contract.”
Although the FDA's new GMP initiative and the final
report on the new initiative do not specifically address
defining the intended use of an automated system/equipment, their impact on system definition is obvious. One
can not focus on those aspects of manufacturing that pose
the greatest potential risk without first defining the intended use of the automated system/equipment utilized in
the manufacturing process.
The waterfall design process depicted in the Design
Control Guidance for Medical Device Manufacturers
shows the process proceeding in a logical sequence of
phases or stages starting with user needs being incorporated into the design input. The guidance goes on to
state:
“Each design input is converted into a new
design output; each output is verified as conforming to its input; and it then becomes the
design input for another step in the design
process. In this manner, the design input requirements are translated into a device design conforming to those requirements.”
requirements are not identified until validation, expensive redesign and rework may be
necessary before a design can be released to
production.”
Eventually the final medical device is validated
against the user needs. As stated in the guidance: “Basically, requirements are developed, and a device is designed to meet those requirements.”
The Design Control Guidance for Medical Device
Manufacturers also states: “…design input requirements
fall into three categories. Virtually every product will
have requirements of all three types:
• “Functional requirements specify what the
device does, focusing on the operational
capabilities of the device and processing of
inputs and the resultant outputs.
• “Performance requirements specify how
much or how well the device must perform,
addressing issues such as speed, strength,
response times, accuracy, limits of operation, etc. This includes a quantitative characterization of the use environment,
including, for example, temperature, humidity, shock, vibration, and electromagnetic compatibility. Requirements
concerning device reliability and safety
also fit into this category.
• “Interface requirements specify characteristics of the device which are critical to
compatibility with external systems; specifically, those characteristics which are mandated by external systems and outside the
control of the developers. One interface
which is important in every case is the user
and/or patient interface.”
The guidance also states:
“Development of a solid foundation of requirements is the single most important design control activity,” and “If essential
The FDA guidance on Off-The-Shelf Software Use in
Medical Devices provides a series of six questions, with
additional questions following each of the primary six, to
help define the basic documentation requirements for
N ove m b e r 2 0 0 7 • Vo l u m e 1 4 , N u m b e r 1
59
IVTJVT1107.qxd
10/8/07
3:27 PM
Page 60
Robert W. Stotz, Ph.D.
OTS software. The following is an adaptation of those
questions that can be used as an aid in defining the intended use of OTS software.
1. What is it?
For each component of OTS software used, specify
the following:
• Title and Manufacturer of the software
• Version Level, Release Date, Patch Number, and
Upgrade Designation as appropriate
• Any software documentation that will be provided to the end user
• Why this OTS software is appropriate for its intended use
2. What are the computer system specifications for
the OTS software?
For what configuration will the OTS software be
validated? Specify the following:
• Hardware specifications: processor (manufacturer, speed, and features), RAM (memory size),
hard disk size, other storage, communications,
display, etc.
• Software specifications: operating system, drivers, utilities, etc. The software requirements
specification (SRS) listing for each item should
contain the name (e.g., Windows 95, Excel, Sun
OS, etc.), specific version levels (e.g., 4.1, 5.0,
etc.) and a complete list of any patches that have
been provided by the OTS software manufacturer.
3. How will you assure appropriate actions are
taken by the end user?
• What aspects of the OTS Software and system
can (and/or must) be installed/configured?
• What steps are permitted (or must be taken) to install and/or configure the product?
• How often will the configuration need to be
changed?
• What education and training are suggested or required for the user of the OTS software?
• What measures have been designed into the computer system to prevent the operation of any nonspecified OTS software, e.g., word processors,
games?
60
Journal of Validation Technology
4. What does the OTS software do? What function does the OTS software provide in
the computer system? Specify the following:
• What is the OTS software intended to do? The design documentation should specify exactly which
OTS components will be included in the design of
the computer system. Specify to what extent OTS
software is involved in error control and messaging
in the computer system error control.
• What are the links with other software including
software outside the computer system (not reviewed as part of this or another application)?
The design documentation should include a complete description of the linkage between the computer system software and any outside software
(e.g., networks).
5.
How will you know the OTS software works?
• Describe testing, verification, and validation of
the OTS software. Software test, verification,
and validation plans should identify the exact
OTS software (title and version) that is to be
used in the computer system. When the OTS
software is tested it should be integrated and
tested using the specific OTS software that will
be delivered to the end user.
• Is there a current list of OTS software problems
(bugs) and access to updates?
6.
How will you keep track of (control) the OTS
software?
An appropriate plan should answer the following
questions:
• What measures have been designed into the
computer system to prevent the introduction of
incorrect versions? On startup, ideally, the computer system should check to verify that all software is the correct title, version level, and
configuration. If the correct software is not
loaded, the computer system should warn the
operator and shut down to a safe state.
• How will you maintain the OTS software configuration?
• Where and how will you store the OTS Software?
IVTJVT1107.qxd
10/8/07
3:27 PM
Page 61
Robert W. Stotz, Ph.D.
• How will you ensure proper installation of the
OTS software?
• How will you ensure proper maintenance and
lifecycle support for the OTS software?
The FDA guidance on General Principles of Software
Validation describes how certain provisions of the medical device Quality System regulation, which became effective in June 1997, applys to software and the agency's
current approach to evaluating a software validation system. Validation of software is a requirement of the medical device Quality System regulation, i.e., Title 21 Code
of Federal Regulations (CFR) Part 820, and applies to
software used as components in medical devices, to software that is itself a medical device, and to software used
in production of the device or in implementation of the
device manufacturer's quality system. Although the
guidance is directed at the medical device industry, it is
based on generally recognized software validation principles, and can therefore, be applied to any software.
Section 2.4 of this guidance (Regulatory Requirements for Software Validation states in part:
“All production and/or quality system software, even
if purchased off-the-shelf, should have documented requirements that fully define its intended use, and information against which testing results and other evidence
can be compared, to show that the software is validated
for its intended use.” The guidance defines a “requirement” as “any need or expectation for a system or for its
software,” and goes on to state: “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.”
DEFINING REQUIREMENTS
It should be clear at this point that the first and most
vital step in defining an automated system is the definition of its requirements, i.e., its intended use. The requirements are the foundation for the system
specifications and all subsequent design documents. One
cannot prove that a system does what it is intended to do
if just what it is intended to do has not been clearly defined. The requirements define "what" the system is to do
rather than "how" it will perform a given task.
Definition of a system's requirements frequently begins with a preliminary concept of the required (and desired) functions of the new system. Through an iterative
process with input from the system's users and others involved with the design and implementation of the system,
the requirements are further refined in terms of required
functions (needs or musts), desired functions (wants),
data to be processed, design constraints, performance and
documentation requirements, and validation criteria. The
desired functions or wants should be prioritized. The
ability to understand both the activities being automated
as well as the needs of the individuals or operators who
will be using the system is necessary in defining the requirements. In many cases, these needs may not be
known at the beginning of the project, but they must nevertheless be anticipated to the greatest degree possible.
A rigorous review and verification process is required
in defining the requirements of a system that not only
considers the needs of the end-user(s) but also includes a
clear understanding of the operating environment that is
to surround the proposed system. Configurations that
might satisfy the requirements should be considered in
terms of cost; availability of required technology, facilities, equipment and effectively trained personnel; interface with current systems (e.g., enterprise resource
planning, ERP); legal liabilities; etc. Prospective vendors
can also be contacted for additional information.
Requirements can be developed using a top-down
process. General requirements for the automated system
are established first, and then more detailed requirements
are developed. In large projects, defining the requirements of each logical entity may be required. A typical
requirements document could contain the following: an
overview of the project and its objectives; expected benN ove m b e r 2 0 0 7 • Vo l u m e 1 4 , N u m b e r 1
61
IVTJVT1107.qxd
10/8/07
3:27 PM
Page 62
Robert W. Stotz, Ph.D.
efits; and financial, time, and manpower constraints. The
requirements document should describe the required and
desired control functions; sources and characteristics of
the input data; data manipulation and output requirements; technical, electrical, and mechanical requirements; human interfaces; desired timetable for
completion of important milestones in the project; and
the basis for system evaluation and validation (i.e., a
summary of the general approach to validation of the automated system). Each device and/or piece of equipment
included in, or controlled by, the automated system
should be described in the requirements document.
Block diagrams or sketches that show the physical location of the components of the system are also helpful and
should be included. The requirements document should
describe the sequence, timing, and scheduling of operations. The document should also include security requirements; safety considerations; specific hardware and
software implementation requirements; and level of education, training, and experience of each person who will
interact with the system. Personnel (i.e., in-house experts, consultants, etc.) required or available for each part
of the project, and a description of environmental factors
should be included as well. Graphical information such
as system flow charts and diagrams that show the impact
of the new system on existing manufacturing functions
and corporate data bases is useful in communication of
requirements. Definition of the requirements (intended
use) for an automated system should not be taken lightly.
The quality and ease of maintenance of the system depend on the care taken at this point in the planning phase
of the project.
A typical requirements document10 contains the following:
• Overview of the project and its objectives, expected
benefits, as well as constraints caused by finances,
time, and human resources
• Required and desired control functions
• Sources and characteristics of input data
• Data manipulation and output requirements
• Technical, electrical, and mechanical requirements
• Spare capacity
• Human/Machine Interfaces (HMIs)
• Schedule for desired completion of important milestones in the project
62
Journal of Validation Technology
• Basis for system evaluation (in terms of performance
requirements), and validation (a summary of the general approach to be used for validation of the system)
• Devices, equipment, and/or databases included in, or
controlled by, the system
• Block diagrams or sketches showing the physical location of the components of the system
Because the requirements document describes the sequence, timing, and scheduling of operations, it should
also include the following:
• Security requirements
• Safety considerations
• Specific hardware and software implementation requirements
• Level of education, training, and experience necessary for anyone interacting with the system
• Personnel (e.g., in-house subject matter experts and
consultants) required or available for each phase of
the project
• Description of environmental factors
• Graphical information, such as system flow charts
and diagrams, that demonstrates the impact of the
new system on existing manufacturing functions and
corporate databases
All activities and functions controlled, monitored, or
reported by the system, as well as their interrelationships
and sequencing, should be identified in the requirements
document. Allocate functions of the system to general
types of hardware, firmware, and/or software. Make sure
to rank the system's overall structure according to higher
and lower level activities, the discrete functions making
up each activity, and the interdependencies of the functions and activities.
The requirements document should also include flow
charts and diagrams that translate requirements and project objectives into inputs, functions, and outputs. Diagrams should reference the source of each input and the
destination of each output to indicate their relationships
with system functions. The hierarchy of activities and
functions should be clearly identified.
IVTJVT1107.qxd
10/8/07
3:27 PM
Page 63
Robert W. Stotz, Ph.D.
COMPONENTS OF THE
REQUIREMENTS DOCUMENT
The Project Overview discusses the objectives and expected benefits of implementing the system, the nature of
the project, the components of the automated activities,
the amount and type of operational support needed, future requirements that might affect system design, and
any standards and/or design constraints to which the system must adhere. This section should include alternate
approaches that also would produce desired results, and
methods of control, data acquisition, storage, reporting,
and analysis.
The Scope of Responsibilities identifies hardware and
services provided by the vendor, end user, and third party
contractors. This section should contain the following:
• Processing requirements for signal conversion
• Control algorithms (i.e., the controlling actions of
the system and the parameters to be controlled)
• Data manipulation necessary to support display or
reporting functions
• Number and format of reports
• Archival of data and reports
• Application-specific programs that may be required
(e.g., production or assay scheduling, batch recipes,
assay methods, and production tracking)
• Required utility programs (Those associated with, or
used by, the operating system for back-up; the
restarting of the system following an unplanned shut
down; tools for configuring, programming, and editing; and diagnostic and troubleshooting aids necessary for maintenance of the system)
The Scope of Responsibilities also describes field
hardware and human interfaces. Field hardware includes
the following items (as well as their physical location and
input/output requirement):
• Instruments (including intelligent instruments which
provide early warning of potential failures and significantly reduce maintenance costs for the proposed
system)
• Transducers
• Sensors
• Valves
• Activators
• Actuators (wired to the system)
Human interfaces encompass the following:
• Number of operators
• Quantity and type of data to be entered into the system
• Output to be displayed and/or printed
• Networking requirements (e.g., definition of communication protocols, polling response times, error
recovery, and link redundancy) with other systems
Security addresses requirements for protecting against
unauthorized use, levels of security, virus scanning, and
logging of access to the system. Electrical and mechanical requirements include the following:
• Power sources and characteristics
• Maintenance of system operation during a power
failure
• Atmospheric conditions at the site
• System operation hazards (e.g., electromagnetic
fields; corrosive or explosive chemicals, gases, or
dusts; or vibration)
Documentation specifies the documentation that a
vendor is expected to provide. Generally, a vendor is responsible for all documentation until installation of the
system. System qualification usually is executed on the
installed system by either the firm or a third party, although the vendor may assist in the preparation of protocols and training of personnel.
Vendor documentation should be clear. For example,
management of the firm using the system should have no
difficulty explaining the documentation during the course
of a regulatory agency inspection. In other words, end
users must demonstrate a thorough understanding of the
system's procedures and controls and a firm command of
the quality of their finished product.
Training is performed to ensure the proper operation
and maintenance of the system. Everyone who uses the
system must be trained adequately, and this instruction
must be documented. This section of the requirements
document should outline the type and amount of instruction required, as well as the materials to be provided by
the vendor.
N ove m b e r 2 0 0 7 • Vo l u m e 1 4 , N u m b e r 1
63
IVTJVT1107.qxd
10/8/07
3:27 PM
Page 64
Robert W. Stotz, Ph.D.
Figure 4
Requirements/Specifications and PhRMA's Lifecycle Model
User
Requirements
Functional
Description
Contact
Prospective Vendors
Functional
Requirements
System
Requirements
Design
Requirements
System
Definition
Define System
Function
Structure
Requests for
Proposal
System
Specification
Vendor
Selection
Define
Software
64
Journal of Validation Technology
System
Specifications
Define/Specify
Hardware
IVTJVT1107.qxd
10/8/07
3:27 PM
Page 65
Robert W. Stotz, Ph.D.
Qualification/Validation Requirements define vendor
qualification, system qualification before and after installation (i.e. factory and site acceptance testing, FAT and
SAT), system support, and system evaluation and acceptance. Vendor qualification refers to the items incorporated in an audit or assessment of vendor operations,
including:
• Successful market experience and awareness of applicable regulations in the industry where the system
will be installed
• Financial stability
• Documentation of system or software development
• Adherence to software quality assurance standards
and procedures
• Change and revision control
• Assurances of pre- and post-installation support
System qualification before installation (FAT) should
identify the methods that will ensure that the purchased
system meets, and is installed according to, specifications. In addition, it should detail the supporting documentation (e.g., installation, operator, and maintenance
manuals) to be supplied by the vendor and the timeframe
for providing this documentation.
System qualification after installation (SAT and/or installation and operational qualification, IQ/OQ) generally
is the responsibility of the firm using the system. It
should be noted, however, that there may be a need for
vendor participation. Any requirements in this area
should be outlined in the requirements document.
System support refers to requirements for ongoing
vendor assistance with hardware and software employed
for various reasons, including:
• Correction of problems
• Implementation and testing of changes
• Warranty periods
• Availability of spares
In system evaluation and acceptance, the formal
mechanism for judging the performance of the new system and the minimum requirements for acceptance
should be identified.
Requirements versus Specifications
Each of the above lifecycle models (Figures 1-3)
shows two separate and distinct steps in defining the attributes of an automated system. The first step, defines
the system's requirements and the second its specifications. Although the level of detail can vary, the requirements must establish the criteria for system design and
testing, while also allowing for flexibility in the selection
of specific hardware, software, and vendors. On the
other hand, specifications provide highly detailed definitions of specific hardware components and their functions, software considerations, and the system's
interaction with its operating environment, i.e., specifications define in detail “how” the system will meet the requirements described in the requirements document.
Figure 4 shows the lifecycle relationships and separation between requirements and specifications using
PhRMA's SDLC model. The process of system definition
starts with a high-level description (User Requirements)
of what the new system must do to be acceptable for its
intended use. Depending on the complexity of the new
system a narrative description of its intended use (Functional Description) may be extracted from the User Requirements and used to solicit information from
prospective vendors on systems, technologies, and/or system components (hardware and software) that could be
utilized in the development and construction of the new
system. Subsequently, this information can be formulated
into the Functional Requirements (i.e., prioritized required and desired functions) and Design Requirements
(i.e., the new system’s architecture, its operating environment, design and/or software development standards to be
followed, etc.) sections of the System Requirements document. The System Requirements document in conjunction with the selected vendors is then used to generate a
separate System Specifications document.
Despite the above discussion, experience has shown
that the definitions of requirements and specifications are
often incorrectly combined into a single document. Done
sometimes by design and other times through the evolution
of the requirements document, this practice often results in
oversights of user needs and the mixing of requirements
with specifications. If all or a major part of the automated
system is supplied by outside vendors, more the rule than
N ove m b e r 2 0 0 7 • Vo l u m e 1 4 , N u m b e r 1
65
IVTJVT1107.qxd
10/8/07
3:27 PM
Page 66
Robert W. Stotz, Ph.D.
the exception with today's more complex systems, a separate requirements document is required to convey user requirements. Providing a detailed specifications document
to potential vendors may lead them to rule out some viable
solutions or attempt to satisfy the specification with an expensive, customized system.
REFERENCES
1. Chapman, K.G., J.R. Harris, A.R. Bluhm, and J.J. Errico,
“Source Code Availability and Vendor-User Relationships,”
Pharm. Technol., 11(12), 24-35 (1987).
2. PMA's Computer Systems Validation Committee, K.G.
Chapman and J.R. Harris, principal authors, "Computer
CONCLUSION
System Validation - Staying Current: Introduction, Pharm.
Technol., 13(5), 60-66 (1989).
3. Technical Report No. 18, “Validation of Computer-Related
Defining an automated system in terms of its requirements, i.e., what a system is intended to do is the first,
and most important, step in building a quality system. A
clear definition of requirements, and specifications based
on these requirements, results in systems that are more
straightforward to construct, easier to operate, better documented, and more reliable. These systems are subsequently simpler and less costly to maintain, and vendors
are better able to determine and meet user needs.
The development of a system's requirements (intended use), as well as its specifications, is an iterative
process that requires effective communication among diverse disciplines. Too often the system user either is neglected or fails to participate adequately in these phases
of the project. Invariably, the result is an inferior system
which is difficult to learn, confusing to use, and expensive to maintain.
Although defining system requirements and system
specifications are closely related, they should be defined
at two distinct points in the lifecycle. This two step
process may seem lengthy, tedious, and simply not worth
the extra effort; however, taking these additional steps
consistently proves to be time well spent, making validation a value added process rather than an unending series
of costly events.
The importance of clearly defining the function and
structure of an automated system in terms of its requirements cannot be overemphasized. The time spent in the
early planning stages of a project will save hours in the
subsequent design, implementation, and maintenance of
the system when the cost of correcting or adding a feature
grows exponentially. ❏
66
Journal of Validation Technology
Systems,” PDA Journal of Pharmaceutical Science and
Technology, Supplement 49(S1) (1995).
4. Stotz, R.W. and K.G. Chapman, "Validation of Automated
Systems - System Definition," Journal of Parenteral Science and Technology, 46(5), 156-160, September/October
1992.
5. PMA's Computer Systems Validation Committee
(CSVC),”Validation Concepts for Computers Used in the
Manufacturing of Drug Products,” Pharm. Technol., 10(5),
24-34 (1986).
6. International Society of Pharmaceutical Engineering,
“GAMP Guide for Validation of Automated Systems,” GAMP
4, December 2001.
7. Proposed Validation Standard VS-2: Computer-Related
System Validation, Journal of Validation Technology, 6(2),
502-521, (2000).
8. Stotz, R.W., “System Definition: The Oft Neglected Life
Cycle Module,” Part 1, Journal of Validation Technology,
1(3), 28-32, (1995).
9. Tetzlaff, R.F., “GMP Documentation Requirements for Automated Systems: Part II,” Pharm. Technol., 16(4), 60-72
(1992).
10. Stotz, R.W., “System Definition: The Oft Neglected Life
Cycle Module,” Part 2, Journal of Validation Technology,
1(4), 24-29, (1995).
ABOUT THE AUTHOR
Robert W. Stotz, Ph.D., has more than 28 years experience in the pharmaceutical and healthcare industry, and
is President of Validation Compliance Inc. (VCI) located
in Exton, Pennsylvania. Dr. Stotz accumulated more than
11 years experience at The Upjohn Company (now
IVTJVT1107.qxd
10/8/07
3:27 PM
Page 67
Robert W. Stotz, Ph.D.
Pfizer) in Kalamazoo, Michigan USA, culminating as
Validation Manager for Upjohn's worldwide validation
efforts, and nearly seventeen years in the validation services industry.
Dr. Stotz works with many multi-national pharmaceutical and healthcare manufacturers in all aspects of operations (particularly computer systems) and validation,
from concept through to system/facility qualification and
start-up. He has been actively involved with validation
issues for more than twenty-seven years and was a member of the Pharmaceutical Research and Manufacturers
of America's (PhRMA's, formerly PMA's) Computer
Systems Validation Committee for several years. He was
also a member of the PDA's Computer Validation Committee that published PDA Technical Report No. 18 on
“Validation of Computer-Related Systems,” and has presented and published several papers on the subject of validation. Dr. Stotz holds a doctoral degree from the
University of Florida and B.S. and M.S. degrees from the
University of Toledo. He can be reached at (610) 5942182.
Article Acronym Listing
CFR
Code of Federal Regulations
CGMP
Current Good Manufacturing Practice
CSVC
Computer Systems Validation
Committee
ERP
Enterprise Resource Planning
FAT
Factory Acceptance Testing
FDA
Food and Drug Administration (U.S.)
GAMP
Good Automated Manufacturing
Practice
HMI
Human/Machine Interface
IQ
Installation Qualification
OQ
Operational Qualification
OS
Operating System
OTS
Off-The-Shelf
PDA
Parenteral Drug Association
PhRMA
Pharmaceutical Research and
Manufacturer's Association
PMA
Pharmaceutical Manufacturer's
Association
RAM
Random Access Memory
SAT
Site Acceptance Testing
SDLC
System Development Life Cycle
SRS
Software Requirements Specification
N ove m b e r 2 0 0 7 • Vo l u m e 1 4 , N u m b e r 1
67