4. 需求工程与可验证性设计
在医疗器械安全测试与验证工程中，需求工程不是“写文档”的前置环节，而是决定后续测试能否成立、验证是否可判定的根本约束。临床需求描述的是“医生或患者需要达成什么”，用户需求描述的是“操作者如何使用设备完成工作”，而安全需求必须回答一个更严格的问题：在什么条件下、对什么对象、施加什么输入、观察到什么结果，才能判定这条需求被满足或未被满足。如果一条需求无法被观测、无法被判定，它在验证阶段就会退化为“主观确认”，无法形成可追溯的客观证据。
从临床需求到安全需求的三层转化
需求转化通常经历三个层次。第一层是临床需求，例如“在除颤过程中，设备应避免对操作者造成电击风险”。第二层是用户需求，例如“操作者按下放电按钮后，设备应在充电完成后才允许放电”。第三层是安全需求，例如“当储能电容电压低于设定放电阈值时，放电回路应保持闭锁，且面板显示‘未就绪’状态；在电压达到阈值后，闭锁解除，放电允许信号有效”。可以看到，安全需求必须包含触发条件、对象、动作、可观测输出和判定边界。
一个常见的错误是把用户需求直接当作安全需求。例如“设备应防止误放电”这句话无法测试，因为它没有定义“误”的判定条件。正确的做法是将其拆解为可验证的约束：在什么状态下禁止放电、禁止信号如何被检测、允许放电的条件是什么、边界值是多少、超时如何处理。只有拆到这一层，测试用例才能被设计出来。
可验证性检查的五个问题：
- 这条需求是否描述了可观测的输出（信号、显示、日志、物理动作）？
- 是否给出了明确的输入条件或触发事件？
- 是否定义了判定阈值、容差或时间窗口？
- 是否说明了异常或边界条件下的预期行为？
- 是否能够设计出一条测试用例，使其结果只有“通过/不通过”两种判定？
需求追溯矩阵的构建方法
需求追溯矩阵（Requirements Traceability Matrix, RTM）是连接临床需求、用户需求、安全需求、设计输出、测试用例和验证结果的纵向链条。它的核心价值不是“表格好看”，而是当某一层发生变更时，能够快速定位受影响的下游对象。一个可用的 RTM 至少应包含以下字段：需求编号、需求层级、需求描述、来源、设计对应项、测试用例编号、验证方法、验证结果、状态。
以输液泵为例，假设临床需求为“防止因输液速度异常导致患者药物过量”。用户需求可写为“当实际流速与设定流速偏差超过允许范围时，设备应发出报警并停止输液”。安全需求则进一步细化为：“在流速检测周期 100 ms 内，若连续 3 个周期检测到实际流速高于设定流速的 120%，则触发高优先级报警，并在 500 ms 内关闭泵驱动输出。”这条安全需求可以直接对应测试用例：注入模拟流速信号，使其在 300 ms 内达到设定值的 130%，观察报警是否在 500 ms 内触发、泵驱动输出是否被切断。
验证计划的编写要点
验证计划不是测试用例的简单堆叠，而是对“用什么方法、在什么条件下、由谁、依据什么判定准则”进行预先约定。对于安全需求，验证方法通常分为四类：测试（施加输入并观测输出）、检验（检查设计文件或物理特征）、分析（通过计算或仿真证明）、演示（在真实或模拟场景中观察功能）。选择哪种方法，取决于需求的性质和风险等级。
以电气安全需求为例，“应用部分与地之间的漏电流在正常状态下不超过 100 μA”这条需求，验证方法应选择测试，并明确测试条件：供电电压、温度、湿度、测试仪器精度、测量点位置。若需求是“外壳应能承受 1.5 J 冲击而不破裂”，则可能采用检验加测试的组合。验证计划中必须写明样本量、接受准则、异常处理流程和记录要求，否则验证结果无法被审计和复现。
验证计划的最小可用结构：需求编号 → 验证方法 → 测试条件与设备 → 样本量 → 接受准则 → 记录表单 → 异常处理。对于安全等级较高的需求，还应增加独立复核和回归验证要求。
可验证性设计的常见陷阱
第一类陷阱是模糊副词，如“快速”“可靠”“足够”。这些词在需求评审中容易被忽略，但在测试阶段会直接导致无法判定。替代方式是给出量化边界，例如“在 200 ms 内”“连续 3 次采样均满足”“误报率低于 1%”。
第二类陷阱是复合需求，即一条需求中同时包含多个可独立验证的约束。例如“设备应报警并停止输液并记录事件”实际上包含三个可分别测试的行为。复合需求会导致测试用例覆盖不完整，建议拆分为独立编号的需求条目。
第三类陷阱是缺少异常路径。安全需求不仅要描述正常条件下的行为，还要描述传感器失效、通信中断、电源跌落等异常条件下的预期状态。例如“若流速传感器信号丢失超过 200 ms，设备应进入安全状态并发出报警”，这条需求才真正具备安全意义。
第四类陷阱是追溯断裂。当设计变更时，如果没有 RTM 的纵向连接，测试用例可能仍然针对旧版本需求执行，导致验证结果与当前设计不一致。因此，RTM 必须作为受控文档纳入变更管理流程，任何需求修改都应触发下游影响分析。
从需求到验证的闭环示例
回到输液泵案例，完整的闭环可以这样组织：临床风险分析识别出“药物过量”危害，导出临床需求 CN-01；使用场景分析将其转化为用户需求 UN-03；安全需求 SR-07 给出量化阈值和时间窗；设计输出 DD-12 实现流速比较与泵驱动闭锁；测试用例 TC-07 定义注入信号波形和观测点；验证结果 VR-07 记录实测报警时间 420 ms、泵驱动输出 0 V，判定为通过。若后续将阈值从 120% 调整为 110%，则 SR-07、TC-07、VR-07 必须同步更新，并在回归测试中重新执行。
这套方法的核心并不复杂：每一条安全需求都必须能回答“怎么测、测什么、什么算通过”。需求追溯矩阵和验证计划是把这种可验证性固定下来的工程工具。它们让安全测试不再是事后补救，而是从需求阶段就被设计出来的可执行路径。