# 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.

<!--
Guidance: How to use this template
- One file per software system. If the device has several software
  systems (for example main controller and an independent safety
  monitor), keep one classification and SOUP list per system in
  sections 2 and 5, and share the rest.
- IEC 62304 assumes a quality management system (ISO 13485 is the
  usual one) and a risk management process (ISO 14971). This file
  points to both and does not repeat them.
- The safety class drives how much of the process is required. Class
  it early, record the reasoning, and revisit it when the architecture
  or the risk file changes.
- Clause numbers in headings point to IEC 62304:2006+A1:2015 for
  orientation. All wording here is original.
- The examples continue the fictional "Corvane IP-200 infusion pump"
  from the fictional maker Corvane Medical Ltd used in the risk file
  template. Delete them.
- Related templates: risk management file
  (`compliance/iso-14971-risk-file`), design and development file
  (`compliance/iso-13485-design-controls`), usability engineering file
  (`compliance/usability-engineering-file`), technical documentation
  (`compliance/mdr-technical-documentation`), software FMEA
  (`ops/fmea-software`), verification and validation plan
  (`quality/vv-plan`).
-->

## Document control

<!-- Guidance: The plan is a controlled document under the QMS. It must be updated as development proceeds (IEC 62304 cl. 5.1.2), so expect several approved versions before release. -->

| 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

1. General requirements and context (cl. 4)
2. Software safety classification (cl. 4.3)
3. Software development plan (cl. 5.1)
4. Software requirements (cl. 5.2)
5. Architecture, segregation and SOUP (cl. 5.3)
6. Detailed design, units and verification (cl. 5.4 to 5.6)
7. Software system testing (cl. 5.7)
8. Software release (cl. 5.8)
9. Software maintenance (cl. 6)
10. Software risk management (cl. 7)
11. Configuration management (cl. 8)
12. Problem resolution (cl. 9)
13. Traceability matrix
14. Glossary and references

## 1. General requirements and context (cl. 4)

<!-- Guidance: Show the foundations the standard expects before any development activity: a quality management system, a risk management process and, for software already on the market before the standard was applied, the legacy software route. Auditors start here. -->

| 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)

<!-- Guidance: Classify each software system by the worst harm that a software failure could contribute to, after taking into account risk control measures that are outside the software (Amendment 1 changed the wording to make this explicit). Assume the software can fail: a probability of failure is not an argument for a lower class. A common pitfall is claiming a lower class for an item without an architecture that really segregates it. -->

| 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)

<!-- Guidance: The plan names the processes, deliverables, standards, methods, tools and integration approach, and how the plan links to the system design. Keep it short and point to procedures where your QMS already has them. -->

### 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)

<!-- Guidance: Write requirements that are testable and traceable. Include risk control requirements from the risk management file, interfaces, alarms, security, data definitions, user interface requirements from the usability engineering file, and regulatory requirements. Re-evaluate the risk analysis when requirements change. -->

| 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)

<!-- Guidance: Describe the software items and their interfaces, identify segregation needed for risk control, and list every item of software of unknown provenance (SOUP) with its functional and performance requirements and the hardware and software it needs. The SOUP list is one of the most frequently requested records in audits. -->

### 5.1 Software items

```mermaid
flowchart LR
  UI["UI item (class C)"] --> PCS["Pump control software (class C)"]
  PCS --> MOT["Motor driver hardware"]
  SMF["Safety monitor firmware (class C)"] -->|"Stop signal"| MOT
  SENS["Volume sensor"] --> SMF
  PCS --> LOG["Event log export (class A)"]
  RTOS["SOUP-01 real-time kernel"] -.-> PCS
  RTOS -.-> UI
```

| 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)

<!-- Guidance: For class C, document the design of each unit and its interfaces in enough detail to implement it correctly. Define unit acceptance criteria before testing, and plan integration in the order the architecture allows. Record regressions found during integration as problems in section 12. -->

| 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)

<!-- Guidance: Test every software requirement, including risk control requirements, against pass criteria fixed before the run. Record tester, configuration, results and anomalies. Re-run affected tests after a change and document why the regression set is sufficient. -->

| 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)

<!-- Guidance: Before release, confirm verification is complete, list known residual anomalies with their evaluation, record the exact version and how it was built, and archive the build so it can be reproduced. -->

| 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)

<!-- Guidance: Plan how feedback, problem reports and change requests are received, evaluated and implemented after release, including SOUP updates and security patches. Each change re-enters the development process at the right point and goes through risk analysis. -->

| 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)

<!-- Guidance: Identify software items that can contribute to hazardous situations, the causes (including SOUP failures and unexpected inputs), the risk control measures and their verification. Feed results into the ISO 14971 file and keep IDs consistent with it. -->

| 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)

<!-- Guidance: Identify every configuration item (source, SOUP, tools, documents, build scripts), control changes to them, and keep a status record that shows which version of each item is in each release. -->

| 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)

<!-- Guidance: Every problem gets a report, an investigation of its cause and safety relevance, a decision, verification of the fix, and a check for trends. Keep problem reports even when the decision is not to fix. -->

| 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

<!-- Guidance: Link each risk control and requirement to architecture, units and tests. A reviewer should be able to follow any hazard to a test record. -->

| 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

<!-- Guidance: Use plain working definitions and refer to the standard for normative definitions. List the editions you applied, and record market-specific expectations separately. -->

| 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.

Official text: IEC, purchase or licensed access:
https://webstore.iec.ch/en/publication/22794 (also available from
national standards bodies).

Template licence: MIT.