4. 软件需求分析

在医疗器械软件生命周期中，需求分析是把“临床要解决什么问题”逐步转化为“软件必须做什么、做到什么程度”的工程活动。它并非一次性写文档，而是沿着用户需求 → 系统需求 → 软件需求规格说明（SRS）三层逐级分解、逐级验证的过程。三层需求的对象、责任主体和验收方式各不相同，混为一谈是导致后期返工和追溯断裂的常见根源。

三层需求的分工与边界

用户需求（User Needs）描述临床使用者、患者、维护人员对产品的期望，通常以“谁、在什么场景、需要达成什么结果”表述，不涉及实现手段。例如“护士在夜间巡视时，需在3秒内确认输液泵当前流速与剩余量”。它来自临床调研、投诉数据、法规要求和同类产品分析，是设计输入的源头。

系统需求（System Requirements）把用户需求分配到硬件、软件、机械、算法等子系统，并给出可验证的指标。例如上述用户需求可分解为：显示刷新周期≤1s、流速显示分辨率0.1mL/h、剩余量误差≤±5%、报警声压≥65dB(A)。系统需求回答“由谁承担、达到什么量化指标”。

软件需求规格说明（SRS）只描述软件承担的部分，需细化到软件可以独立实现和测试的粒度，包括功能需求、性能需求、接口需求、安全需求（如IEC 62304中的软件安全分级对应的风险控制措施）以及设计约束。SRS是软件设计和软件测试的直接依据。

从用户需求到SRS的编写要点

编写用户需求时，应避免把实现方案写进去。例如“软件应提供夜间模式按钮”是方案，而“夜间巡视时无需强光即可读清关键参数”才是需求。每条用户需求应可追溯到临床来源或法规条款，并标注优先级。

系统需求阶段的核心动作是分配与量化。对每条用户需求，逐项判断由哪些子系统承担，并给出可测量的验收指标。指标必须包含数值、容差和测试条件，例如“在环境照度≤5lx、观察距离50cm条件下，流速字符高度≥8mm”。无法量化的需求应退回澄清，而不是留到测试阶段再解释。

SRS的编写建议遵循以下可操作规则：

• 唯一标识：每条需求分配稳定编号（如SRS-FUNC-012），编号一经发布不重用、不改变含义。
• 单一性：一条需求只描述一件事，避免“并且/或者”造成测试用例无法判定通过与否。
• 可验证性：每条需求必须能通过检查、分析、测试或演示之一验证，并注明验证方法。
• 无歧义：避免“快速”“友好”“尽可能”等主观词，改用可测量表述。
• 安全需求显式化：来自风险分析的风险控制措施必须写成软件需求，并标注对应的风险条目编号。

可追溯性矩阵的建立与维护

可追溯性不是事后补的表格，而是与需求同步生长的结构。实践中通常建立需求追溯矩阵（RTM），至少覆盖：用户需求 ↔ 系统需求 ↔ 软件需求 ↔ 软件设计 ↔ 测试用例 ↔ 风险条目。正向追溯用于确认每条需求都被实现和验证；反向追溯用于确认每个设计单元和测试用例都有需求来源，防止“镀金”功能和无依据代码。

下面给出一份可直接参考的追溯矩阵片段（示例数据，用于说明字段与填写方式）：

维护追溯矩阵时，建议把矩阵作为配置管理项纳入版本控制。每次需求变更，先更新矩阵中的链接关系，再评估受影响的设计、测试和风险分析。若某条软件需求找不到上游用户需求，说明它可能是多余功能；若某条用户需求没有下游软件需求，说明它可能被遗漏或由其他子系统承担但未记录。

常见问题与判断依据

需求分析阶段最常见的问题是层级混淆：把系统需求直接当SRS使用，导致软件测试无法判定；或把用户需求写成软件功能，导致设计自由度被过早锁死。判断一条需求属于哪一层，可以问三个问题：它描述的是使用者的目标（用户需求）、子系统的量化指标（系统需求），还是软件可独立实现和测试的行为（软件需求）？

另一个高频问题是追溯关系只做正向、不做反向。只做正向时，遗漏的需求和多余的设计都不容易被发现。建议在每次基线发布时，同时输出正向覆盖率和反向覆盖率两个指标：正向覆盖率 = 已有下游链接的需求数 / 需求总数；反向覆盖率 = 有上游来源的设计与测试项数 / 设计与测试项总数。两者都接近100%时，追溯结构才算基本完整。

需求分析的质量最终体现在变更成本上。追溯关系清晰的项目，一条需求变更可以在数小时内定位到受影响的代码、测试和风险文档；追溯断裂的项目，同样的变更往往需要数天排查，且容易遗漏。把追溯矩阵当作工程资产持续维护，而不是当作评审前临时补齐的文档，是医疗器械软件需求工程能否落地的关键分水岭。