跳转至

IEC 62304 文档要求

学习目标

完成本模块后,你将能够: - 理解IEC 62304要求的所有必需文档 - 掌握不同安全等级的文档要求差异 - 了解文档模板的结构和内容 - 应用文档管理最佳实践 - 建立符合IEC 62304的文档体系

前置知识

  • IEC 62304标准基础知识
  • 软件生命周期过程
  • 医疗器械软件安全分类
  • 文档管理基础

内容

文档要求概览

IEC 62304要求建立完整的文档体系,以证明软件开发过程的合规性和可追溯性。

文档的作用: - 📋 证明符合标准要求 - 🔍 支持审核和检查 - 📊 建立可追溯性 - 🔄 支持维护和变更 - 📚 知识传承和培训

文档分类: 1. 计划文档:定义如何执行过程 2. 规格文档:定义软件应该做什么和如何做 3. 记录文档:记录实际执行的活动和结果

必需文档清单

按生命周期过程分类

1. 软件开发过程文档

文档名称 Class A Class B Class C 说明
软件开发计划 ✅ ✅ ✅ 定义开发方法和资源
软件需求规格说明 ✅ ✅ ✅ 定义软件功能和性能要求
软件架构设计 简化 ✅ ✅ 定义软件高层结构
软件详细设计 ❌ ✅ ✅ 定义软件单元实现细节
软件验证计划 ✅ ✅ ✅ 定义验证策略和方法
软件验证报告 ✅ ✅ ✅ 记录验证活动和结果
软件确认计划 ✅ ✅ ✅ 定义确认策略和方法
软件确认报告 ✅ ✅ ✅ 记录确认活动和结果
软件发布记录 ✅ ✅ ✅ 记录发布的软件配置
需求追溯矩阵 ✅ ✅ ✅ 建立需求到测试的追溯

2. 软件维护过程文档

文档名称 Class A Class B Class C 说明
软件维护计划 ✅ ✅ ✅ 定义维护方法和流程
问题报告 ✅ ✅ ✅ 记录软件问题
修改请求 ✅ ✅ ✅ 记录修改需求
维护记录 ✅ ✅ ✅ 记录维护活动

3. 软件风险管理文档

文档名称 Class A Class B Class C 说明
软件风险管理计划 ✅ ✅ ✅ 定义风险管理方法
软件风险分析 ✅ ✅ ✅ 识别和分析软件风险
风险控制措施 ✅ ✅ ✅ 定义风险缓解措施
风险管理报告 ✅ ✅ ✅ 总结风险管理活动

4. 软件配置管理文档

文档名称 Class A Class B Class C 说明
软件配置管理计划 ✅ ✅ ✅ 定义配置管理方法
配置项清单 ✅ ✅ ✅ 列出所有配置项
变更记录 ✅ ✅ ✅ 记录配置变更
SOUP清单 ✅ ✅ ✅ 列出第三方软件

5. 软件问题解决文档

文档名称 Class A Class B Class C 说明
问题解决计划 ✅ ✅ ✅ 定义问题解决流程
问题报告 ✅ ✅ ✅ 记录问题详情
问题分析记录 ✅ ✅ ✅ 记录根本原因分析

核心文档详解

1. 软件开发计划(Software Development Plan, SDP)

目的:定义软件开发的方法、资源和时间表

必需内容:

# 软件开发计划

## 1. 项目概述
- 项目名称和标识
- 软件安全分类(Class A/B/C)
- 项目范围和目标
- 预期用途

## 2. 组织和职责
- 项目组织结构
- 团队成员和角色
- 职责分配
- 沟通机制

## 3. 开发生命周期模型
- 选择的生命周期模型(瀑布、迭代、敏捷等)
- 各阶段定义
- 阶段间的评审和批准

## 4. 开发标准和方法
- 编码标准(如MISRA C)
- 设计方法
- 文档标准
- 命名规范

## 5. 开发工具和环境
- 开发工具(IDE、编译器)
- 版本控制系统
- 测试工具
- 静态分析工具
- 需求管理工具

## 6. 交付物
- 文档清单
- 软件交付物
- 交付时间表

## 7. 验证和确认
- 验证策略
- 确认策略
- 测试方法
- 验收标准

## 8. 风险管理
- 风险管理方法
- 与ISO 14971的集成

## 9. 配置管理
- 配置管理方法
- 版本控制策略
- 变更控制流程

## 10. 问题解决
- 问题报告流程
- 问题跟踪方法
- 升级机制

