Software Development Plan and Lifecycle File: [Software system name]
The software development plan and lifecycle records for medical device
software, structured on IEC 62304:2006 with Amendment 1:2015 (Medical
device software, Software life cycle processes, consolidated edition
1.1, June 2015). It covers the plan, software safety classification,
requirements, architecture and segregation, the SOUP list, unit,
integration and system verification, release, maintenance, software
risk management, configuration management and problem resolution.
A second edition of IEC 62304 is in development; as checked in October
2026 it was not yet published, and drafts propose changing the safety
classes. Replace every [bracketed] value and every row marked
Example. This is a documentation format, not regulatory or legal
advice: check the current official texts, the rules of your target
markets and a qualified regulatory professional.
Document control
| Field | Value |
|---|
| Document ID | [SDP-NNN] |
| Software system | [Name, version] |
| Device | [Device name and model] |
| Software safety class | [A / B / C, see section 2] |
| Linked records | [Risk management file ID, design and development file ID, usability engineering file ID] |
| Version | [0.1] |
| Status | [Draft / In review / Approved] |
| Owner | [@software-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
Approvals
| Role | Name | Decision | Date |
|---|
| Software lead | [@name] | [Approved] | YYYY-MM-DD |
| Risk management lead | [@name] | [Approved] | YYYY-MM-DD |
| Quality assurance | [@name] | [Approved] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | Plan and initial classification |
| 0.4 | YYYY-MM-DD | [@name] | Example: Architecture, segregation argument and SOUP list added |
| 1.0 | YYYY-MM-DD | [@name] | Example: Released with software version 1.0.0 |
Contents
- General requirements and context (cl. 4)
- Software safety classification (cl. 4.3)
- Software development plan (cl. 5.1)
- Software requirements (cl. 5.2)
- Architecture, segregation and SOUP (cl. 5.3)
- Detailed design, units and verification (cl. 5.4 to 5.6)
- Software system testing (cl. 5.7)
- Software release (cl. 5.8)
- Software maintenance (cl. 6)
- Software risk management (cl. 7)
- Configuration management (cl. 8)
- Problem resolution (cl. 9)
- Traceability matrix
- Glossary and references
1. General requirements and context (cl. 4)
| Item | Value |
|---|
| Quality management system | Example: Corvane QMS certified to ISO 13485:2016, certificate [ID] |
| Risk management process | Example: ISO 14971:2019, risk management file RMF-012 |
| Intended use of the device | [One line, from the risk management file] |
| Role of software in the device | Example: Controls the pumping mechanism, alarms, drug library limits and the user interface |
| Legacy software (cl. 4.4) | [None / name and justification route] |
| Cybersecurity process | [For example IEC 81001-5-1:2021, plan ID] |
2. Software safety classification (cl. 4.3)
| Class | Working meaning |
|---|
| A | No injury or damage to health is possible |
| B | Injury is possible but not serious |
| C | Death or serious injury is possible |
| Software system or item | Hazardous situations it can contribute to | External risk control considered | Class | Rationale |
|---|
| Pump control software (PCS) (Example) | Over-dose or under-dose (HZ-02) | Hardware dose monitor stops the motor, but a wrong programmed rate within limits is still delivered | C | Remaining harm after external control can still be serious |
| Safety monitor firmware (SMF) (Example) | Failure to stop an over-delivery (HZ-02) | None beyond the monitor itself | C | It is the risk control for a serious harm |
| User interface item (UI) (Example) | Wrong value displayed or entered (HZ-04) | Confirmation screen, drug library hard limits in PCS | C | Shares the processor with PCS, segregation not argued |
| Event log export item (LOG) (Example) | None identified | Not applicable | A | Segregated in a separate memory partition with no write access to dose data (section 5.3) |
Classification reviewed by: [@name], YYYY-MM-DD. Re-classify when the
risk management file changes the hazards in the table above.
3. Software development plan (cl. 5.1)
3.1 Lifecycle model and deliverables
| Item | Value |
|---|
| Lifecycle model | Example: Iterative, two-week increments, with formal design reviews at architecture freeze and release candidate |
| Deliverables | Requirements specification (SRS), architecture document (SAD), detailed design (class C units), unit and integration test records, system test report, release notes, SOUP list |
| Link to system design | Each SRS item traces to a design input in the design and development file |
| Integration plan | Example: Daily continuous integration build, hardware-in-the-loop integration test nightly |
3.2 Standards, methods and tools
| Category | Choice | Version | Tool qualification or validation |
|---|
| Programming language and coding standard | Example: C with an internal coding standard derived from a published safety subset | [Version] | Static analysis rule set reviewed |
| Compiler | Example: Certified C compiler for the target MCU | [Version] | Supplier qualification kit, record [TQ-01] |
| Static analysis | Example: Commercial analyser | [Version] | Validated for intended use, record [TQ-02] |
| Requirements and test management | Example: Application lifecycle management tool | [Version] | Computer software validation per QMS |
3.3 Activities by class
The table summarises which activities this plan applies to each class.
Check the standard's own requirements tables for the authoritative
mapping; this summary is a working aid only.
| Activity | Class A | Class B | Class C |
|---|
| Development plan and requirements | Yes | Yes | Yes |
| Architecture document | Not required by the standard | Yes | Yes |
| Detailed design of each unit | Not required by the standard | Not required by the standard | Yes |
| Unit verification | Not required by the standard | Yes | Yes, with additional acceptance criteria |
| Integration testing | Not required by the standard | Yes | Yes |
| System testing | Yes | Yes | Yes |
4. Software requirements (cl. 5.2)
| ID | Requirement | Type | Source | Risk control? | Verification |
|---|
| SRS-045 (Example) | The safety monitor shall stop the motor within 2 s when delivered volume exceeds the programmed volume by more than 5% | Risk control | RMF HZ-02 | Yes | ST-210 |
| SRS-052 (Example) | The software shall reject a rate above the drug library hard limit for the selected drug | Risk control | RMF HZ-04, usability file | Yes | ST-230 |
| SRS-060 (Example) | The software shall raise a high-priority occlusion alarm within the time stated in the alarm specification | Functional, alarm | System requirement SYS-120 | Yes | ST-240 |
| SRS-075 (Example) | The software shall accept only signed drug library files | Security | Threat model [TM-NNN] | Yes | ST-260 |
| SRS-090 (Example) | The event log shall record every alarm with time stamp and code | Functional | Post-market needs | No | ST-280 |
5. Architecture, segregation and SOUP (cl. 5.3)
5.1 Software items
| Item | Purpose | Runs on | Class | Interfaces |
|---|
| UI (Example) | Programming screens, alarms display | Main MCU | C | PCS via message queue |
| PCS (Example) | Rate control, drug library checks, alarm logic | Main MCU | C | UI, motor driver, LOG |
| SMF (Example) | Independent volume check and motor stop | Separate safety MCU | C | Volume sensor, motor stop line |
| LOG (Example) | Stores and exports event records | Main MCU, separate memory partition | A | Read-only interface from PCS |
5.2 Segregation argument
[State how items of different classes are kept apart and how that is
verified.] Example: LOG runs in a memory-protected partition enforced
by the MCU memory protection unit; it has no write path to PCS data and
its failure cannot stop or change delivery. The separation is verified
by fault injection test IT-140 and the memory map review DR-07.
5.3 SOUP list
| ID | SOUP item | Version | Used by | Functional and performance requirements | Required hardware and software | Known anomalies reviewed |
|---|
| SOUP-01 (Example) | Real-time kernel (commercial, vendor A) | [x.y.z] | PCS, UI | Pre-emptive scheduling, task switch below 10 microseconds | Main MCU, 64 kB RAM | Vendor anomaly list reviewed YYYY-MM-DD, 2 items not applicable |
| SOUP-02 (Example) | Cryptographic library (open source) | [x.y.z] | PCS | Signature verification of drug library files | Main MCU | Public vulnerability database checked YYYY-MM-DD |
| SOUP-03 (Example) | Display graphics library (commercial, vendor B) | [x.y.z] | UI | Renders all screens within 100 ms | Main MCU, display controller | Vendor release notes reviewed |
6. Detailed design, units and verification (cl. 5.4 to 5.6)
| Unit | Item | Detailed design ref | Acceptance criteria | Verification method | Record |
|---|
| RateCalc (Example) | PCS | SDD-PCS-03 | Correct rate for every unit conversion, boundary values, overflow handling | Unit test, code review, static analysis | UT-031, CR-031 |
| LimitCheck (Example) | PCS | SDD-PCS-05 | Hard and soft limits enforced for every drug entry | Unit test with library fixtures | UT-052 |
| VolumeCompare (Example) | SMF | SDD-SMF-01 | Stop triggered above 5% over programmed volume (tested at 5.1%), no stop at 4.9% or at exactly 5% | Unit test, timing analysis | UT-101 |
| Integration step | Items | Test | Result |
|---|
| IT-100 (Example) | PCS with SOUP-01 | Task timing under maximum load | [Pass / Fail] |
| IT-120 (Example) | PCS with UI | Programming flows end to end | [Pass / Fail] |
| IT-140 (Example) | LOG partition | Fault injection, LOG crash has no effect on delivery | [Pass / Fail] |
7. Software system testing (cl. 5.7)
| Test | Requirement | Configuration | Expected result | Result | Anomaly |
|---|
| ST-210 (Example) | SRS-045 | Build [tag] on production-equivalent hardware | Motor stops within 2 s at 5.1% over-delivery | Pass, worst case 1.4 s | None |
| ST-230 (Example) | SRS-052 | Build [tag], drug library [version] | Entry rejected above hard limit for every drug | Pass | None |
| ST-260 (Example) | SRS-075 | Build [tag] | Unsigned library refused with message | Fail on first run, pass after fix | PR-0147 |
8. Software release (cl. 5.8)
| Check | Result | Evidence |
|---|
| All planned verification complete | [Yes / No] | Sections 6 and 7 |
| Known residual anomalies listed and evaluated as not contributing to unacceptable risk | [Yes / No] | Anomaly list [REL-ANOM-NNN] |
| Released version identified | [Version, commit, build ID] | Release notes |
| Build procedure documented and repeatable | [Yes / No] | Build record [BLD-NNN] |
| Software and documentation archived | [Yes / No] | Archive location and retention period |
9. Software maintenance (cl. 6)
| Item | Value |
|---|
| Feedback sources | Complaints, service reports, vigilance, SOUP vendor notices, vulnerability feeds |
| Evaluation | Each report becomes a problem report in section 12 and is assessed for safety impact |
| Change approval | Change control board, decision recorded in [CCR-NNN] |
| Re-release | Through section 8, with regression testing justified |
| Regulatory assessment of changes | [Procedure that decides whether a change needs notified body or regulator notification] |
10. Software risk management (cl. 7)
| Hazard (RMF) | Software item | Potential cause | Risk control measure | Requirement | Verification |
|---|
| HZ-02 (Example) | PCS RateCalc | Arithmetic overflow in unit conversion | Independent safety monitor, range checks | SRS-045 | ST-210, UT-031 |
| HZ-02 (Example) | SOUP-01 | Task starvation delays motor control | Watchdog on SMF, timing tests | SRS-045 | IT-100, ST-210 |
| HZ-04 (Example) | UI | Decimal point entry misread | Drug library hard limits, confirmation screen | SRS-052 | ST-230, usability file USAB-07 |
Software changes: before each change, record whether it introduces a new
cause, affects an existing risk control, or changes the classification.
11. Configuration management (cl. 8)
| Configuration item type | Identification | Storage | Change control |
|---|
| Source code | Repository path and commit | Version control system | Pull request with review |
| SOUP | ID, version, checksum | Artefact repository | Change request and re-evaluation |
| Tools | Name and version | Tool register | Change request, re-validation |
| Documents | Document ID and version | Document control system | QMS document control |
12. Problem resolution (cl. 9)
| ID | Date | Description | Safety relevance | Decision | Verification | Status |
|---|
| PR-0147 (Example) | YYYY-MM-DD | Unsigned drug library accepted when file header truncated | Could load limits not approved by pharmacy (HZ-04) | Fix in 0.9.3 | ST-260 re-run | Closed |
| PR-0152 (Example) | YYYY-MM-DD | Screen flicker on alarm silence | None identified | Fix in next release | Planned ST-270 | Open |
13. Traceability matrix
| Hazard | Requirement | Item | Units | Integration | System test | Result |
|---|
| HZ-02 (Example) | SRS-045 | SMF, PCS | VolumeCompare, RateCalc | IT-100 | ST-210 | Pass |
| HZ-04 (Example) | SRS-052 | PCS, UI | LimitCheck | IT-120 | ST-230 | Pass |
| HZ-04 (Example) | SRS-075 | PCS | Signature check | IT-120 | ST-260 | Pass after PR-0147 |
14. Glossary and references
| Term | Working meaning in this file |
|---|
| Software system | The integrated software of one device or component, made of software items |
| Software item and unit | A part of the software; a unit is the smallest part not further divided for testing |
| SOUP | Software already developed and generally available that was not developed for incorporation into this device, or earlier software without adequate records of its development process |
| Segregation | Separation that prevents one item from affecting another, used to justify different classes |
| Anomaly | Any behaviour that deviates from requirements or expectations |
| Reference | Edition or date | Use |
|---|
| IEC 62304, Medical device software, Software life cycle processes | 2006 + A1:2015 (consolidated edition 1.1, 2015-06-26) | Process structure and clause numbers |
| ISO 14971 | 2019 | Risk management process |
| ISO 13485 | 2016 | Quality management system |
| IEC 81001-5-1 | 2021 | Security activities in the product lifecycle |
| IEC 82304-1 | 2016 | Health software products outside a physical device |
| EU example: Regulation (EU) 2017/745, Annex I section 17 | Check the consolidated text | Software requirements in the general safety and performance requirements |
| US example: FDA guidance Content of Premarket Submissions for Device Software Functions | Final, June 2023 | Documentation levels (Basic, Enhanced) for submissions: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-submissions-device-software-functions |
| UK example: Medical Devices Regulations 2002 (as amended) and MHRA guidance | Check current MHRA pages | Great Britain market requirements |
Standard and licence note
Structure aligned with IEC 62304:2006+AMD1:2015 (consolidated edition
1.1, published 2015-06-26; stability date 2028 on the IEC webstore,
checked October 2026). A second edition is under development; drafts
discussed in 2026 propose a wider health software scope and replacing
the A, B and C classes, so check the IEC webstore for the current
edition before use. Clause numbers are given for orientation only. All
wording, tables, IDs and examples are original; no text, table or
definition is reproduced from the standard. The device, software items,
SOUP and results are fictional examples. This template is not
regulatory or legal advice: check the current official texts, the rules
of your target markets and a qualified regulatory professional.