Requirements Traceability and Validation Evidence

Requirements traceability demonstrates how a computerized system’s intended use is translated into requirements, controls, specifications, configuration, verification, operational procedures, and release evidence.

A traditional requirements traceability matrix may connect each user requirement to one or more tests. That connection is necessary, but it is not sufficient. Complete traceability should also show:

• why the requirement exists;
• which risks and regulated records it addresses;
• how the requirement was implemented;
• what supplier or site evidence supports it;
• whether deviations or defects affected the result;
• what procedures and training support continued operation; and
• whether the complete evidence set supports release.

Traceability should make the validation conclusion understandable without forcing the reviewer to reconstruct relationships across disconnected documents.

Purpose of Requirements Traceability

Traceability provides documented evidence that:

• the approved intended use has been addressed;
• requirements have been implemented;
• identified risk controls are present;
• the configured system matches its specifications;
• regulated functions and records have been verified;
• failed or incomplete evidence has been resolved;
• procedures and training support operational use;
• migration and interfaces are acceptable;
• and unresolved risks were formally evaluated before release.

Traceability also helps identify:

• requirements without verification;
• tests that do not address an approved requirement or risk;
• undocumented configuration;
• inconsistent specifications;
• missing supplier evidence;
• unresolved deviations;
• unapproved requirement changes;
• and obsolete documents retained after system changes.

Traceability Begins With Intended Use

The first traceability link should connect the system’s intended use to the requirements needed to support it. The intended use established in Computerized System Validation Planning and Strategy should identify:

• the regulated business process;
• the system boundary;
• the principal users;
• the functions relied upon;
• the regulated records created or maintained;
• important calculations and decisions;
• interfaces and dependent systems;
• and significant operating limitations.

A requirement may be technically implemented and successfully tested but still fail to support the intended use. Traceability should therefore confirm that the collection of requirements covers the complete regulated process rather than merely showing that individual requirements have tests.

Traceability From Requirements

Each requirement should have a unique identifier that remains stable throughout the validation lifecycle. The User Requirements Specification for Computerized Systems should define requirements for applicable areas such as:

• business processes;
• workflows;
• data and metadata;
• calculations;
• security;
• audit trails;
• electronic signatures;
• reports;
• interfaces;
• performance;
• availability;
• backup and recovery;
• retention;
• migration;
• and regulatory controls.

Traceability should connect each requirement to its applicable:

• risk assessment;
• functional or design specification;
• configuration record;
• supplier evidence;
• verification activity;
• procedure;
• training requirement;
• deviation or defect;
• and release disposition.

Not every requirement must connect to every evidence type. The applicable links depend on the requirement and the way it is implemented.

For example, a requirement for a configurable approval workflow may connect to:

• a workflow risk assessment;
• a functional specification;
• an approved configuration record;
• role and permission settings;
• a scripted functional test;
• an operating procedure;
• administrator training;
• and the final release record.

Risk-Control Traceability

Traceability should show how credible failure scenarios and required controls are addressed. The Computerized System Risk Assessment and Test Strategy may identify risks such as:

• unauthorized record changes;
• incorrect calculations;
• incomplete data transfer;
• bypassed approvals;
• missing audit-trail entries;
• inaccurate reports;
• lost metadata;
• unavailable records;
• or failure to restore required data.

Each significant risk should connect to one or more controls. Those controls should then connect to the requirement, specification, configuration, procedure, or test that establishes their implementation and effectiveness.

This connection prevents risk assessment from becoming a separate document with no demonstrated effect on system design or testing.

A risk may be controlled through several layers. For example:

Functional and Configuration Traceability

Requirements should connect to the documents that explain how the system satisfies them.

The Functional, Design, and Configuration Specifications for Computerized Systems may include:

• functional behavior;
• business rules;
• workflow states;
• calculations;
• roles and permissions;
• audit-trail settings;
• code tables;
• master data;
• reports;
• interfaces;
• exception handling;
• custom code;
• and infrastructure dependencies.

Traceability should distinguish between specified behavior and the actual installed configuration.

