2. 医疗设备软件需求工程
医疗设备软件的需求工程与普通商业软件最大的区别在于：需求的第一来源不是市场部门，而是临床场景中的患者、医生、护士和设备本身。一条需求如果写错，可能表现为监护仪报警阈值设置不当、输液泵流速计算偏差，甚至影响患者安全。因此，本章把需求工程看作一条从“临床事实”到“可验证规格”再到“受控变更”的完整链路，而不是一份文档的写作练习。
一、临床需求获取：从工作流中提取可验证事实
临床需求获取的核心不是问用户“你想要什么功能”，而是观察并记录“在什么临床情境下，谁对设备做了什么，设备应如何响应”。以一台床旁监护仪为例，典型获取方式包括：跟随护士完成一次夜间巡房、记录报警设置与静音操作、观察中央站与床旁机的数据同步过程、访谈临床工程师关于报警疲劳的抱怨。获取到的原始素材通常是口语化、片段化的，需要转化为结构化条目。
一个实用的做法是采用“情境—角色—动作—期望响应—约束”五元组记录。例如：
情境：ICU 夜间，患者血氧下降
角色：责任护士
动作：将 SpO₂ 低限从 90% 调整为 88%
期望响应：3 秒内更新报警阈值，不触发历史报警重算
约束：调整需记录操作者与时间，且不能静音超过 2 分钟
这类记录直接对应后续的用户故事与验收条件。获取阶段还要区分“临床需求”与“技术实现偏好”：护士说“报警声太吵”是临床需求，而“把蜂鸣器换成压电式”是技术方案，不应在需求阶段锁定。
二、用户故事与用例：两种互补的表达
用户故事适合表达临床角色的价值诉求，格式为“作为<角色>，我希望<目标>，以便<价值>”。例如：“作为 ICU 护士，我希望在床旁机上一键切换成人/小儿模式，以便快速匹配不同患者的报警阈值。”用户故事强调可讨论、可拆分，但不直接给出验证细节，因此需要补充验收条件。
用例则更适合描述设备与外部角色之间的交互序列，尤其是涉及多步骤、异常分支和系统响应的场景。以“调整报警阈值”为例，用例可包含主成功场景、阈值越界、权限不足、通信中断等分支。用户故事与用例并非二选一：用户故事用于排优先级和迭代规划，用例用于细化交互与异常处理，两者在需求规格说明书中汇合。
三、需求规格说明书：把“可讨论”变成“可验证”
需求规格说明书（SRS）不是用户故事的堆砌，而是经过分析、去重、编号和基线化的正式条目。医疗设备软件的 SRS 通常按功能需求、性能需求、接口需求、安全需求、法规需求分类。每条需求应具备唯一标识、来源、优先级、验收准则和验证方法。以报警阈值调整为例，可写成：
REQ-ALM-007 报警阈值调整响应时间
来源：US-012 / 临床访谈 ICU-2024-03
描述：护士在床旁机调整 SpO₂ 低限后，系统应在 3 秒内完成阈值更新并生效。
验收准则：从确认操作到新阈值参与报警判断的时间 ≤ 3 s（n=20，取 P95）。
验证方法：测试 TC-ALM-021
优先级：高
这里的关键是“可验证”：3 秒、P95、n=20 都是可测量的。如果写成“快速响应”，测试人员无法判定通过与否，监管审核也无法接受。SRS 还应明确不做什么，例如“本版本不支持远程修改报警阈值”，避免范围蔓延。
四、可追溯性矩阵：让每条需求都有来路和去路
可追溯性矩阵（RTM）是需求工程的“账本”。它至少应建立三层映射：临床来源 → 需求条目 → 设计/代码 → 测试用例。正向追溯回答“这条需求被实现和验证了吗”，反向追溯回答“这个测试用例为什么存在”。在医疗设备软件中，RTM 还是法规审核和变更影响分析的核心证据。
一个简化的 RTM 片段如下：
| 需求 ID | 临床来源 | 设计模块 | 测试用例 | 状态 |
|---|---|---|---|---|
| REQ-ALM-007 | US-012 | AlarmManager | TC-ALM-021 | 已覆盖 |
| REQ-ALM-008 | US-012 | AlarmManager / AudioCtrl | TC-ALM-022 | 已覆盖 |
| REQ-ALM-009 | 临床审计要求 | AuditLogger | TC-ALM-023 | 待补充 |
当 RTM 中出现“无测试用例覆盖”或“测试用例无对应需求”时，就是需求工程需要介入的信号。前者意味着验证缺口，后者意味着范围外功能或需求遗漏。
五、变更管理：需求一旦基线化，变更必须受控
临床需求会变：新指南发布、耗材更换、医院采购新中央站、监管要求更新。变更管理不是阻止变更，而是让每次变更都有记录、有评估、有批准、有验证。典型流程是：提交变更请求（CR）→ 用 RTM 做影响分析（涉及哪些需求、设计、测试、风险）→ 变更控制委员会（CCB）评审 → 批准后更新 SRS 与 RTM 基线 → 执行受影响测试并回归。
常见误区：只改代码不改 SRS，或只改 SRS 不更新 RTM。前者导致文档与实现不一致，后者导致测试覆盖出现盲区。医疗设备软件审核时，这两类不一致都可能被判定为不符合项。
实践建议：把 RTM 做成可查询的表格或轻量工具，每次变更请求必须附带“影响范围”字段，由需求工程师填写受影响的需求 ID 和测试用例 ID。这样 CCB 评审时能快速判断变更代价，而不是凭感觉拍板。
总结来看，临床需求获取解决“来源真实”，用户故事与用例解决“表达可讨论”，SRS 解决“条目可验证”，RTM 解决“覆盖可追踪”，变更管理解决“演化可控制”。五者构成闭环，任何一环缺失，都会在测试、注册或临床使用阶段暴露出来。