Requirements traceability

In order to provide a compliant-ready product, the manufacturer must make sure that the features required for compliance are built into the product. For verification purposes, a requirements traceability matrix should be created to match the appropriate tests for each of these requirements. An excerpt of an actual matrix is show in the following table (Table 2). 

Traceability and accountability of information to be maintained throughout validation life-cycle documents (particularly important in relating qualification tests to defined requirements). The mechanism (e.g., matrix) for establishing and maintaining requirements traceability should document where a user-specified requirement is met by more than one system function or covered by multiple tests... 

It is recommended that wherever possible the structure of the URS be used as the basis for the presentation format of the FDS and hardware and software design specifications this helps ensure design decisions are auditable back to the source requirement. Traceability should also be carried forward to the qualification test procedures, where it can link each test and qualification acceptance criterion directly to a specific requirement. 

For both embedded and stand-alone systems the supplier must adopt a life-cycle approach to system design and development to provide a level of documentation that can be used to support the qualification phases and requirements traceability from specification through to testing. This will also to support effective validation at minimum cost. 

Traceability to a common unit, or to a common measurement scale, makes the results of measurements comparable, regardless of their magnitude. The very -and only - reason for the existence of the requirement traceability is to enable us to compare our measurement results (i.e. achieving comparability) measurements of the same measurand, carried out at different places and/or different times, yield concordant results (meaning that they fall within each other s stated uncertainty). It is emphasized again that traceability need not to be to (values of) SI units but can be to values of other (including arbitrary) units with which measurement scales can be built. As Fig. 2 shows, a measurement scale can be constructed from a calibration curve based on a number of values carried by commonly agreed reference materials (in this case 5) [2],... 

Certainly any organization that requires traceability to national standards ought to focus on whether the measurements made by the organization subject to the trace-ability requirement are sufficiently accurate for their intended purpose and not simply on whether NBS calibration certificate(s) is on file. Without a valid uncertainty statement and evidence that the measurement process remains in a state of statistical control, no one can deter-... 

Assessment of the present situation regarding quality of spectrophotometric measurements [5] suggested the need for basic principles to be followed to assure the required traceability. Lately, some efforts have been focused on elaborating traceability schemes for clinical chemistry measurements. The purpose of any traceability scheme is to provide comparability, compatibility and consistency between the huge numbers of chemical measurements needed everyday, universally in clinical laboratories. On the other hand, the quality accredita-... 

The standard for on a particular kind of stainless steel is one containing 18% chromium and 8% nickel. Thus, not only the units of the International System of Units (SI units), such as mass, temperature and density, but also compositional standards can be defined by attributes or represented by reference materials. Any of these measurement standards can be referenced in technology or commerce often as a contractual or mandatory requirement. Traceability and traceable are commonly used in relation to (the value of) a material standard. 

In practice, of course, it is sufficient to ensure that values xx to xn are under sufficient control to provide the required uncertainty in y. For critical quantities, this requires traceable calibration against other reference values. For less critical quantities, less stringent control may be adequate. 

Measurement results and standards are internationally accepted via their demonstrated comparability and known quality. The test results of a food testing laboratory that is accredited to the ISO/IEC 17025 Standard should be recognized in other countries where laboratory performance is also assessed in accordance with this Standard. This is an aspect of the ILAC MRA [31]. The ISO/IEC 17025 Standard requires traceability to internationally accepted stated references together with their stated measurement uncertainties [22]. 

Uncertainties are a prerequisite for the comparability of analytical measurement results. The ISO/IEC 17025 standard requires traceability to internationally accepted stated references together with their stated measurement uncertainties. 

Complete A Requirements Traceability Matrix (RTM) should be developed to confirm that all relevant aspects of the URS have been brought forward into the Functional Specification and Design Specifications. This includes both positive and negative requirements (the latter often overlooked), i.e., what the software is snpposed to do and what it is NOT supposed to do ... 

The following should be established to support the project and its hand-over to ongoing use. With the exception of requirements traceability these topics are discussed in more detail in Chapter 4. 