A specification may state that only Quality personnel can approve a deviation. The as-built evidence should identify the configured role, permission, workflow state, and applicable user groups. Verification should then demonstrate that:

• an authorized Quality user can approve the record;
• an unauthorized user cannot approve it;
• the approval is recorded correctly;
• and the audit trail captures the required information.

Configuration and As-Built Evidence

Configuration records establish what was actually implemented. Applicable records may include:

• configuration workbooks;
• workflow definitions;
• role and permission matrices;
• enabled modules;
• audit-trail settings;
• electronic-signature settings;
• code tables;
• master-data records;
• report definitions;
• interface mappings;
• infrastructure configurations;
• installed versions;
• custom-code inventories;
• and approved configuration baselines.

Traceability should identify the approved as-built record rather than relying only on a proposed design.

When configuration changes during testing, the traceability record should reference the final approved configuration and the testing performed against that configuration.

Supplier Evidence

Supplier documentation may provide useful evidence for standard functions, development controls, testing, architecture, security, or product release.

Applicable supplier evidence may include:

• product specifications;
• design documentation;
• development records;
• supplier test summaries;
• automated-test results;
• security assessments;
• release notes;
• known-defect lists;
• certificates;
• and installation documentation.

Before supplier evidence is traced to a requirement, the organization should confirm:

• the supplier and product were appropriately assessed;
• the evidence applies to the installed product and version;
• the tested function is used as intended;
• the supplier’s acceptance criteria are suitable;
• significant defects are understood;
• and the evidence is available for review when required.

The principles for accepting and supplementing supplier documentation are addressed in Computerized System Supplier Assessment and Evidence Leverage.

Supplier evidence does not replace site-specific verification of:

• configured workflows;
• calculations dependent on site data;
• security roles;
• interfaces;
• reports;
• migration;
• infrastructure;
• operating procedures;
• and representative business processes.

Verification Traceability

Verification evidence may include:

• document reviews;
• configuration reviews;
• code reviews;
• supplier testing;
• installation verification;
• scripted functional tests;
• unscripted or exploratory tests;
• interface tests;
• security tests;
• migration verification;
• backup and restoration tests;
• and end-to-end business-process testing.

The traceability record should identify the specific test or review that addresses the requirement. Referencing only a protocol title may be insufficient when the protocol contains many unrelated tests.

Where practical, the link should identify:

• protocol or record number;
• test-case number;
• test step or section;
• execution status;
• associated deviation;
• and final disposition.

A requirement should not be marked as covered merely because its identifier appears somewhere in a protocol. The test must contain an appropriate challenge and acceptance criterion.

Forward Traceability

Forward traceability follows the validation logic from the intended use toward implementation and evidence.

A typical forward path is:

Intended use → requirement → risk control → specification → configuration → verification → release

Forward tracing helps confirm that:

• every approved requirement was implemented;
• risk controls were translated into specifications or procedures;
• specified functions were configured;
• configured functions were verified;
• and required evidence was considered during release.

Forward traceability is particularly useful for identifying requirements that were approved but never implemented or tested.

Backward Traceability

Backward traceability begins with an implemented component or validation record and traces it to its justification.

A typical backward path is:

Test or configuration item → specification → requirement → risk or intended use

Backward tracing helps identify:

• tests with no defined objective;
• configuration without an approved requirement;
• custom functions added without authorization;
• controls that do not address an identified risk;
• and documents that no longer apply to the released system.

Backward traceability is also useful during change control. It helps determine which requirements, risks, tests, procedures, records, and users may be affected by a proposed change.

Partial Coverage

One test may address only part of a requirement. For example, a requirement may state that the system shall:

1. restrict approval to authorized Quality users;
2. record the signer’s identity;
3. record the date and time;
4. display the meaning of the signature; and
5. link the signature permanently to the record.

A test demonstrating only that a Quality user can approve the record does not fully cover the requirement.

Partial coverage should be visible in the traceability record. The organization may:

• link the requirement to several tests;
• divide the requirement into separately identified subrequirements;
• identify covered and uncovered clauses;
• or document the remaining coverage in a supplemental review.

