3. 需求工程与架构映射

在医疗设备研发中，需求不是一份静态文档，而是一条从临床场景逐级收敛到代码实现的“证据链”。临床医生关心的是“能否在 30 秒内完成一次除颤能量设定并确认”，护士关心的是“报警是否会被误静音”，注册与合规关心的是“是否满足 IEC 60601-1-8 报警优先级要求”，而软件架构师关心的是“报警处理链路的实时性与可测试性”。需求工程的任务，就是把这些不同语言、不同粒度的诉求，翻译成可验证、可追溯、可映射到架构元素的软件需求。

三层需求的语义与转换

通常把需求分为三层：临床需求（Clinical Needs）描述医疗价值与临床工作流目标；用户需求（User Needs）描述具体角色在具体场景下的操作与期望；软件需求（Software Requirements）则是可被软件实现和测试的、带参数与判据的陈述。三者之间不是简单复制，而是逐层“加约束、加参数、加验证方法”。

例如，临床需求“降低除颤器误放电风险”可分解为用户需求“操作者在充电后必须看到明确的能量就绪指示，且放电需二次确认”，再细化为软件需求“在能量充电完成事件发生后 200 ms 内点亮 READY 指示灯，且放电按钮需在 500 ms 内被连续按下两次才触发”。可以看到，越往下走，时间、阈值、状态、接口越具体。

可追溯性矩阵：让每条需求都有“来路”和“去路”

可追溯性矩阵（RTM）是需求工程的核心工件。它至少应包含：需求编号、需求层级、来源（临床/用户/法规）、对应软件需求、关联架构元素、验证方法、验证状态。矩阵的价值不在于“填表”，而在于暴露三类问题：孤儿需求（没有来源）、悬空需求（没有实现或验证）、冲突需求（同一资源被多条需求争抢）。

下面给出一个可直接参考的 RTM 片段示例（示例数据，用于说明字段与追溯关系，非实测结果）：

填写 RTM 时，建议先建立“需求—架构”双向链接：正向从需求找到实现它的模块，反向从模块找到它承载的需求。这样在架构评审时，可以快速判断某个模块是否承担了过多质量属性，或某条安全需求是否被遗漏。

架构关键驱动因子与质量属性

并非所有需求都同等重要。架构关键驱动因子（Architecturally Significant Requirements, ASR）是那些会显著影响架构结构、技术选型或分解方式的需求。识别 ASR 的常用判据是：是否影响安全性、实时性、可靠性、可维护性、法规符合性，或是否跨多个模块。质量属性场景（QA Scenario）是表达 ASR 的有效方式，它包含六要素：刺激源、刺激、环境、制品、响应、响应度量。

例如：“当除颤器处于充电状态时，若电池电压低于 10.5 V，电源管理模块应在 50 ms 内切换至备用电池，并保持能量输出误差不超过 ±5%。”这条场景直接驱动了电源架构、任务调度周期和故障检测机制的设计。

从需求到架构的映射关系图

下图展示了临床需求、用户需求、软件需求与架构元素之间的追溯与映射关系，同时标出质量属性对架构的驱动路径。图中左侧为需求层级，右侧为架构层，中间通过追溯链连接，底部为质量属性对架构的约束。

需求映射的实操要点

在实际项目中，需求映射不是一次性活动，而是随架构演进持续维护的。建议在每次迭代评审时检查三件事：第一，新增的软件需求是否都能追溯到上层需求；第二，架构变更是否影响已有需求的验证方法；第三，质量属性场景是否仍然覆盖当前的风险点。对于医疗嵌入式软件，尤其要关注安全相关需求（如报警、剂量、能量输出）的追溯完整性，因为这些需求一旦断裂，可能导致注册审评中的重大缺陷。

此外，需求描述应避免“快速”“友好”“可靠”等不可验证的形容词。可验证的需求通常包含：触发条件、系统响应、响应时间、容差范围、异常处理。例如，把“报警要快”改写为“在 SpO₂ 低于 90% 持续 5 s 后，10 s 内发出中优先级报警，报警声压级 45–85 dB(A)”。这样的需求才能直接映射到架构中的报警管理模块，并设计出对应的测试用例。

最后，可追溯性矩阵应与需求管理工具（如 DOORS、Jama 或开源方案）结合使用，但工具只是载体，关键仍是团队对“每条需求都有来源、有实现、有验证”的共识。当架构师能指着某个模块说“它承载了 SR-012 和 SR-018，并满足实时性与安全性约束”时，需求到架构的映射才算真正建立。