## 11. 文档管理
- 文档控制流程
- 文档审批流程
- 文档归档方法

模板示例:

文档编号: SDP-001
版本: 1.0
日期: 2026-02-09
项目: 血压监测设备软件

1. 项目概述
   项目名称: BP-Monitor-SW
   软件安全分类: Class B
   项目范围: 开发血压测量和数据管理软件
   预期用途: 家用血压监测

2. 组织和职责
   项目经理: 张三
   软件架构师: 李四
   开发工程师: 王五、赵六
   测试工程师: 孙七
   质量保证: 周八

3. 开发生命周期模型
   采用迭代开发模型,包含以下阶段:
   - 需求分析(2周)
   - 架构设计(1周)
   - 详细设计(2周)
   - 实现和单元测试(4周)
   - 集成测试(2周)
   - 系统测试(2周)
   - 发布准备(1周)

4. 开发标准
   - 编码标准: MISRA C 2012
   - 注释规范: Doxygen格式
   - 文档模板: 公司标准模板

说明: 这是软件开发计划(SDP)文档的示例模板。包含项目概述、软件安全分类、项目范围和预期用途等关键信息,是IEC 62304要求的核心文档之一。

2. 软件需求规格说明(Software Requirements Specification, SRS)

目的:定义软件应该实现的功能和性能

必需内容:

# 软件需求规格说明

## 1. 引言
- 文档目的
- 文档范围
- 术语和缩写
- 参考文档

## 2. 总体描述
- 产品视角
- 产品功能
- 用户特征
- 约束条件
- 假设和依赖

## 3. 功能需求
- FR-001: [功能需求描述]
- FR-002: [功能需求描述]
- ...

## 4. 性能需求
- 响应时间要求
- 吞吐量要求
- 资源使用要求

## 5. 接口需求
- 硬件接口
- 软件接口
- 用户界面
- 通信接口

## 6. 安全需求
- 来自风险分析的安全需求
- 风险控制措施
- 报警和警告要求

## 7. 数据要求
- 数据定义
- 数据范围和约束
- 数据验证规则

## 8. 可靠性和可用性要求
- 可靠性指标
- 可用性指标
- 故障处理要求

## 9. 可维护性要求
- 诊断功能
- 日志记录
- 错误报告

## 10. 追溯性
- 需求到系统需求的追溯
- 需求到风险的追溯

需求编写示例:

需求ID: FR-BP-001
标题: 血压测量功能
优先级: 高
安全等级: Class B
来源: 系统需求 SR-001

描述:
系统应能够测量用户的收缩压和舒张压。

详细要求:
1. 测量范围:
   - 收缩压: 70-200 mmHg
   - 舒张压: 40-130 mmHg

2. 测量精度:±3 mmHg

3. 测量时间:不超过60秒

4. 输入:
   - 来自压力传感器的ADC数据
   - 采样率: 100 Hz

5. 输出:
   - 收缩压值(mmHg)
   - 舒张压值(mmHg)
   - 测量质量指示

6. 错误处理:
   - 如果测量失败,显示错误信息
   - 如果数据超出范围,拒绝测量

验证方法: 系统测试
追溯到: SR-001, RISK-003

说明: 这是软件需求规格(SRS)文档中需求条目的示例格式。每个需求包含ID、标题、优先级、安全等级、来源、描述和详细要求,确保需求的完整性和可追溯性。

3. 软件架构设计文档(Software Architecture Design Document)

目的:定义软件的高层结构

必需内容:

# 软件架构设计文档

## 1. 架构概述
- 架构目标
- 架构约束
- 架构原则

## 2. 架构视图
- 逻辑视图:组件和接口
- 物理视图:部署结构
- 开发视图:模块组织
- 过程视图:运行时行为

## 3. 软件组件
- 组件清单
- 组件职责
- 组件接口

## 4. 软件单元
- 单元划分
- 单元接口
- 单元依赖关系

## 5. SOUP
- SOUP清单
- SOUP功能和限制
- SOUP已知异常
- SOUP使用方式

## 6. 隔离策略
- 安全等级隔离
- 硬件抽象层
- 错误隔离机制

## 7. 数据流和控制流
- 主要数据流
- 控制流程
- 状态机

## 8. 架构风险分析
- 架构层面的风险
- 风险缓解措施

架构图示例:

