3. 医疗设备软件可靠性需求工程

可靠性需求工程是医疗设备软件全生命周期中最具杠杆效应的环节。一个在需求阶段未被识别的可靠性缺陷，若遗留到现场，其修复成本可能是需求阶段修复的数十倍甚至上百倍。本章聚焦三个核心问题：如何从临床需求、法规要求和风险控制中提取可靠性需求；如何保证需求的可追溯性、可验证性与完整性；以及当需求缺陷真实发生时，现场故障会呈现怎样的形态。

3.1 可靠性需求的三个来源

医疗设备软件的可靠性需求并非凭空产生，它有三个明确的来源，且三者之间存在交叉与约束关系。

临床需求描述的是设备在真实诊疗场景中必须持续、正确完成的功能。例如，一台输液泵的临床需求是“在设定的流速下持续输注，并在管路阻塞时于规定时间内报警”。从可靠性视角看，这要求软件在电源波动、传感器漂移、通信中断等条件下仍能维持或安全终止输注。临床需求往往以用户故事或使用场景的形式给出，可靠性工程师需要将其转化为可量化的指标，如“连续运行72小时无中断”“阻塞检测响应时间≤15秒”。

法规要求是强制性的外部约束。IEC 62304将软件安全等级分为A、B、C三级，等级越高，对需求追溯、架构设计和验证的要求越严格。FDA的510(k)和PMA路径要求提交软件需求规格书及其追溯矩阵。中国NMPA的《医疗器械软件注册审查指导原则》同样要求提供需求规范、可追溯性分析和验证记录。法规要求不直接规定“可靠性指标是多少”，但它规定了“你必须证明你的需求是完整、可追溯、可验证的”。

风险控制是第三个来源，也是最容易被忽视的。ISO 14971要求对每个已识别危害进行风险估计，并采取控制措施。当控制措施落到软件上时，就转化为可靠性需求。例如，风险分析识别出“输注速度设置错误可能导致药物过量”，对应的软件控制措施可能是“设置值超出安全范围时拒绝执行并提示”，这本身就是一条可靠性需求。

3.2 从来源到需求条目的转化方法

转化过程需要一套结构化的方法，而不是凭经验逐条编写。以下给出一个可操作的转化路径。

第一步，建立“来源—需求”映射表。每一行对应一个来源条目（临床场景、法规条款或风险控制措施），每一列对应转化后的可靠性需求。映射表至少包含：来源标识、来源描述、转化后的需求陈述、需求类型（功能/性能/安全/接口）、验证方法。

第二步，对每条需求进行“可靠性修饰”。原始需求往往只描述正常路径，可靠性修饰要求补充异常路径和边界条件。例如，原始需求“软件应显示当前输注速度”可修饰为“软件应在正常、报警、暂停三种状态下均正确显示当前输注速度，显示刷新周期≤1秒，且在通信中断时保持最后有效值并标记为‘数据可能过期’”。

第三步，分配验证方法。每条可靠性需求必须对应至少一种验证方法：测试、分析、演示或检查。对于“阻塞检测响应时间≤15秒”，验证方法为测试，需明确测试条件（管路类型、阻塞程度、流速设定）和通过准则。对于“软件在断电后恢复时应保持配置参数”，验证方法可以是测试加分析。

第四步，进行完整性检查。完整性检查不是简单看“有没有漏”，而是从三个维度审查：来源覆盖度（每个临床场景、法规条款、风险控制是否都有对应需求）、状态覆盖度（正常、异常、边界、恢复状态是否都有需求）、接口覆盖度（人机接口、通信接口、传感器接口是否都有可靠性约束）。

3.3 需求可追溯性、可验证性与完整性检查

可追溯性要求需求之间、需求与设计、需求与测试之间存在双向链接。正向追溯从来源到需求到设计到测试，确保每条来源都被实现和验证；反向追溯从测试到需求到来源，确保每条测试都有需求依据，每条需求都有来源支撑。实践中，追溯矩阵是核心工具，但矩阵本身不是目的，目的是在变更发生时能快速评估影响范围。

可验证性要求每条需求都是客观、可测量、无歧义的。常见的不可验证需求包括“软件应具有高可靠性”“界面应友好”“响应应迅速”。可验证的改写是“软件在95%的输注场景下，从用户按下启动键到泵开始运转的时间≤2秒”“软件在连续运行72小时内，无因软件原因导致的非计划中断”。

完整性检查可以借助检查单进行，但检查单需要根据设备类型定制。以下给出一个面向输液泵类设备的可靠性需求完整性检查表示例。

3.4 需求缺陷导致的现场故障复盘

以下案例基于行业公开召回信息和合理假设构建，用于说明需求缺陷如何演变为现场故障。

案例背景：某输液泵软件在临床使用中出现“阻塞报警延迟”投诉。现场表现为：管路完全阻塞后，部分设备在30秒至2分钟后才报警，超出说明书声称的15秒。部分投诉伴随“报警后泵未停止”的二次故障。

需求追溯：回溯需求文档发现，原始需求写的是“软件应检测阻塞并报警”，未规定响应时间，也未定义“阻塞”的判定条件（压力阈值、持续时间、流速相关性）。风险分析中虽识别了“阻塞未及时报警”的危害，但控制措施仅写“软件检测阻塞”，未转化为可验证的可靠性需求。

根因分析：开发团队在实现时采用了压力传感器采样值连续超过阈值3次才触发报警的逻辑，采样周期为200ms，理论上600ms即可触发。但现场故障设备中，部分设备的压力传感器存在缓慢漂移，导致基线压力升高，阻塞判定阈值相对降低，软件为抑制误报警加入了“动态基线调整”逻辑，该逻辑在低流速下调整过慢，导致报警延迟。更严重的是，报警触发后，软件进入报警状态但未立即停止泵，而是等待“报警确认”后才停止，这与临床预期的“报警即停止”不符。

需求缺陷定位：三个需求缺陷共同导致故障。其一，阻塞检测需求缺少响应时间指标和判定条件定义；其二，动态基线调整逻辑未在需求中说明，属于设计阶段引入的未受控行为；其三，报警后行为未在需求中明确“报警即停止”还是“报警后等待确认”。

纠正措施：将阻塞检测需求改写为“在流速≥1 mL/h时，管路完全阻塞后，软件应在15秒内触发报警并停止泵；报警停止泵的行为不可被配置为延迟；动态基线调整算法需在需求中定义其适用流速范围和调整速率上限，并作为安全相关需求进行验证”。同时，在追溯矩阵中补充该需求到风险控制措施的链接，并增加针对低流速、传感器漂移场景的测试用例。

从上述案例可以看出，需求缺陷的传导具有隐蔽性：它不会在代码编译时暴露，也不会在单元测试中必然暴露，而是可能在特定临床场景、特定硬件状态下才被触发。因此，可靠性需求工程必须与风险分析、验证测试形成闭环。需求阶段多花一天时间明确“阻塞后15秒内报警并停止泵”，现场就可能少一次召回、少一份伤害报告。

在实际项目中，建议将可靠性需求评审作为独立于功能需求评审的专项活动，评审输入包括临床场景清单、法规条款对照表、风险控制措施清单，评审输出包括需求条目、追溯矩阵和完整性检查记录。评审通过后，需求基线冻结，任何变更都需重新评估其对追溯矩阵和验证用例的影响。