3. 需求追溯的核心概念与模型

在医疗软件的需求工程中，追溯不是一张“事后补出来的表格”，而是一套贯穿需求、设计、实现、测试与风险控制的关系网络。要真正用好追溯，必须先理解五个核心概念：追溯链、追溯矩阵、双向追溯、追溯粒度，以及追溯关系类型（派生、满足、验证、依赖）。它们共同构成了需求追溯的模型基础。

追溯链：从需求到证据的路径

追溯链（Trace Chain）描述的是从一个需求出发，沿着关系边一路走到最终验证证据的完整路径。例如，一条“输液泵阻塞报警响应时间不超过 5 秒”的用户需求，可能派生出“阻塞检测模块应在 200 ms 内识别压力异常”的软件需求，再被“阻塞检测函数 detect_occlusion()”满足，最终由“阻塞报警响应时间测试用例 TC-0412”验证。这条 用户需求 → 软件需求 → 设计/代码 → 测试用例 → 测试结果 的路径就是一条追溯链。

追溯链的价值在于：当测试失败或发生变更时，可以沿链快速定位受影响的所有节点。链的完整性（无断链）是医疗软件合规审查的重点，例如 IEC 62304 要求每个软件需求都能追溯到其实现与验证。

追溯矩阵：关系网络的结构化表达

追溯矩阵（Traceability Matrix, TM）是把追溯链组织成二维表格的形式，通常行表示上游对象（需求、风险），列表示下游对象（设计、代码、测试）。矩阵中的每个标记表示一条关系边。矩阵的优点是便于批量检查覆盖率，例如“有多少条需求没有对应测试用例”。

在实际项目中，矩阵往往不是单一的一张表，而是分层组织的：用户需求—系统需求矩阵、系统需求—软件需求矩阵、软件需求—测试用例矩阵等。分层矩阵可以避免单表过大，也便于不同角色维护各自负责的层级。

双向追溯：正向与反向都要通

双向追溯（Bidirectional Traceability）要求关系不仅可以从上游查到下游（正向），也能从下游回溯到上游（反向）。正向追溯回答“这条需求被实现和验证了吗”，反向追溯回答“这个测试用例为什么存在、它验证的是哪条需求”。

只有双向都成立，追溯才具备变更影响分析和覆盖度审计的能力。例如，当某条软件需求被修改时，正向追溯可以找到受影响的测试用例；当某个测试用例失败时，反向追溯可以定位到它验证的需求和对应的风险控制措施。

追溯粒度：多细才算够

追溯粒度（Traceability Granularity）指追溯对象的大小和层级。粒度过粗（如“整个模块对应整个测试计划”）会失去定位能力；粒度过细（如“每一行代码对应一条需求”）则维护成本极高。医疗软件中常见的合理粒度是：需求级 → 设计单元级 → 测试用例级，并在高风险需求上适当细化到函数或分支级别。

粒度选择应遵循“风险驱动”原则：安全等级高、失效后果严重的需求，追溯粒度应更细；一般功能需求可以保持在需求—用例级别。

追溯关系类型：派生、满足、验证、依赖

追溯关系不是只有“有关联”一种，而是有明确语义的多种类型：

• 派生（Derive）：下游需求由上游需求推导而来。例如系统需求派生出软件需求，软件需求派生出详细设计约束。
• 满足（Satisfy）：设计或实现满足某条需求。例如某个类或函数满足一条软件需求。
• 验证（Verify）：测试用例或验证活动证明某条需求被满足。例如 TC-0412 验证“阻塞报警响应时间 ≤ 5 s”。
• 依赖（Depend）：需求之间或需求与外部条件之间存在依赖。例如“报警功能”依赖“电源监控功能”正常。

区分关系类型的意义在于：不同类型的边在变更影响分析中的传播规则不同。派生关系会向下传播变更，验证关系会向上反馈测试结果，依赖关系可能引入跨模块的连锁影响。

模型整合：五个概念如何协同工作

把五个概念放在一起看：追溯链是路径，追溯矩阵是路径的集合视图，双向追溯是路径必须可正反通行，追溯粒度决定路径上节点的粗细，关系类型决定路径上每条边的语义和传播规则。五者缺一不可。

在医疗软件项目中，建议先定义关系类型和粒度策略，再建立矩阵模板，最后通过工具或脚本自动生成追溯链视图。这样既能满足合规审查，也能在变更和缺陷分析中真正发挥作用。