FDA의 의료기기 SRS

오래된 문서긴 하다. 파일은 첨부하였음.

Guidance for Industry and FDA Staff

Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices

Document issued on: May 11, 2005

FDA 문서에서 SRS를 요구한다.

Software Requirements Specification (SRS)	Summary of functional requirements from SRS.	The complete SRS document.

 

그리고 다음 내용이 있어야 한다.

0. Software Requirements Specification

   The Software Requirements Specification (SRS) documents the requirements for the software. This typically includes functional, performance, interface, design, developmental, and other requirements for the software. In effect, this document describes what the Software Device is supposed to do. Examples of some typical requirements that would be included in a SRS are

11

Contains Nonbinding Recommendations

described below. For Software Devices that are identified as Minor Level of Concern, we recommend that you provide only the summary functional requirements section from the SRS, includingidentificationofoff-the-shelfsoftware. ForSoftwareDevicesthatareidentifiedas Major or Moderate Level of Concern, we recommend that you provide the complete SRS document.

Hardware Requirements

Hardware requirements generally include:

• microprocessors

• memory devices

• sensors

• energy sources

• safety features

• communications.

  Programming Language Requirements

  Programming language requirements include program size requirements or restrictions, and information on management of memory leaks.

  Interface Requirements

  Interface requirements generally include both communication between system components and communication with the user such as:

  • printers
  • monitors • keyboard • mouse.

  Software Performance and Functional Requirements

  Software performance and functional requirements include algorithms or control characteristics for therapy, diagnosis, monitoring, alarms, analysis, and interpretation with full text references or supporting clinical data, if necessary. Software performance and functional requirements may also include:

• device limitations due to software

• internal software tests and checks

• error and interrupt handling

• fault detection, tolerance, and recovery characteristics

12

Contains Nonbinding Recommendations

• safety requirements

• timing and memory requirements

• identification of off-the-shelf software, if appropriate.

  Architecture Design Chart

  This document is typically a flowchart or similar depiction of the relationships among the major functional units in the Software Device, including relationships to hardware and to data flows suchasnetworking. Itisusuallynotnecessarytoincludeeveryfunctioncallandmoduleinthis document; however, there should be sufficient information to allow for review of the organization of the software relative to the functionality and to the intended use of the Software Device. For Moderate and Major Level of Concern devices, detailed information such as state diagrams may be useful to clearly depict the relationships among the software functional units. If the Architecture Design Chart is included in another document such as the SRS then you should include in your submission a statement to that effect and a reference to the location of the Architecture Design Chart in the submission.

  Software Design Specification

  The Software Design Specification (SDS) describes the implementation of the requirements for the Software Device. In terms of the relationship between the SRS and the SDS, the SRS describes what the Software Device will do and the SDS describes how the requirements in the SRS are implemented. The information presented in the SDS should be sufficient to ensure that the work performed by the software engineers who created the Software Device was clear and unambiguous, with minimal ad hoc design decisions. The SDS may contain references to other documents, such as detailed software specifications. However, the document you submit should, in and of itself, provide adequate information to allow for review of the implementation plan for the software requirements in terms of intended use, functionality, safety, and effectiveness.

  Traceability Analysis

  A Traceability Analysis links together your product design requirements, design specifications, andtestingrequirements. Italsoprovidesameansoftyingtogetheridentifiedhazardswiththe implementationandtestingofthemitigations. Werecommendthatyousubmitforreview explicit traceability among these activities and associated documentation because they are essential to effective product development and to our understanding of product design, development and testing, and hazard mitigations. The Traceability Analysis commonly consists of a matrix with line items for requirements, specifications and tests, and pointers to hazard mitigations. It is possible to document traceability simply through a shared organizational

13

Contains Nonbinding Recommendations

structure with a common numbering scheme; however, we recommend that you include some mechanism, such as a matrix for guiding the reviewer through the information you submit.

Software Development Environment Description

For Moderate and Major Level of Concern Software Devices, the submission should include a summary of the software development life cycle plan. This summary should describe the sponsor’s software development life cycle and the processes that are in place to manage the various life cycle activities. For Major Level of Concern Software Devices, this document should also include an annotated list of the control/baseline documents generated during the software development process and a list or description of software coding standards.