The traceability status should not be shown as complete until all applicable elements are addressed.

Combined Tests

A single test may address several related requirements when the test method and acceptance criteria clearly verify each one. For example, an end-to-end deviation workflow test may verify:

• initiation;
• required fields;
• role restrictions;
• status transitions;
• electronic signatures;
• audit trails;
• notifications;
• report inclusion;
• and record retention.

Combined tests can reduce unnecessary duplication, but traceability should identify where each requirement is verified within the test.

A failed portion of a combined test should not automatically invalidate every requirement. The deviation assessment should identify which requirements and results were affected.

Requirements Covered by Review

Not every requirement requires execution of a functional test. Some requirements may be verified through:

• configuration review;
• document inspection;
• supplier-document assessment;
• code review;
• certificate review;
• architectural review;
• or installation records.

For example, confirmation of an installed operating-system version may be demonstrated through installation or configuration evidence rather than a functional test.

The selected verification method should be justified by:

• the nature of the requirement;
• the associated risk;
• supplier evidence;
• configuration complexity;
• and the ability of the method to provide objective evidence.

Removed Requirements

A requirement may be removed when it no longer supports the approved intended use or was entered in error. Removal should be controlled and should document:

• the requirement being removed;
• the reason for removal;
• the effect on intended use;
• the risk assessment;
• affected specifications;
• configuration or code already developed;
• existing tests;
• procedures;
• training;
• and regulatory commitments.

The identifier should normally remain visible in the history. Reusing it for a different requirement can obscure the audit trail.

A removed requirement should have a final status such as removed, cancelled, or not applicable, together with its approved justification.

Deferred Requirements

A deferred requirement remains applicable but will not be implemented before the planned release. Deferral should identify:

• why implementation is delayed;
• the operational effect;
• associated risks;
• compensating controls;
• system restrictions;
• responsible owner;
• planned completion date;
• and approval authority.

The release assessment should clearly identify deferred requirements. They should not be hidden by marking them complete or not applicable.

Where a deferred requirement is necessary for safe, compliant, or reliable intended use, release may not be acceptable.

Failed Tests and Deviations

A failed test creates an incomplete or adverse traceability link. The traceability record should connect the affected requirement to:

• the failed test;
• the deviation or discrepancy;
• the investigation;
• the identified defect;
• corrective action;
• retesting;
• regression testing;
• and final disposition.

The original failure should remain visible. Replacing a failed test result with a successful rerun without retaining the failure record breaks the evidence chain.

The deviation assessment should determine whether the failure affects:

• other requirements;
• related configuration;
• previous test results;
• migrated data;
• procedures;
• training;
• supplier evidence;
• or release readiness.

Retesting and Regression Testing

Retesting confirms that the specific correction resolved the identified problem. Regression testing evaluates whether the correction affected other functions or controls.

Traceability should identify:

• the failed requirement or function;
• the implemented correction;
• the retest performed;
• the regression scope;
• the basis for that scope;
• the resulting evidence;
• and the final approval.

Retesting should use the approved final configuration. If the correction changes a requirement, specification, risk control, or procedure, those records should be updated before closure.

Defects and Known Limitations

Not every identified defect must be corrected before release. A defect may be accepted when its effect is understood and adequately controlled. The defect record should identify:

• affected requirements and functions;
• affected data or records;
• the conditions under which the defect occurs;
• product-quality, patient-safety, data-integrity, and regulatory impact;
• available workarounds;
• procedural or technical controls;
• monitoring requirements;
• and authorized risk acceptance.

The traceability record should not show an affected requirement as unconditionally satisfied when a known limitation remains. The status should direct the reviewer to the approved defect and residual-risk decision.

Data-Migration Traceability

Migration evidence should connect:

• source data;
• approved migration requirements;
• field and object mappings;
• transformations;
• migration tools;
• migration runs;
• reconciliation;
• exceptions;
• verification;
• and acceptance.

Traceability should demonstrate that required records, metadata, relationships, attachments, statuses, and other critical attributes were addressed.

