T-012-025 Software Verification Phase 4 Checklist
Actors
Name | Title | Meaning | Approved Date & Time |
---|---|---|---|
Change history
Revision | Summary | Date |
---|---|---|
Process overview
The purpose of the Software Design Checklist review is to ensure the outputs of Phase 4 satisfy the criteria listed in the next section.
Project information
- Project title:
- Project manager (name and function):
Planning
Phase | Object | Done |
---|---|---|
Phase 1 Product Design Review | Establish input data | |
Phase 2 Software Design Review | SRs, Architectural Design and UI Prototypes | |
Phase 3 Software Candidate Release | Coding, integration and test plan | |
Phase 4 Software Verification Review | Software version verified and residual anomalies | |
Phase 5 Product Validation Review | Validation activities, Technical Documentation and DHF |
Previous reserves
Instructions
If there were any reserves or outstanding issues identified during Phase 2, list them here. Include a brief description of each reserve, the actions required to address them, and assign an owner and targeted completion date. See T-012-024 Software Candidate Release Phase 3 Checklist for an example.
N° | Documents / Purpose / Actions to implement | Owner | Targeted Date | Satisfying |
---|---|---|---|---|
Review according to 62304
Verification
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
5.5.2 EN 62304. The strategies, methods and procedures for verifying each SOFTWARE UNIT are documented [Class B, C] | |||
5.5.3 EN 62304. The acceptance criteria for SOFTWARE UNITS before integration into SOFTWARE ELEMENTS are documented [Classes B, C] | |||
5.5.4 EN 62304. Additional acceptance criteria for SOFTWARE UNITS are documented [Class C] | |||
5.5.5 EN 62304. SOFTWARE UNIT VERIFICATION results are documented [Class B, C] |
Software integration and integration testing
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
5.6.1 EN 62304. The SOFTWARE UNITS are integrated in accordance with the integration plan. [Class B, C] | |||
5.6.2 EN 62304. Integration verification is documented [Class B, C] | |||
5.6.3 - 5.6.4 EN 62304. Testing of integrated SOFTWARE ELEMENTS is documented [Class B, C] | |||
5.6.5 EN 62304. The integration testing procedures were evaluated to ensure their validity. [Class B, C] | |||
5.6.6 - 5.6.7 EN 62304. Appropriate REGRESSION TESTS have been performed and documented to demonstrate that defects have not been introduced into previously integrated software [Class B, C] | |||
5.6.8 EN 62304. ANOMALIES detected during software integration and integration testing are integrated into the software problem resolution PROCESS [Class B, C] |
Software system testing
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
5.7.1, 5.7.4 et 5.7.5 EN 62304. Carrying out and documenting a set of tests expressed in input stimuli, expected results, pass/fail criteria and SOFTWARE SYSTEM test execution procedures [Class B, C] | |||
5.7.2 EN 62304. ANOMALIES detected during SOFTWARE SYSTEM testing are incorporated into the software problem resolution PROCESS [Class B, C] | |||
5.7.3 EN 62304. When modifications are made during testing of the SOFTWARE SYSTEM [Class B, C] |
Distribution of the software
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
5.8.1 EN 62304. The software VERIFICATION has been completed and the results have been evaluated. [Class B, C] | |||
5.8.2 EN 62304. All known residual ANOMALIES are documented [Class B, C] | |||
5.8.3 EN 62304. All known residual ANOMALIES have been evaluated to ensure that they do not contribute to unacceptable RISK. [Class B, C] | |||
5.8.4 EN 62304. The VERSION of the SOFTWARE PRODUCT that is released is documented [Class A, B, C] | |||
5.8.5 - 5.8.8 EN 62304. The procedure and environment used to create the released software and delivery to the point of use without corruption or unauthorized change is documented. [Class B, C] | |||
5.8.6 EN 62304. All ACTIVITIES and TASKS are completely completed and associated documentation is complete. [Classes B, C] |
Design history file
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
DHF updated. Available index and updated computer directories |
Review according to IEC 81001
Verification
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
5.5.2 EN 81001. The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to ensure that implementation reviews are performed for identifying, characterizing and feeding into the problem resolution PROCESS all SECURITY-related issues associated with the implementation of the secure design |
Software integration testing
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
5.6 EN 81001. The MANUFACTURER can perform some of the software system testing as a part of software integration testing |
Software system testing
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
5.7.1 EN 81001 SECURITY requirements testing. The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for verifying that the HEALTH SOFTWARE SECURITY functions meet the SECURITY requirements and that the HEALTH SOFTWARE handles error scenarios and invalid input. | |||
5.7.2 EN 81001 THREAT mitigation testing. The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for testing the effectiveness of the mitigation for the THREATS identified and assessed in the THREAT MODEL. | |||
5.7.3 EN 81001 VULNERABILITY testing. The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for performing tests that focus on identifying and characterizing potential SECURITY VULNERABILITIES in the HEALTH SOFTWARE. | |||
5.7.4 EN 81001 Penetration testing. The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to identify and characterize WEAKNESSES via tests that focus on discovering and exploiting SECURITY VULNERABILITIES in the HEALTH SOFTWARE. | |||
5.7.4 EN 81001 Managing conflicts of interest between testers and developers. The MANUFACTURER shall document means of ensuring objectivity of the test effort for the security requirements, threat mitigation, vulnerability and penetration testing. |
Residual anomalies
List here all residual anomalies detected during verification and their risk analysis
Key | Summary | Risk assessment & control measure | Acceptability |
---|---|---|---|
Reserves
N° | Documents / Purpose / Actions to implement | Owner | Targeted Date |
---|---|---|---|
Conclusion
Instructions
- Begin with a brief summary of the review outcome, stating that the cited data is available, complete, and relevant.
- Indicate clearly whether the milestone is confirmed or if any reservations prevent moving to the next phase.
- If applicable, mention how the identified reservations will be addressed (e.g., "in a new release").
- Explicitly confirm whether a risk analysis has been conducted on residual anomalies and whether they are acceptable.
- Answer clearly: "Regarding the mentioned reserves, has the review been accepted?" — use “Yes” or “No”.
- Use a formal, neutral, and conclusive tone throughout.