3. 需求追踪的基本原理
需求追踪不是把需求编号抄到测试用例旁边，而是要在“需求—设计—实现—测试—验证结果”之间建立可判定、可查询、可维护的关联关系。航天器研制中，一条需求往往要经过分系统分解、单机实现、软件配置项实现、总装测试和环境试验等多个环节，如果没有统一的追踪关系定义，后续的覆盖分析就会退化为人工比对，既无法证明完整性，也无法定位变更影响。本节围绕四个基本问题展开：追踪关系是什么、追踪到什么粒度、沿什么方向追踪、如何用追踪矩阵承载这些关系。
一、追踪关系的定义：三类基本关系
在工程实践中，需求追踪关系至少包含三类：派生关系、满足关系和验证关系。派生关系描述“上级需求被分解为哪些下级需求”，例如整星级“在轨自主安全模式切换时间不大于30 s”可派生为姿轨控分系统的模式判定需求、星务软件的模式切换指令需求、电源分系统的供电保持需求。满足关系描述“哪一项设计、单机或软件配置项实现了该需求”，例如某需求由“星务软件CSCI-03的模式管理模块”满足。验证关系描述“哪一项测试用例、分析、检查或演示验证了该需求”，例如“TC-AOC-021 安全模式切换时序测试”验证该需求。
三类关系必须区分开，不能混为一张“关联表”。派生关系回答“需求从哪来、到哪去”，满足关系回答“谁实现”，验证关系回答“谁证明”。只有三者同时存在，才能形成从需求到验证结果的闭环。若某条需求只有验证关系而没有满足关系，说明验证对象不明确；若只有满足关系而没有验证关系，说明该需求尚未被验证覆盖。
二、追踪粒度：从型号级到测试用例级
追踪粒度决定追踪矩阵的行列规模和信息密度。粒度过粗，一条需求对应整个分系统，无法判断具体覆盖情况；粒度过细，一条需求拆成几十条子需求，维护成本急剧上升。航天器测试中常用的粒度层级为：型号级需求 → 分系统级需求 → 单机/软件配置项级需求 → 测试项目 → 测试用例 → 测试步骤/判据。
选择粒度的基本原则是“可独立验证”。如果一条需求可以独立设计一个测试用例并给出明确通过判据，就应作为追踪矩阵中的一行；如果它必须与其它需求合并才能验证，则应合并为一条可验证需求，或拆分为若干条可独立验证的子需求。例如“星务软件应具备遥控指令校验功能”过于笼统，可拆为“对上行遥控帧进行CRC校验”“校验失败时丢弃并计数”“计数超过阈值时告警”三条，每条都能独立构造测试用例。
粒度还影响变更影响分析。当某条单机级需求变更时，追踪矩阵应能立即查出受影响的测试用例、验证状态和已执行结果。若粒度只到分系统级，变更影响只能靠人工判断，容易遗漏。
三、追踪方向：正向、反向与双向
追踪方向决定我们“从哪一端出发查什么”。正向追踪从需求出发，沿派生、满足、验证关系向下游查找，回答“这条需求是否被实现、是否被验证”。反向追踪从测试用例或验证结果出发，向上游查找，回答“这个测试为什么存在、它验证了哪条需求”。双向追踪是两者的组合，也是覆盖分析和变更影响分析的基础。
在航天器测试需求追踪中，正向追踪用于编制测试覆盖矩阵，检查每条需求是否至少有一个验证方法；反向追踪用于审查测试用例是否存在“无需求来源”的冗余用例，以及测试失败时快速定位受影响的需求。双向追踪则用于变更控制：当某条需求变更时，正向查受影响的设计和测试，反向查该需求的上游来源，判断变更是否向上传播。
四、追踪矩阵：承载关系的核心工具
追踪矩阵是追踪关系的表格化表达。典型的需求追踪矩阵以需求为行，以设计对象、测试用例、验证结果、验证方法、当前状态为列。每一行至少应包含：需求标识、需求描述摘要、上级需求标识、满足对象标识、验证用例标识、验证方法（测试/分析/检查/演示）、验证状态（未验证/通过/失败/待复测）、备注。矩阵的列可以根据项目阶段扩展，例如增加“变更影响标记”“覆盖缺口说明”。
下面给出一个可直接参考的追踪矩阵片段示例，数据为教学假设，不代表真实型号数据：
| 需求标识 | 需求摘要 | 上级需求 | 满足对象 | 验证用例 | 验证方法 | 状态 |
|---|---|---|---|---|---|---|
| RQ-SYS-005 | 安全模式切换≤30 s | — | — | — | — | 已派生 |
| RQ-AOC-018 | 模式判定与切换指令 | RQ-SYS-005 | CSCI-03 | TC-AOC-021 | 测试 | 通过 |
| RQ-SW-042 | 切换指令输出时序 | RQ-AOC-018 | CSCI-03 | TC-SW-014 | 测试 | 待复测 |
| RQ-PWR-009 | 切换期间供电保持 | RQ-SYS-005 | PCDU-02 | AN-PWR-006 | 分析 | 通过 |
使用追踪矩阵时，重点检查三类缺口：无验证用例的需求行（覆盖缺口）、无需求来源的测试用例列（冗余或遗漏需求）、验证状态长期为“待复测”的行（闭环未完成）。在航天器测试中，覆盖分析通常要求每条需求至少有一种验证方法，关键需求还需交叉验证。若某条需求只有分析验证而无测试验证，应在矩阵备注中说明理由，并由总体或分系统设计师确认。
五、从关系定义到覆盖判断
把追踪关系、粒度、方向和矩阵串起来，覆盖判断就有了明确依据。以“安全模式切换≤30 s”为例：正向追踪确认该需求已派生到姿轨控、星务、电源三条下级需求；反向追踪确认TC-AOC-021、TC-SW-014、AN-PWR-006三个验证项均有明确需求来源；矩阵中三条下级需求均至少有一个验证用例，且状态为“通过”或“待复测”。此时可判定该需求族在当前基线下的验证覆盖是完整的，但“待复测”项仍需在下一轮测试中关闭。若某条下级需求在矩阵中验证用例为空，则覆盖不完整，必须补充测试用例或说明采用其它验证方式的理由。
追踪矩阵不是一次性文档，而是随研制阶段滚动维护的活数据。需求追踪的基本原理，归根结底是让每一条需求都能回答三个问题：我从哪里来、由谁实现、被谁验证。回答清楚这三个问题，覆盖分析才有可核查的证据链。