┌─────────────────────────────────────────────┐
│          应用层 (Application Layer)          │
│  ┌──────────────┐  ┌──────────────┐        │
│  │ 用户界面模块  │  │ 数据管理模块  │        │
│  └──────────────┘  └──────────────┘        │
└─────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────┐
│          服务层 (Service Layer)              │
│  ┌──────────────┐  ┌──────────────┐        │
│  │ 测量算法模块  │  │ 数据处理模块  │        │
│  └──────────────┘  └──────────────┘        │
└─────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────┐
│      硬件抽象层 (Hardware Abstraction Layer) │
│  ┌──────────────┐  ┌──────────────┐        │
│  │ 传感器驱动    │  │ 显示驱动      │        │
│  └──────────────┘  └──────────────┘        │
└─────────────────────────────────────────────┘

说明: 这是软件架构设计文档中的架构图示例。展示了应用层、服务层和硬件抽象层的分层架构,以及各层之间的依赖关系,帮助理解系统的整体结构。

4. 软件详细设计文档(Software Detailed Design Document)

目的:定义软件单元的实现细节

必需内容:

# 软件详细设计文档

## 1. 单元设计
对每个软件单元:

### 单元名称: [单元名]
- 单元ID
- 单元职责
- 输入和输出
- 算法描述
- 数据结构
- 接口规格
- 错误处理
- 性能考虑
- 风险分析

## 2. 数据结构定义
- 结构体定义
- 枚举定义
- 常量定义

## 3. 算法详细说明
- 伪代码或流程图
- 计算公式
- 状态机

## 4. 接口详细规格
- 函数原型
- 参数说明
- 返回值说明
- 前置条件和后置条件

详细设计示例:

/**
 * 单元名称: 血压计算模块
 * 单元ID: UNIT-BP-CALC-001
 * 职责: 从原始传感器数据计算血压值
 */

/**
 * @brief 计算血压
 * @param raw_data 原始ADC数据数组
 * @param length 数据长度
 * @param result 输出结果结构体
 * @return 0成功,-1失败
 * 
 * 算法步骤:
 * 1. 数据预处理
 *    - 去除异常值
 *    - 低通滤波(截止频率20Hz)
 * 2. 特征提取
 *    - 检测压力峰值
 *    - 检测脉搏波形
 * 3. 血压计算
 *    - 收缩压 = 最大压力峰值
 *    - 舒张压 = 使用振荡法计算
 * 4. 结果验证
 *    - 检查范围有效性
 *    - 检查逻辑一致性
 * 
 * 前置条件:
 * - raw_data不为NULL
 * - length >= 100
 * - result不为NULL
 * 
 * 后置条件:
 * - 如果成功,result包含有效的血压值
 * - 如果失败,result未修改
 */
int calculate_blood_pressure(
    const uint16_t* raw_data,
    size_t length,
    BloodPressureResult* result
);

/**
 * 数据结构定义
 */
typedef struct {
    uint16_t systolic;      // 收缩压 (mmHg)
    uint16_t diastolic;     // 舒张压 (mmHg)
    uint8_t quality;        // 测量质量 (0-100)
    uint32_t timestamp;     // 时间戳
} BloodPressureResult;

5. 软件验证计划和报告

验证计划内容:

# 软件验证计划

## 1. 验证策略
- 验证方法(测试、审查、分析)
- 验证级别(单元、集成、系统)
- 验证覆盖目标

## 2. 单元验证
- 单元测试方法
- 测试工具
- 覆盖率目标

## 3. 集成验证
- 集成策略
- 集成测试方法
- 接口测试

## 4. 系统验证
- 系统测试方法
- 测试环境
- 测试数据

## 5. 代码审查
- 审查方法
- 审查检查清单
- 审查记录

## 6. 静态分析
- 分析工具
- 分析规则
- 缺陷处理

## 7. 追溯性验证
- 需求覆盖验证
- 追溯矩阵验证

## 8. 验证资源
- 人员和角色
- 工具和设备
- 时间表

验证报告内容:

# 软件验证报告

## 1. 验证概述
- 验证范围
- 验证方法
- 验证环境

## 2. 验证结果
- 单元测试结果
- 集成测试结果
- 系统测试结果
- 代码审查结果
- 静态分析结果

## 3. 覆盖率分析
- 需求覆盖率
- 代码覆盖率(语句、分支)
- 覆盖率报告

## 4. 缺陷统计
- 发现的缺陷数量
- 缺陷严重性分布
- 缺陷状态

## 5. 验证结论
- 验证是否通过
- 未解决的问题
- 风险评估

6. 软件发布记录

必需内容:

# 软件发布记录

