Shared view
Report abuse
Use this data
Sign up for free
Name
1
Recommended Submission Documentation
2
Software Requirements Specification (SRS)
3
Software Requirements Specification (SRS)
4
System and Software Architecture Design
5
System and Software Architecture Design
6
Software Design Specification (SDS)
7
Software Design Specification (SDS)
8
Traceability Analysis
9
Software Development Configuration Management, and Maintenance Practices
10
Software Development Configuration Management, and Maintenance Practices
11
Software Development Configuration Management, and Maintenance Practices
12
Software Testing as Part of Verification and Validation
13
Software Testing as Part of Verification and Validation
14
Software Testing as Part of Verification and Validation
15
Software Version History
16
Software Version History
17
Drag to adjust the number of frozen columns
2005 Software Categorization
2023 Documentation Level
Implications
2005 Guidance
2023 Guidance
Minor
Moderate
Major
Basic
Enhanced

The focus of the documentation levels is now centered around risk analysis. Improper and incomplete risk analysis may affect documentation levels. This is arguably the most important activity that is required per the guidance.


Moderate software could be considered either basic or enhanced depending on the results of the risk assessment. This could increase or decrease the amount of document submissions required to support your product.

Tabular description of identified hardware and software hazards including severity assessment and mitigations

Risk management plan, risk assessment demonstrating that risks have been appropriately mitigated, and risk management report.

Major
Moderate
Basic
Enhanced

Previously software determined to be Minor will now require full SRS documentation under the basic category.

Full SRS documentation

SRS documentation, describing the needs or expectations for a system or software, presented in an organized format, at the software system level or subsystem level, as appropriate, and with sufficient information to understand the traceability of the information with respect to the other

Minor
Basic
Enhanced

Previously software determined to be minor will now require full SRS documentation under the basic category.

Summary SRS documentation

SRS documentation, describing the needs or expectations for a system or software, presented in an organized format, at the software system level or subsystem level, as appropriate, and with sufficient information to understand the traceability of the information with respect to the other

Moderate
Major
Basic
Enhanced

The new guidance provides clarification for meeting the system and software architecture design requirements.

Detailed depiction of functional units and software modules. May include state diagrams as well as flow charts.

Detailed diagrams of the modules, layers, and interfaces that comprise the device, their relationships, the data inputs/outputs and flow of data, and how users or external products interact with the system and software.

Minor
Basic
Enhanced

Previously software determined to be minor will now require architecture design documentation under the basic category.

No documentation is necessary in the submission.

Detailed diagrams of the modules, layers, and interfaces that comprise the device, their relationships, the data inputs/outputs and flow of data, and how users or external products interact with the system and software.

Moderate
Major
Enhanced

The FDA does not recommend that basic levels submit an SDS. However, this does not imply that creating an SDS is not necessary. The FDA may still request this information if needed.

Full software design specification documentation.

SDS Documentation, including sufficient information that would allow the FDA to understand technical design details of how the software functions, how the software design completely and correctly implements all the requirements of the SRS, and how the software design traces to the SRS in terms of intended. Use, functionality, safety and effectiveness.

Minor
Basic

Although the SDS is not recommended for submission, it's still a good practice to have this information documented and ready for review should the FDA request additional information to evaluate the safety and effectiveness of the device.

No SDS documentation is necessary in the submission.

FDA is not recommending the SDS as part of the submission. However, the sponsor should document this information on the design via the DHF for the device. The FDA may request additional information if needed, to evaluate the safety and effectiveness of the device.

Major
Moderate
Minor
Enhanced
Basic

Good software development will still involve creating a traceability matrix and the expectation is that you still have one. Submission details provided in the SDS and SRS demonstrate traceability. However, you should still be able to trace the risks developed in the risk management plan to mitigations and additional user requirements presented in other documentation.

Traceability among requirements, specifications, identified hazards and mitigations, and V&V testing

No longer a stand-alone requirement for submission. 

Major
Enhanced

A declaration of conformity to the FDA version of IEC 62304 including specified subclauses is required. Additionally basic levels of documentation are required to include configuration management and maintenance plans.

Software Development Environment Description: Summary of the SDLC. Annotated list of control documents generated during the development process. Configuration management plan and maintenance documents.

Basic Documentation Level, PLUS complete configuration management and maintenance plan document(s);

OR

A Declaration of Conformity to the FDA-recognized version of IEC 62304, including subclause 5.1 (Software development planning), clause 6 (software maintenance process), and clause 8 (software configuration management process), among others as applicable.