Where particular data were excluded, transformed, cleansed, or archived instead of migrated, the approved disposition should be traceable to the applicable migration rule and risk assessment.

Procedures and Training

Technical testing alone does not establish operational readiness. Requirements that depend on procedural or human controls should connect to the applicable:

• standard operating procedure;
• work instruction;
• administrator guide;
• business-continuity procedure;
• backup and recovery procedure;
• incident-response procedure;
• or manual workaround.

Traceability should also identify required training where correct system operation depends on qualified users, reviewers, administrators, or support personnel.

Training evidence does not need to be entered person by person in the requirements matrix. The traceability record may link to an approved training plan or release-readiness record confirming that the required population completed training.

Release Traceability

Before release, the traceability record should support a documented coverage review. The review should confirm that:

• intended use is adequately addressed;
• requirements are approved and current;
• risk controls have been implemented;
• specifications represent the released system;
• the as-built configuration is controlled;
• supplier evidence has been assessed;
• required testing is complete;
• deviations and defects are resolved or accepted;
• migration is approved;
• procedures are effective;
• training is complete;
• and residual risks are accepted.

For electronic records subject to Part 11, 21 CFR 11.10(a) requires validation to support accuracy, reliability, consistent intended performance, and the ability to identify invalid or altered records. Traceability helps demonstrate how the organization established that evidence.

For drug manufacturing systems, 21 CFR 211.68 addresses computerized and related systems, including controls over changes and checks of input and output. Traceability should connect applicable controls to the evidence demonstrating their implementation.

Traceability Gap Resolution

A gap exists when a required relationship or supporting record is missing, incomplete, failed, or no longer current. Examples include:

• a requirement without verification;
• a test without an approved requirement;
• a risk control without implementation evidence;
• a configuration setting that differs from its specification;
• a failed test without an approved disposition;
• supplier evidence for a different software version;
• incomplete migration coverage;
• a missing procedure;
• or a requirement changed without reassessing prior tests.

The gap should be assessed rather than closed administratively. Its disposition may require:

• correcting a document;
• adding or modifying a requirement;
• updating the risk assessment;
• correcting configuration;
• executing additional testing;
• performing regression testing;
• revising a procedure;
• completing training;
• deferring a function;
• or accepting documented residual risk.

Traceability Status

Clear status terms help prevent incomplete evidence from appearing acceptable.

A traceability record may use statuses such as:

Terms should be defined in the validation procedure and used consistently.

Format of the Traceability Record

The traceability record may be maintained in:

• a controlled spreadsheet;
• a validation-management application;
• an application-lifecycle management platform;
• a requirements-management system;
• or a validated quality-management system.

The format should support:

• unique identifiers;
• controlled status;
• searchable relationships;
• approval;
• revision history;
• reporting;
• and retention.

A practical traceability record may include:

The record should remain understandable without duplicating entire documents within the matrix.

Lifecycle Maintenance

Traceability should not be archived immediately after initial release and ignored. It should be reviewed and updated when changes affect:

• intended use;
• requirements;
• risk controls;
• software versions;
• configuration;
• custom code;
• reports;
• calculations;
• interfaces;
• security;
• infrastructure;
• data migration;
• procedures;
• or supplier responsibilities.

Change-impact assessment should use backward traceability to identify affected requirements and evidence, then use forward traceability to confirm that required updates and regression tests were completed.

Periodic review should confirm that the traceability baseline still represents the current system and that cumulative changes have not created undocumented gaps.

During retirement, traceability can help identify:

• regulated records requiring retention;
• dependent interfaces;
• migration obligations;
• retrieval requirements;
• procedures to withdraw;
• and evidence needed to support decommissioning.

Practical Outcome

Effective traceability allows a reviewer to determine:

• what the system is intended to do;
• which requirements support that use;
• which risks and controls are involved;
• how each requirement was implemented;
• what evidence verifies the implementation;
• how failures and changes were resolved;
• whether users and procedures are ready;
• and why the system was considered acceptable for release.

The traceability matrix remains useful, but it is only the index. The validation conclusion depends on the complete, connected, and approved body of evidence behind it.