## 1. 发布信息
- 软件名称和版本
- 发布日期
- 发布批准人

## 2. 软件配置
- 源代码版本
- 构建工具和版本
- 编译选项
- 依赖库版本

## 3. 已知问题
- 已知缺陷清单
- 限制和约束
- 使用注意事项

## 4. 验证状态
- 验证活动完成状态
- 测试通过状态
- 未解决问题的风险评估

## 5. 交付物
- 可执行文件
- 配置文件
- 用户文档
- 安装指南

## 6. 归档信息
- 归档位置
- 归档内容清单

文档管理最佳实践

1. 文档模板化

优势: - ✅ 确保一致性 - ✅ 提高效率 - ✅ 减少遗漏 - ✅ 便于审核

实施方法: - 为每种文档类型建立标准模板 - 在模板中包含必需章节 - 提供填写指南和示例 - 定期更新模板

2. 文档版本控制

版本命名规则:

主版本.次版本.修订版本
例如: 1.2.3

主版本: 重大变更
次版本: 功能增加或修改
修订版本: 错误修正或小改进

版本控制实践: - 所有文档纳入版本控制系统 - 记录每次修改的原因 - 保留历史版本 - 建立文档审批流程

3. 文档追溯性

追溯矩阵示例:

需求ID 设计ID 代码单元 测试用例 状态
FR-001 ARCH-001 bp_calc.c TC-001, TC-002 ✅
FR-002 ARCH-002 ui_display.c TC-003 ✅
FR-003 ARCH-003 data_mgmt.c TC-004, TC-005 🔄

追溯性工具: - 需求管理工具(DOORS, Jira) - 电子表格 - 专用追溯工具

4. 文档审查和批准

审查流程:

graph LR
    A[作者完成] --> B[技术审查]
    B --> C{通过?}
    C -->|否| A
    C -->|是| D[质量审查]
    D --> E{通过?}
    E -->|否| A
    E -->|是| F[批准]
    F --> G[发布]

审查检查清单: - ✅ 内容完整性 - ✅ 技术准确性 - ✅ 符合模板要求 - ✅ 追溯性完整 - ✅ 格式和语言规范

5. 文档归档和检索

归档原则: - 按项目组织 - 按文档类型分类 - 包含版本信息 - 便于检索

归档结构示例:

项目根目录/
├── 01_计划/
│   ├── SDP_v1.0.pdf
│   ├── 验证计划_v1.0.pdf
│   └── 维护计划_v1.0.pdf
├── 02_需求/
│   ├── SRS_v1.2.pdf
│   └── 需求追溯矩阵_v1.2.xlsx
├── 03_设计/
│   ├── 架构设计_v1.1.pdf
│   └── 详细设计_v1.0.pdf
├── 04_测试/
│   ├── 测试计划_v1.0.pdf
│   ├── 测试报告_v1.0.pdf
│   └── 测试用例_v1.0.xlsx
└── 05_发布/
    ├── 发布记录_v1.0.pdf
    └── 用户手册_v1.0.pdf

说明: 这是IEC 62304项目文档的推荐目录结构。按照开发生命周期阶段组织文档,包括计划、需求、设计、实现、测试、发布和维护等目录,便于文档管理和审核。

不同安全等级的文档要求对比

Class A 文档要求

简化的文档: - 软件开发计划(简化) - 软件需求规格说明 - 软件架构设计(简化) - 软件验证计划和报告 - 软件发布记录

可省略的文档: - 软件详细设计 - 单元测试文档 - 代码审查记录 - 静态分析报告

Class B 文档要求

完整的文档: - 所有计划文档 - 需求和设计文档(包括详细设计) - 验证和测试文档 - 单元测试文档 - 发布文档

推荐但非必需: - 代码审查记录 - 静态分析报告

Class C 文档要求

最严格的文档: - 所有Class B要求的文档 - 代码审查记录(必需) - 静态分析报告(必需) - 详细的测试覆盖率报告 - 完整的追溯矩阵

最佳实践

文档管理建议

  1. 及时更新:文档应与代码同步更新,避免滞后
  2. 使用工具:使用文档管理工具提高效率
  3. 模板标准化:建立并维护标准文档模板
  4. 审查机制:建立文档审查和批准流程
  5. 追溯性管理:使用工具管理追溯关系
  6. 版本控制:所有文档纳入版本控制
  7. 定期审核:定期审核文档完整性和一致性
  8. 培训团队:确保团队理解文档要求

常见陷阱