In the words of ex-FDA investigator Martin Browning traceability is the absolute key [to documentation] through design, development, deployment, and all the way through to decommissioning. Specifically, requirements traceability will improve ... 

A Requirements Traceability Matrix (RTM) or equivalent mechanism for establishing and maintaining requirement traceability should be put in place for projects for use during operation and maintenance. This mechanism should provide a method of tracing a requirement from the URS through the Design and Development and User Qualification phases. It provides assurance that all system requirements have been included in the design and tested to verify correct operation. 

During the operational life of the computer system, requirements traceability will enable impact assessments to be conducted in support of regression testing of changes. It is quite normal for a particular aspect of a computer system to require more than one test. When making a change, it is important to appreciate if this one-to-many situation exists and ensure that all appropriate tests are executed. 

Requirements traceability should also ease inspections by facilitating the rapid location of any specification-to-test information requested. For many organizations, this forward tracking of requirements can be quite cumbersome if they rely solely on reverse tracking offered by test documentation referencing requirements and specifications. 

Wherever possible, the Functional Specification should follow the same stmcture of the URS (see Appendix 8B), and can refer to the URS rather than duplicate information. A Requirements Traceability Matrix can be developed as described later in this chapter. Compliance, orrrissions, and nonconformances with respect to the URS should all be readily identifiable. 

Architectural Designs should clearly identify the use of COTS software and hardware. Many modem computer systems make extensive use of COTS products. Architectural Designs should be included in the Requirements Traceability Matrix (RTM) as they will provide the vital linkage... 

The Requirements Traceability Matrix (RTM) initially developed for the Design Review should be extended to track which tests cover which aspects of the specification. 

The Requirements Traceability Matrix (RTM) should be updated with details of test speeifiea-tions and test reports. It should be possible to track a user requirement through Functional Specification, Design, System Build, Development Testing, and User Qualification. 

Check requirements traceability to verify IQ/OQ/PQ testing covers the system as used. 

A Design Review should be conducted before testing begins. This will normally involve developing a Requirements Traceability Matrix (RTM). If no detailed design information is available then cross-references should be made between the newly prepared System Specification, available operator manuals, and user procedures. Source Code Reviews will be expected for custom (bespoke) software under the control of the pharmaceutical or healthcare company, and redundant code identified should be removed. 

Certificates of analysis confirming the final product resulting from these weighings can also be retained as further inferred evidence of the quality of the weighing IPC system. Completing the PQ allows the completion of the Requirements Traceability Matrix. Full traceability from specification through testing should be demonstrated at this point. 

A key element of the overall process computer system testing effort is the concept of traceability. Testing should be traceable back to design features and system requirements. Include traceability matrices to show complete coverage of requirements and design. Eormal review activities should include review of these matrices. The GAMP 4 Guide provides direction on requirements traceability. 

A requirements trace matrix (RTM) is a tool to map requirements. However, these can become large and difficult to maintain. An alternative approach is to provide implicit traceability by having a common structure and numbering system for all system design and test documentation. The one area where this is often difficult to achieve is with the User Requirements Specification (URS). The URS often covers not only the DCS requirements but those of the wider project, and is also produced before the system vendor has been selected. In this case a requirements traceability matrix should be generated to confirm requirements relevant to the DCS are addressed within the functional specifications. 

It is not typical to receive a separate functional and design specification these are often included as part of the building s environmental control package. If this proves to be the case, then it is not necessary to rewrite these specifications. The recommended approach is to create a matrix that references those parts of the environmental control package that are relevant to the computer system validation requirements for the critical functions. Also, ensure that this matrix is mapped back to the URS in order to ensure that the URS is met. This matrix will form the basis of the Requirement Traceability Matrix (RTM), which is intended to assure that all requirements have been addressed, that the functionality is appropriate, consistent, and meets predefined standards, and that the system is appropriately tested. The functional/design specification or the relevant sections of the environmental control package should typically address ... 

---