R.D. McDowall
|
In the first part of this column series on traceability matrices (1), we reviewed a system development life cycle model and
then discussed the regulatory requirements and expectations as well as the business benefits of this document. We also looked
at the terminology used and some of the principles of tracing requirements to other documents and activities in the life cycle.
Two points need to be reiterated from Part I for the discussion in this part. Requirements can either be tested or verified
throughout the life cycle. Testable and verifiable were defined in Part I (1) as
Testable: The degree to which a requirement is stated in terms that permit establishment of test criteria and performance
of tests to determine whether those criteria have been met. This is typically undertaken in the operational qualification
(OQ) or performance qualification (PQ) phases of the life cycle.
Verifiable: The degree to which a requirement can be fulfilled by implementation (in the installation qualification phase),
software configuration, writing standard operating procedures (SOPs), user training, vendor audit, calibration, or documentation.
This is important. In contrast to the GAMP 5 guide (2) that only discusses verification in the testing phases of a life cycle
model, I prefer to split traceability into testing and verification because these are different, and in doing so, it makes
the process easier and simpler to understand. When I talk about testing, I am referring to tasks that will be undertaken by the user (during the PQ) and also the vendor (during the OQ). In contrast,
requirements that are verified are scattered throughout all the remaining stages of a life cycle and not just the testing ones.
Linking Requirements with Their Testing or Verification
Figure 1
|
To illustrate the principles of traceability between the requirements in the user requirements specifications (URS) and testing
and verification in later stages of a system life cycle, let's look at Figure 1. The URS and the requirements that it contains
are shown in the left-hand column. Across the top of the figure in a single row are the documents that could be written in
a validation project. The figure caption lists what each of the abbreviations used in the table means. Before we start our
traceability journey, the document names are what I would typically use; your organization might name them differently, but
that is not a problem. This is to illustrate the principles of traceability in more detail than in Part I. You will need to
interpret this approach using your terminology instead.
I will discuss the principles of traceability using most of the nine requirements listed in the URS in Figure 1. After the
principles have been discussed, you can apply them to the remaining ones.
Requirement R1 is for the PC hardware upon which the spectrometer software will run and that the IT department will purchase.
This is expanded in more detail to the make, model, memory, disk size, and configuration required to support the application
and store the acquired data. It is traced first to item the specification T1 in a document called a technical specification;
from here it is verified during the installation qualification (IQ) of the computer system. This answers the question: was
what we specified actually delivered and installed, and if not, has the difference been documented.
R2 describes a requirement that needs an SOP written for the users to follow, and when this document is available the requirement
will be verified. Collate all the user requirements that trace to procedures, check them against existing SOPs, and update
as appropriate. Where no SOP exists, one must be written.
R3 leads to a function in the application software that will be configured and the setting is documented in the configuration
specification in section 3.2 and tested during the PQ (for example, T). One can go further than just listing T under the PQ,
but the detail to which we go will be discussed in a later section of this column.
