FDA Expectations for Requirements

Some thoughts on Requirements … using the General Principles of Software Validation to help.

Many times we struggle with creating software requirements and documenting them. The FDA General Principles of Software Validation-Final Guidance helps set the FDA expectations in this area. Section 4.1 of the guidance states:

“A documented software requirements specification provides a baseline for both validation and verification. The software validation process cannot be completed without an established software requirements specification (Ref: 21 CFR 820.3(z) and (aa) and 820.30(f) and (g)).”

When researching the referenced regulations, we see:

1) 21CFR820.3(z)

“Validation means confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use can be consistently fulfilled.

1. Process validation means establishing by objective evidence that a process consistently produces a result or product meeting its predetermined specifications.
2. Design validation means establishing by objective evidence that device specifications conform with user needs and intended use(s).”

2) 21CRF820.30(f)

“Design verification. Each manufacturer shall establish and maintain procedures for verifying the device design. Design verification shall confirm that the design output meets the design input requirements. The results of the design verification, including identification of the design, method(s), the date, and the individual(s) performing the verification, shall be documented in the DHF.”

3) 21CFR820.30(g)

“Design validation. Each manufacturer shall establish and maintain procedures for validating the device design. Design validation shall be performed under defined operating conditions on initial production units, lots, or batches, or their equivalents. Design validation shall ensure that devices conform to defined user needs and intended uses and shall include testing of production units under actual or simulated use conditions. Design validation shall include software validation and risk analysis, where appropriate (Note: it’s always appropriate!). The results of the design validation, including identification of the design, method(s), the date, and the individual(s) performing the validation, shall be documented in the DHF.”

One can understand very quickly that FDA’s view of software requirements is that requirements will have a role in Design Verification activities and in Design Validation activities. One should be cognizant of that as they plan specific design verification and design validation tasks. In many cases, these will overlap offering opportunities for efficiency and diverse testing methodologies.

Whether one is creating software for a simple, low risk medical device or HealthIT, or complex, high risk safety-intense medical device software, the GPSV specifies documented software requirements. By documented, one should conform with their 21CFR820.40 compliant process. However, how the documentation is captured during development and managed can be very flexible.

Requirements must be measurable and testable … otherwise design verification tasks may be difficult and/or unable to be completed. Generally, software requirements answer the question of “what should the software do.” Software design specifications should describe the detailed software design for achieving the software requirements.

Final thought: Notice the word “baseline.” One should be sure to understand the baseline software requirements for any external release of software. Plan how the baselines will be managed and associated configuration management activities.

FDA Expectations for Requirements

Brian Pate

SoftwareCPR Training Courses:

Subscription Services

Corporate Office