第3章 IEC 62304标准精讲

3、IEC 62304标准精讲：软件安全等级分类（A/B/C）、软件开发流程要求、文档与追溯性管理

各位工程师朋友，大家好。今天我们聊聊IEC 62304。说实话，这个标准我看了不下二十遍。每次项目评审前，我都会再翻一遍。为什么？因为它是医疗器械软件的“宪法”。你产品能不能上市，很大程度上取决于你对它的理解深度。

我个人习惯把IEC 62304拆成三块来看：安全等级怎么定、流程怎么走、文档怎么管。今天我们就按这个逻辑来。

先问大家一个问题：你写的代码如果出错了，最坏后果是什么？

这个问题，就是安全等级分类的核心。

IEC 62304把软件安全等级分成三类：

嗯，这里要注意。很多人以为“我的设备只是监测，不治疗，所以肯定是A级”。错。我见过一个血氧仪项目，团队一开始定的是A级。后来一分析，如果血氧值显示错误，医生会做出错误判断，患者可能因此延误治疗。最后改成了B级。

⚠️ 避坑指南： 我曾经在一个项目中，团队把安全等级定低了。结果到了认证阶段，审核员要求重新评估，整个开发计划全部重做。白白浪费了三个月。记住：安全等级不是拍脑袋定的，必须基于风险分析。

怎么定？流程是这样的：

说白了，就是“木桶原理”。你的软件里最危险的那个功能，决定了整个软件的等级。

很多公司觉得IEC 62304的流程要求就是“写文档”。我告诉你，不是的。流程的目的是让你系统化地降低风险。

标准把开发流程分成几个阶段：

每个阶段都有对应的输出物。我建议你把它当成一个检查清单。做完一步，打一个勾。

💡 个人经验： 我在做输液泵项目时，发现很多团队在“需求分析”阶段就出问题了。需求写得太模糊，比如“系统应能准确控制输液速度”。什么叫“准确”？误差范围是多少？后来我们改成“输液速度误差不超过±2%”。这才是一个可验证的需求。

对于不同安全等级，流程的严格程度是不一样的：

你想想看，C级软件连“详细设计”都要做。这意味着什么？意味着你的代码逻辑必须细化到函数级别。我见过一些C级项目，详细设计文档比代码本身还厚。嗯，这其实是对的。

说到文档，很多人头疼。但我要说，文档不是给别人看的，是给你自己看的。

为什么？因为审核员会问：“你怎么证明你做了你说过要做的事？”

答案就是追溯性矩阵。

追溯性管理，说白了就是一条链：

用户需求 → 软件需求 → 架构设计 → 详细设计 → 代码 → 测试用例 → 测试结果

每个环节都要能对上。比如：

审核员随便挑一个需求，你都能拿出对应的设计、代码和测试结果。这才叫追溯性。

    🔑 关键点：
    追溯性不是事后补的。我建议你在项目一开始就建立好模板。每写一个需求，就分配一个唯一ID。每写一行代码，就注释上对应的需求ID。这样到最后，你只需要跑一个脚本，就能生成完整的追溯矩阵。

文档方面，标准要求至少包括：

我曾经在一个项目中，审核员要求看“软件变更记录”。我们当时用的是Git，每次提交都有commit message。但审核员说：“我要看的是变更对安全的影响分析。” 嗯，从那以后，我们的commit message里必须包含“是否影响安全等级”这一项。

⚠️ 注意： 文档不是越多越好。标准要求的是“必要”的文档。你写100页没人看的东西，不如写10页有用的。关键是每个文档都要有明确的目的和受众。

最后，给大家一个建议。做IEC 62304认证，不要把它当成负担。把它当成一个框架，帮你系统化地管理软件质量。你想想看，如果你的代码真的救了人一命，那这些流程和文档，就是你的“护身符”。

好，今天就聊到这里。下一章我们讲软件风险管理，这是和ISO 14971结合最紧密的部分。到时候我会分享一些实际案例，看看风险分析到底怎么做才不流于形式。