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.

About the author

Brian is a biomedical software engineer - whatever that is! Started writing machine code for the Intel 8080 in 1983. Still enjoys designing and developing code. But probably enjoys his garden more now and watching plants grow ... and grandkids grow!

SoftwareCPR Training Courses:

IEC 62304 and other emerging standards for Medical Device and HealthIT Software

Our flagship course for preparing regulatory, quality, engineering, operations, and others for the activities and documentation expected for IEC 62304 conformance and for FDA expectations. The goal is to educate on the intent and purpose so that the participants are able to make informed decisions in the future.  Focus is not simply what the standard says, but what is meant and discuss examples and approaches one might implement to comply.  Special deep discount pricing available to FDA attendees and other regulators.

3-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Brian Pate

Next public offering:  TBD

Email training@softwarecpr.com to request a special pre-registration discount.  Limited number of pre-registration coupons.

Registration Link:




Being Agile & Yet Compliant (Public or Private)

Our SoftwareCPR unique approach to incorporating agile and lean engineering to your medical device software process training course is now open for scheduling!

  • Agile principles that align well with medical
  • Backlog management
  • Agile risk management
  • Incremental and iterative software development lifecycle management
  •  Frequent release management
  • And more!

2-days onsite (4 days virtual) with group exercises, quizzes, examples, Q&A.

Instructors: Mike Russell, Ron Baerg

Next public offering: March 7 & 28, 2024

Virtual via Zoom

Registration Link:

Register Now



Medical Device Cybersecurity (Public or Private)

This course takes a deep dive into the US FDA expectations for cybersecurity activities in the product development process with central focus on the cybersecurity risk analysis process. Overall approach will be tied to relevant standards and FDA guidance documentation. The course will follow the ISO 14971:2019 framework for overall structure but utilize IEC 62304, IEC 81001-5-1, and AAMI TIR57 for specific details regarding cybersecurity planning, risk characterization, threat modeling, and control strategies.

2-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Dr Peter Rech, 2nd instructor (optional)

Next public offering:  TBD

Corporate Office

15148 Springview St.
Tampa, FL 33624
Partners located in the US (CA, FL, MA, MN, TX) and Canada.