注意事项

  1. 文档滞后:代码先行,文档后补,导致不一致
  2. 过度文档化:文档过于详细,维护成本高
  3. 文档不足:文档过于简略,无法支持审核
  4. 追溯性缺失:缺少需求到测试的追溯
  5. 版本混乱:文档版本管理不当
  6. 审查流于形式:文档审查不认真
  7. 模板僵化:机械套用模板,不考虑实际情况
  8. 归档不当:文档归档混乱,难以检索

实践练习

  1. 为一个血糖监测设备制定文档清单,区分必需和可选文档
  2. 编写一个软件需求规格说明的模板,包含所有必需章节
  3. 建立一个需求追溯矩阵,追溯需求到设计、代码和测试
  4. 设计一个文档审查检查清单,确保文档质量

自测问题

问题1:IEC 62304要求的核心文档有哪些?
答案

IEC 62304要求的核心文档包括:

计划文档: - 软件开发计划 - 软件验证计划 - 软件维护计划 - 软件配置管理计划

规格文档: - 软件需求规格说明 - 软件架构设计文档 - 软件详细设计文档(Class B/C)

记录文档: - 软件验证报告 - 软件测试报告 - 软件发布记录 - 问题报告和修改记录

支持文档: - 需求追溯矩阵 - SOUP清单 - 风险分析文档

问题2:Class A、B、C软件的文档要求有什么区别?
答案

Class A(低风险): - 简化的架构设计 - 不要求详细设计 - 不要求单元测试文档 - 不要求代码审查记录

Class B(中风险): - 完整的架构设计 - 需要详细设计 - 需要单元测试文档 - 推荐代码审查(非必需)

Class C(高风险): - 完整的架构和详细设计 - 需要单元测试文档 - 必需代码审查记录 - 必需静态分析报告 - 需要100%代码覆盖率报告

总体原则:风险越高,文档要求越严格

问题3:软件需求规格说明(SRS)应该包含哪些内容?
答案

软件需求规格说明应包含:

  1. 功能需求:软件应实现的功能
  2. 性能需求:响应时间、吞吐量等
  3. 接口需求:硬件接口、软件接口、用户界面
  4. 安全需求:来自风险分析的安全要求
  5. 数据要求:数据定义、范围、验证规则
  6. 可靠性和可用性要求
  7. 可维护性要求
  8. 追溯性:到系统需求和风险的追溯

每个需求应该: - 有唯一标识符 - 清晰明确 - 可验证 - 可追溯

问题4:什么是需求追溯矩阵?为什么重要?
答案

定义: 需求追溯矩阵是一个表格,建立需求与设计、实现、测试之间的对应关系。

内容: - 需求ID → 设计元素 - 设计元素 → 代码单元 - 代码单元 → 测试用例 - 测试用例 → 测试结果

重要性: 1. 完整性验证:确保所有需求都被实现和测试 2. 影响分析:评估变更的影响范围 3. 审核支持:证明符合标准要求 4. 质量保证:确保需求到测试的完整链条 5. 维护支持:帮助理解系统结构

工具: - 需求管理工具(DOORS, Jira) - 电子表格 - 专用追溯工具

问题5:如何确保文档与代码的一致性?
答案

确保文档与代码一致性的方法:

  1. 同步更新:
  2. 代码修改时同步更新文档
  3. 将文档更新纳入变更流程

  4. 版本控制:

  5. 文档和代码使用同一版本控制系统
  6. 文档和代码版本关联

  7. 审查机制:

  8. 代码审查时检查文档一致性
  9. 文档审查时对照代码验证

  10. 自动化工具:

  11. 使用Doxygen等工具从代码生成文档
  12. 使用工具检查接口一致性

  13. 定期审核:

  14. 定期审核文档和代码的一致性
  15. 在发布前进行完整性检查

  16. 追溯性验证:

  17. 验证追溯矩阵的完整性
  18. 确保所有需求都有对应的实现和测试

相关资源

参考文献

  1. IEC 62304:2006+AMD1:2015 - Medical device software - Software life cycle processes
  2. FDA Guidance: "Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices"
  3. ISO/TR 80002-2:2017 - Medical device software - Part 2: Validation of software for medical device quality systems
  4. AAMI TIR45:2012 - Guidance on the use of AGILE practices in the development of medical device software
  5. 书籍:《Medical Device Software Documentation》by John F. Murray

💬 讨论区

欢迎在这里分享您的想法、提出问题或参与讨论。需要 GitHub 账号登录。