Software Development Cycle Requirements Matrix

This table illustrates the relationship between the FDA Design Control elements, IEC62304 and Company’s Software Development phases and deliverables. The development phases and
deliverables may be different for each company.
FDA Design
IEC62304 Section Development Phase Description Typical Deliverables
Control Element
Plans describe or reference the design and development activities and define
Design and
Software Requirements and responsibility for implementation. The plans identify and describe the interfaces
Development  Project Plan (Software Development Plan).
Development Plan Planning with different groups or activities that provide, or result in, input to the design
Planning
and development process.
The physical and performance requirements of a product used as a basis for
Requirements Requirements and
Design Input product design and development; includes user requirements, regulatory  Software Requirements Specification.
Analysis Planning
requirements, and system requirements.
Software
 Software Design Specifications and
Architecture The results of a design effort at each design phase and at the end of the total
Descriptions (e.g. Architecture,
Software Detailed Design and design effort. The finished design output is the basis for the DMR.
Design Output Infrastructure, Database Design, API).
Design Development Majority of Design Output is generated during the Design and Implementation.
 User instructions
Software Unit Items in italics under IEC62304 column are not required for Class A software
 Source Code
Implementation
 Technical design reviews.
Software Unit A documented, comprehensive, systematic examination of a design to evaluate
 Code reviews
Design Review implementation All phases the adequacy of the design requirements, to evaluate the capability of the design
 Document reviews
and verification to meet these requirements, and to identify problem.
 Milestone reviews
Software Unit
Confirmation by examination and provision of objective evidence that specified  Verification Plan,
Verification
Design and requirements has been fulfilled.  Test Protocol,
Verification Software
Development Some activities are performed throughout the project with majority occurring  Verification Results and Reports
Integration and
during the Design and Development phase  Traceability analysis
integration Testing
Confirmation by examination and provision of objective evidence that the
 Validation Plans, Method(s) and Protocol(s);
Software System Design Validation and particular requirements for a specific intended use can be consistently fulfilled.
Validation  Validation Reports
Testing Transfer Most verification activities are performed throughout the project with the final
 Usability/ User Testing Report
system validation occurring during the Validation and Deployment Phase.
The procedures and processes necessary to ensure that the design is correctly
 Design Transfer Record (Final Build, Build
Design Validation and translated into production specifications.
Design Transfer Software Release Procedure, Archive, Deployment info).
Transfer Some activities are performed throughout the development cycle but are finalized
 List of unresolved anomalies
during the Validation and Deployment Phase.
Process for initiating, assessing the impact and approving the proposed change
Software
before implementation for software product that was previously released into
Design Changes Maintenance Post-release  Software Change Record.
production.
Process
Described in more detail in QS-7.3-02
A compilation of records, which describes the design history of a finished product.  Index included in the project plan or transfer
Design History File All Phases
Maintained throughout the life of the product. record
Systematic application of management policies, procedures, and practices to the  Risk Management Plan.
Software Risk tasks of identifying, analyzing, controlling, and monitoring risk. Described in detail  Risk Assessment;
Risk Management All Phases
Management in QS-7.3-03  Risk Report
Performed throughout the development cycle including post-market activities.  Post-market Risk Assessment
 SOFTWARE DOCUMENTATION
Level of Concern
Software Description
Device Hazard Analysis
Software Requirements Specification Summary of functional
(SRS)
Architecture Design Chart
Software Design Specification (SDS)
Traceability Analysis
Software Development Environment No documentation is
Description
Verification and Validation
Documentation
Revision Level History
Unresolved Anomalies (Bugs or
Defects)
MINOR CONCERN MODERATE CONCERN MAJOR CONCERN
A statement indicating the Level of Concern and a description of the rationale for that
level.
A summary overview of the features and software operating environment.
Tabular description of identified hardware and software hazards, including severity
assessment and mitigations.
The complete SRS document.
requirements from SRS.
No documentation is Detailed depiction of functional units and software
necessary in the modules. May include state diagrams as well as flow
submission. charts.
No documentation is Software design specification document.
necessary in the
submission.
Traceability among requirements, specifications, identified hazards and mitigations,
and Verification and Validation testing.
Summary of software life Summary of software life cycle
necessary in the cycle development plan, development plan. Annotated
submission. including a summary of list of control documents
the configuration generated during
management and development process. Include
maintenance activities. the configuration
management and
maintenance plan documents.
Software functional test Description of V&V Description of V&V activities
plan, pass / fail criteria, activities at the unit, at the unit, integration, and
and results. integration, and system system level. Unit, integration
level. System level test and system level test
protocol, including protocols, including pass/fail
pass/fail criteria, and tests criteria, test report, summary,
results. and tests results.
Revision history log, including release version number and date.
No documentation is List of remaining software anomalies, annotated with an
necessary in the explanation of the impact on safety or effectiveness,
submission. including operator usage and human factors.