As mentioned elsewhere, configuration or change management is a crucial aspect of software development. Changes to the Software Device after initial market release should be subject to positive control, with definitive specification and test plans including well-defined regression testing where appropriate. The description of the development environment should provide information on your configuration management and maintenance plan that addresses these aspects of the software development life cycle. For a Major Level of Concern device, we recommend that you provide sufficient detail to allow for a thorough understanding of the configuration management and maintenance plan. For a Moderate Level of Concern device, we recommend that you provide only a summary of the configuration management and maintenance plans.

Verification and Validation Documentation

The terms “verification” and “validation” described earlier in this document refer to two phases of Software Device testing. This section recommends the type of testing documentation you should include in a premarket submission for a Software Device, based on the Level of Concern.

Minor Level of Concern Devices

For Minor Level of Concern devices, we recommend that you submit documentation of system or device level testing, and, where appropriate, integration testing. The documentation submitted should include system or device level test pass/fail criteria and a summary of the test results.

Moderate Level of Concern Devices

For Moderate Level of Concern devices, we recommend that you submit a summary list of validation and verification activities and the results of these activities. We also recommend that you submit your pass/fail criteria. You should ensure that the Traceability Analysis effectively links these activities and results to your design requirements and specifications.

14

Contains Nonbinding Recommendations

Major Level of Concern Devices

For Major Level of Concern devices, we recommend that you submit the information recommended above for Moderate Level of Concern devices and a description of any tests that were not passed. We also recommend that you include any modifications made in response to failed tests and documentation of results demonstrating that the modifications were effective. Documentation provided in your submission should include examples of unit integration testing and a summary of the results.

Revision Level History

Your submission should include the history of software revisions generated during the course of productdevelopment. Thistypicallytakestheformofaline-itemtabulationofthemajor changes to the software during the development cycle, including date, version number, and a brief description of the changes in the version relative to the previous version. The last entry in the list should be the final version to be incorporated in the released device. This entry should also include any differences between the tested version of software and the released version, along with an assessment of the potential effect of the differences on the safety and effectiveness of the device.

Unresolved Anomalies (Bugs or Defects)

For Moderate and Major Level of Concern Software Devices, the submission should include a list of all unresolved software anomalies. For each anomaly, we recommend that you indicate the:

• problem

• impact on device performance

• any plans or timeframes for correcting the problem (where appropriate).

  We recommend that you annotate each item with an explanation of the impact of the anomaly ondevicesafetyoreffectiveness,includingoperatorusageandhumanfactorsissues. Typically, this list can be generated as an output of a change control board or similar mechanism for evaluation and disposition of unresolved software anomalies. We recommend that you communicate this list to the end user as appropriate to assist in the proper operation of the device. Inallinstanceswhereitispracticaltodoso,youshouldincludeanymitigationsor possible work-arounds for unresolved anomalies; this recommendation applies to Blood Establishment Computer Software in particular.

  The Special 510(k) Program

  For a premarket submission to qualify for review under the Special 510(k) Program, the device should be a modification of your 510(k) cleared device that you own, where the modification does

15

Contains Nonbinding Recommendations

notaltertheintendeduseorthefundamentalscientifictechnologyofthedevicevii. InaSpecial 510(k), you should follow the recommendations in this guidance on the documentation to submit, but submit only the documentation related to the modification that prompted the submission. For example, when submitting the documentation of requirements and specifications in a Special 510(k), the documentation should focus on the modifications and may not necessarily include all of the requirements and specifications of the entire device.

We recommend that you submit the regression testing performed to verify and validate the modifications. Werecommendthatyousubmityourtestplans,pass/failcriteria,andsummary results rather than test data. In all cases, the type of software-related documentation and the level of detail you provide should be appropriate to the Level of Concern associated with your device in thecontextofthemodifications. SinceaSpecial510(k)submissionreliesonyourdeclarationof conformance to design controls, we believe you cannot properly submit a Special 510(k) until you have completed testing or other activities relied on by your declaration (see section 514(c)(1)(B) of the Federal Food, Drug, and Cosmetic Act (Act) (21 U.S.C. 360d(c)(1)(B)).

fda.pdf