Moderate
Basic

A declaration of conformity to the FDA-recognized version of IEC 62304 including specified subclauses is sufficient. If you don't want to use IEC 62304, you can submit a summary of your life cycle development plan and a summary of configuration management and maintenance activities.

Summary of software life cycle development plan, including a summary of the configuration management and maintenance activities.

A summary of the life cycle development plan and a summary of configuration management and maintenance activities; 

OR

A Declaration of Conformity to the FDA-recognized version of IEC 62304, including subclauses 5.1.1-5.1.3, 5.1.6-5.1.9, clause 6 (Software maintenance process), and clause 8 (Software configuration management process), among others as applicable.

Minor
Basic

A declaration of conformity to the FDA-recognized version of IEC 62304 including specified subclauses is sufficient. If you don't want to use IEC 62304, you can submit a summary of your life cycle development plan and a summary of configuration management and maintenance activities.

No documentation necessary

A summary of the life cycle development plan and a summary of configuration management and maintenance activities; 

OR

A Declaration of Conformity to the FDA-recognized version of IEC 62304, including subclauses 5.1.1-5.1.3, 5.1.6-5.1.9, clause 6 (Software maintenance process), and clause 8 (Software configuration management process), among others as applicable.

Major
Enhanced

Core testing requirements remain essentially the same. The technical wording is a little differenct but expectations are the similar. However, additional testing requirements called out include intentional change testing and regression testing with associated analysis, test protocols, results, and reports. Anamolies are expected to be addressed here as well. Requirements for complete unit and integration testing are the delta between basic and enhanced levels of documentation.

Description of V&V activities at the unit, integration, and system level. Unit, integration and system level test protocols, including pass/fail criteria, test report, summary, and test results.

Basic level Documentation , PLUS unit and integration level test protocols including expected results, observed results, pass/fail determination, and unit and integration level test reports.

Moderate
Basic

Core testing requirements remain essentially the same. The technical wording is a little differenct but expectations are the similar. However, additional testing requirements called out include intentional change testing and regression testing with associated analysis, test protocols, results, and reports. Anamolies are expected to be addressed here as well. Requirements for a summary of unit and integration testing are the delta between basic and enhanced levels of documentation.

Description of V&V activities at the unit, integration, and system level. System level test protocol, including pass/fail criteria, and tests results.

A summary description of the testing activities at the unit, integration and system levels;

AND

System level test protocol including expected results, observed results, pass/fail determination, and system level test report.

Provide a summary of the modifications compared to the previous cleared version with a summary of new tests.

Provide any intentional changes made in response to failed tests and documentation of test results demonstrating that the intentional changes were implemented correctly.

Regression analysis and testing (based on analysis) for unintended effects of a software change if needed.

Minor
Basic

System level test protocols including expected results are now required for software that would previously be considered minor and exempt from having to perform rigorous tests. Additionally, you must provide a summary description of testing activities at the unit, integration, and system levels. Additional testing requirements called out include intentional change testing and regression testing with associated analysis, test protocols, results, and reports. Anamolies are expected to be addressed here as well. Simple functional tests are no longer considered acceptable.

Software functional test plan, pass / fail criteria, and results.

A summary description of the testing activities at the unit, integration and system levels;

AND

System level test protocol including expected results, observed results, pass/fail determination, and system level test report.

Provide a summary of the modifications compared to the previous cleared version with a summary of new tests.

Provide any intentional changes made in response to failed tests and documentation of test results demonstrating that the intentional changes were implemented correctly.

Regression analysis and testing (based on analysis) for unintended effects of a software change if needed.

Major
Moderate
Enhanced
Basic

A list of software unresolved anomalies with an evaluation of safety and effctiveness is necessary now for all submissions. Description of software versions is new.

Revision history log, including release version number and date.

AND

List of remaining software anomalies 

annotated with an explanation of the impact on safety or effectiveness, including operator usage and human factors.

A history of tested software versions including the date, version number, and a brief description of all changes relative to the previously tested software version.

AND

List of remaining unresolved software anomalies with an evaluation of the impact of each unresolved software anomaly on the device’s safety and effectiveness.

Minor
Basic

Description of software versions is new.

Revision history log, including release version number and date. No documentation was necessary in the submission

A history of tested software versions including the date, version number, and a brief description of all changes relative to the previously tested software version.


List of remaining unresolved software anomalies with an evaluation of the impact of each unresolved software anomaly on the device’s safety and effectiveness.

17 records

Alert

Lorem ipsum
Okay