4. 需求追踪矩阵的构建方法

需求追踪矩阵（Requirements Traceability Matrix，RTM）是航空软件研制过程中连接需求、设计、代码与测试的核心工件。在 DO-178C 的语境下，它不仅是管理文档，更是适航审查中证明"每条需求都被实现且被验证"的关键证据。本节围绕矩阵结构、需求标识规则、追踪链接类型、工具支持以及手工与自动追踪的对比展开，帮助读者建立一套可落地、可审查的追踪体系。

一、矩阵结构：从二维表到多维关系网

最基础的 RTM 是一张二维表：行代表需求，列代表生命周期工件（设计项、源代码单元、测试用例、测试结果）。单元格内填写对应工件的标识符，形成"需求—工件"的映射。但在航空软件中，单一二维表往往不够，因为一条高层需求可能派生出多条低层需求，一条低层需求又可能被多个测试用例覆盖。因此实际工程中常采用"分层矩阵 + 交叉引用"的结构：

• 纵向分层：系统需求 → 高层软件需求 → 低层软件需求 → 源代码 → 目标码，每层之间建立派生关系。
• 横向覆盖：每条需求对应设计描述、测试用例、测试规程、测试结果，形成验证闭环。
• 双向可追溯：既能从需求向下查到测试，也能从测试结果反查需求，便于变更影响分析。

矩阵的粒度需要与项目规模匹配。对于机载软件，通常以"可验证的最小需求单元"为行，避免一条需求包含多个独立可测点，否则追踪会失去意义。

二、需求标识规则：唯一、稳定、可解析

需求标识是追踪的"主键"，必须全局唯一且长期稳定。推荐采用分段编码，例如：

SRS-FCS-0012
│    │    └─ 序号（4位，从0001起）
│    └────── 子系统代码（FCS=飞行控制系统）
└─────────── 文档类型（SRS=软件需求规格说明）

规则要点包括：标识一经分配不得复用，需求删除后其标识作废；派生需求在父标识后追加层级码，如 SRS-FCS-0012-D01；测试用例采用独立前缀，如 TC-FCS-0012-01，便于与需求对应。标识中避免使用空格、中文和特殊符号，确保在 DOORS、Polarion 等工具中可被正则表达式解析。

三、追踪链接类型：派生、满足、验证、依赖

追踪链接不是简单的"关联"，而是带有语义的有向边。常见类型如下：

在工具中，这些链接类型通常以 Link Module 或 Traceability Type 的形式定义，并设置方向性和可追溯性规则。例如，DOORS 允许为链接模块定义"源对象类型—目标对象类型"的合法组合，防止出现"测试用例派生需求"这类语义错误。

四、工具支持：DOORS 与 Polarion 的典型用法

IBM DOORS 采用模块化对象管理，每个需求是一个 Object，链接通过 Link Module 建立。构建 RTM 时，通常先创建需求模块和测试模块，再建立链接模块，最后用 Analysis Wizard 生成矩阵视图。DOORS 的优势在于成熟的基线管理和变更影响分析，适合大型机载项目。

Polarion 基于 Web 和 OSLC 标准，需求、测试用例、缺陷统一在工作项模型中管理。它支持实时追踪和覆盖率仪表盘，链接类型可通过工作项类型配置。Polarion 更适合与敏捷流程结合，但在复杂派生关系的可视化上不如 DOORS 直观。

五、手工与自动追踪对比

手工追踪依赖工程师在表格或工具中逐条建立链接，优点是灵活、可处理语义模糊的关系；缺点是工作量大、易遗漏、变更后维护成本高。自动追踪则通过标识匹配、自然语言处理或代码注解扫描来生成候选链接，再由人工确认。自动追踪能显著提升覆盖率统计效率，但对命名规范和工具链集成要求高。

实际项目中常采用混合策略：对结构化程度高的需求—测试映射使用自动生成，对派生和依赖关系保留人工确认。下图展示了从需求标识到追踪链接、再到工具落地的整体关系。

构建 RTM 时，建议先冻结需求标识规则，再在工具中建立链接类型模板，最后批量导入或自动生成候选链接。每次需求变更后，应重新运行覆盖率检查，确认没有出现"孤儿需求"（无测试覆盖）或"孤儿测试"（无需求对应）。只有矩阵保持双向完整，才能在适航审查中快速给出每条需求的实现与验证证据。