4. 医疗嵌入式软件需求分析与测试需求转化

临床需求往往以自然语言描述，例如“输液泵在管路阻塞时应及时报警并停止输液”。这类表述对临床人员是清晰的，但对嵌入式软件开发和测试而言，它缺少可判定的边界：多快算“及时”？多大阻力算“阻塞”？报警后是否允许继续输注？因此，需求分析的核心任务不是把这句话抄进需求文档，而是把它拆解为可验证的软件需求，并进一步转化为可执行的测试需求。

一、从临床需求到软件需求的三层分解

医疗嵌入式软件的需求通常分为三层：用户需求、系统需求、软件需求。用户需求描述临床使用目标；系统需求把目标分配到硬件、软件、机械等子系统；软件需求则精确到软件能观测的输入、能控制的输出、状态迁移和时序约束。以输液泵阻塞报警为例：

• 用户需求：当输液管路发生阻塞时，泵应提醒医护人员并停止输液，避免患者受到伤害。
• 系统需求：压力传感器检测管路压力，主控软件在压力超过阈值并持续一定时间后，驱动报警并停止电机。
• 软件需求：软件以 10 ms 周期采样压力 ADC 值，经滑动平均滤波后与阻塞阈值比较；当连续 3 个采样周期超过阈值时，进入阻塞报警状态，关闭电机驱动，点亮红色报警灯，并发出 2.5 kHz 蜂鸣。

可以看到，软件需求把“及时”转化为“连续 3 个采样周期”，把“阻塞”转化为“压力 ADC 值超过阈值”，把“报警”转化为具体的输出动作。这种转化是后续测试用例设计的基础。

二、识别安全相关需求

并非所有需求都同等重要。医疗嵌入式软件必须识别安全相关需求，即一旦失效可能直接导致患者伤害或死亡的需求。常用方法是结合风险分析结果，对每条需求标注安全等级。例如，阻塞报警失效可能导致输液过量或空气栓塞，属于高风险；而历史记录查询失败通常只影响可追溯性，风险较低。

识别安全相关需求时，可以追问三个问题：该需求失效后，患者是否可能受到伤害？伤害的严重程度如何？是否存在软件可独立控制的危险输出？如果答案指向高风险，则该需求必须被标记为安全相关，并在测试中给予更高的覆盖强度和更严格的通过准则。

三、编写可测试的需求规格

可测试的需求应具备五个特征：明确输入、明确输出、明确状态、明确时序、明确边界。以下是一个可测试的软件需求示例：

需求编号：SWR-INF-012
需求名称：阻塞报警触发与电机停止
安全等级：高
输入条件：压力传感器采样值 P，采样周期 T=10 ms
处理逻辑：对最近 5 个采样值做滑动平均，得到 P_avg
判定条件：若 P_avg ≥ 80 kPa 且持续 ≥ 30 ms，则判定为阻塞
输出动作：关闭电机驱动；点亮红色报警灯；蜂鸣器以 2.5 kHz 鸣响
恢复条件：压力恢复至 P_avg ≤ 60 kPa 且持续 ≥ 100 ms，且医护人员按下消音键
异常处理：若压力传感器读数超出 0～120 kPa 有效范围，进入传感器故障状态

这条需求中，输入、输出、阈值、持续时间、恢复条件、异常处理都已明确，测试人员可以直接据此设计测试用例，而不需要再猜测“及时”或“阻塞”的含义。

四、基于需求设计测试用例

测试用例设计应从需求中的判定条件出发，覆盖正常路径、边界路径和异常路径。对于上述阻塞报警需求，可以设计以下用例：

这些用例直接对应需求中的阈值、持续时间和恢复条件，体现了“需求—测试”一一映射。对于安全相关需求，还应增加故障注入用例，例如模拟压力传感器卡滞、ADC 通道断线、电机驱动短路等，验证软件在异常输入下是否仍能进入安全状态。

五、需求追溯与变更控制

需求分析不是一次性活动。临床需求变更、风险分析更新、法规标准换版，都可能触发软件需求和测试用例的调整。因此，必须建立需求追溯矩阵，记录每条临床需求对应的软件需求、安全等级、测试用例和验证状态。当某条软件需求发生变更时，可以快速定位受影响的测试用例，评估是否需要重新执行回归测试。

在实际项目中，建议把追溯关系直接维护在需求管理工具中，例如每条软件需求关联至少一条测试用例，每条安全相关需求关联至少一条故障注入用例。测试执行后，记录实际结果与预期结果的偏差，并判断偏差是否可接受。如果偏差涉及安全相关需求，必须启动缺陷分析和风险再评估，不能简单标记为“已知问题”后放行。

总结来说，从临床需求到软件需求，再到测试需求，是一条需要反复校准的转化链。需求分析人员要做的，是把模糊的临床语言翻译成精确的软件行为；测试人员要做的，是把这些精确行为转化为可执行、可判定、可追溯的测试用例。两者共同保证医疗嵌入式软件在真实临床场景中的安全性和有效性。