如何用 AI 构建需求可追溯性矩阵？先冻结基线再做双向追踪

要用 AI 构建需求可追溯性矩阵，先冻结已批准的需求基线，分配唯一 ID，并规定矩阵允许哪些关系。只有 AI 能引用支持文字并指明出处时，才让它提出候选关系；再由需求、设计、实现、测试、安全和合规负责人确认每条关系和结果。

需求可追溯性矩阵（RTM）是证据基础设施，不是项目结束时一次性生成的表格。它应支持正向追踪（从每条获批需求追到设计、实现、验证和证据）和反向追踪（从实现和测试追回获授权的需求）。AI 能减少文书工作，但不得编造需求、映射、测试结果、豁免或合规结论。

进度和依赖另用一份项目计划管理。更全面的 AI 使用总指南说明如何限制模型权限，人类审批工作流则可把批准绑定到有版本的矩阵导出文件。

关键要点：

• 从已批准、有唯一标识、有版本的需求开始。
• 每条关系都要明确，并有引用的证据支持。
• 把 AI 输出视为候选映射，绝不当作已接受的事实。
• 同时追踪正向覆盖和反向授权。
• 区分计划中的验证与已执行、已复核的证据。
• 需求或下游产物变化时，随时维护矩阵。

步骤 1：冻结基线和唯一 ID

确定权威来源：已批准的规格、合同、政策、架构决策、监管解读或受控待办列表。记录基线版本、批准机构、日期、范围和变更控制流程。保存只读副本，便于日后复核区分“需求变了”和“映射变了”。

为每条需求分配唯一、稳定的 ID，不用排序后会变的行号。记录确切文本、出处位置、理由、负责人、已批准的优先级或关键程度及当前生命周期状态。

NASA 的需求管理指南描述了在整个生命周期中建立、控制、验证、确认和追踪需求。［1］ 这一视角很重要：RTM 必须反映受控变更，而非最新收集的一堆句子。

把需求与背景说明、目标、设计想法、假设和示例分开。AI 可以指出某句像需求，但只有获授权的需求流程能接受它。未批准的候选放进收件队列，不要悄悄分配需求 ID。

步骤 2：检查原子性与可验证性

映射前，检查每条需求是否只含一项有边界的义务，主体明确、条件清楚、结果可验证。多个“并且”连起的复合陈述可能需要经批准的拆分。保留父子关系和原文；不要让 AI 改写合同或受监管措辞，好像改写版才是权威。

提出以下问题：

• 执行者或系统边界是否清楚？
• 所要求的行为或质量是否可观察？
• 触发条件和例外是否有定义？
• 单位、阈值和容差是否无歧义？
• 是否有验证方法能判定通过或失败？
• 是否与另一条已批准需求冲突或重复？

NASA 的需求确认指南着重在下游依赖之前，确保需求格式规范、清晰、完整、一致、可行且可验证。［3］ 缺陷记录后交需求负责人，不要只在矩阵里修补。

步骤 3：定义字段和状态

提取之前先选定字段。一个有用的模板是：

需求 ID	来源	需求文本	理由	负责人	状态	设计	实现	测试/证据	结果	版本
REQ-001	SPEC-3.2	准确获批原文	获批理由	产品负责人	已入基线	DES-014	MOD-07	TP-031 / EV-031	已复核通过	2.1

示例只说明格式。定义允许的取值，如 candidate、reviewed、approved、implemented、verified、deferred 和 retired，并写明谁可以设置每个值。避免笼统的“完成”：一条需求可能已实现但未验证，或已测试但未通过。

用稳定的产物 ID 加版本表示链接，而非非正式描述。设计文档或测试变化时，矩阵应能看出之前的复核是否仍适用。写明确切的证据位置（章节、测试用例、结果记录或受控 URL），让其他复核人能打开。

步骤 4：用 AI 构建需求可追溯性矩阵时只提取候选关系

只提供已批准或已清楚标注的产物、术语表、字段结构和关系规则。把大型来源集拆成可复核的批次，同时保留产物 ID 和版本元数据。

一条受控的提示词是：

为每条已批准需求提出与所提供产物之间的候选关系。返回需求 ID、目标产物 ID 和版本、关系类型、带位置的确切支持引文，以及简短理由。只使用所提供的文本。如果支持含糊或缺失，返回 UNRESOLVED。不要创建需求 ID、产物、测试结果、状态、豁免或合规主张。

要求模型为拟议链接两端都给出引用。只靠关键词重叠不够：提到“timeout”的测试未必验证了所要求的超时行为。由复核人检查目标是否真正实现或验证了这项义务及其条件。

按获批工具、访问、保留和数据存放位置的规定，保护敏感规格和安全设计。尽量减少提供的材料。NIST 的生成式 AI 风险概况指出了虚构、隐私、信息安全和信息完整性等需要治理和人工监督的风险。［4］

步骤 5：处理歧义、重复和孤立项

分小批复核候选映射。每条链接选择接受、拒绝、需澄清或需负责人处理，并记录复核人、日期、理由和矩阵版本。绝不把模型的置信度分数当作批准。

特别留意：

• 没有设计、实现、测试或证据的需求；
• 一个测试链接到多条需求，却没有证明每个条件；
• ID 不同的重复需求；
• 相互冲突的需求或版本；
• 超出或违背已批准范围的实现；
• 测试了没有任何需求授权的行为；
• 只基于相似字眼的链接；
• 从计划中照抄、而非来自执行记录的结果。

孤立项是复核信号，不自动证明失败。新纳入基线的需求可能正在等待设计；反过来，没有对应需求的实现，可能是必要基础设施、缺陷修复、未成文的需求或未经授权的范围。交负责人处理。

矩阵引用外部标准或主张时，使用事实核查流程的控制方法。AI 对标准的总结，不能代替已批准的解读。

步骤 6：建立正向追踪

正向追踪要问：每条已批准需求是否都有合适的下游实现和验证。沿着这条链走：

1. 需求到架构或设计决策；
2. 设计到实现组件或配置；
3. 需求到验证方法和测试规程；
4. 规程到执行记录和证据；
5. 证据到已复核的结果和处置。

别忽略“规程”与“结果”的区别。测试用例 ID 只证明测试已计划；“通过”需要对应正确版本和环境的执行结果，并按项目流程复核。

检查、分析、演示或认证等非测试验证，要明确记录方法和证据。链接到文件夹通常太宽泛，应指明能证明该需求的产物和章节。

NASA 的双向追踪指南强调，要把软件测试规程追踪到需求，也要把需求追踪到测试规程，并在整个生命周期中维护这些关系。［2］ 具体产物因项目而异，但两个方向都应可复核。

步骤 7：执行反向追踪

从设计、已实现组件、配置、测试规程和证据出发，逐一追问：哪条已批准需求授权或要求了这项产物？这能暴露镀金功能、过时测试、未成文的行为和意外的范围扩张。

AI 可以把未链接的产物分组并建议可能的负责人，但不得为了给它们找理由而创建需求。把每项归类为：

• 已链接并确认；
• 有文档理由的共享基础设施；
• 关联到已批准问题或需求的缺陷修复；
• 等待批准的候选新需求；
• 已过时或超出范围；
• 未解决。

请架构和实现负责人复核反向追踪，因需求作者未必了解每个下游产物。对于安全攸关、信息安全、受监管或合同约束的工作，使用项目批准的追踪工具和领域专属的复核流程；本教程不能代替它们。

步骤 8：在变更时维护矩阵

为每条需求以及作为受控产物的矩阵本身指定负责人。定义复核触发条件：基线变更、设计修订、代码变更、测试变更、测试失败、豁免、发布候选或审计请求。

发生变化时：

1. 记录变更请求和批准；
2. 创建产物的新版本；
3. 找出受影响的关系；
4. 酌情把之前的复核标为需重新评估；
5. 重新执行正向和反向检查；
6. 收集新证据；
7. 批准并导出一份带日期的矩阵快照。

自动化工具能标出过期链接、缺失字段、重复 ID 或无效状态，但不能判定变化后的证据仍然充分；这个决定由具名复核人作出。

把维护流程整理成 SOP 与清单，包括访问控制、备份、复核频率和导出格式。避免出现与受控矩阵逐渐分歧的私人副本。

除检查完整性外，还要人工抽查：挑几条高关键度需求、几条看似简单的需求和几项最近变更的产物，不依赖矩阵创建者重建每条链。抽查能暴露看似精确却指向错误版本的链接，或未测试所需条件的证据。把样本、复核人、发现和纠正措施随矩阵版本记录。

批准检查清单

在发布或正式评审之前，确认：

• 已标明基线及所含版本；
• 所有需求 ID 唯一且已批准；
• 每条已接受的链接都有目标 ID 和复核证据；
• 所有需求都有适当的正向处置；
• 反向追踪没有发现无法解释的实现或测试范围；
• 计划中的测试没有被表述为已通过的结果；
• 失败、推迟、豁免和未解决的项目仍然可见；
• 敏感产物受到保护；
• 专家复核人已批准必需的安全或合规解读；
• 导出文件和批准记录指向同一个矩阵版本。

常见问题

什么是需求可追溯性矩阵？

它是已批准需求与相关设计、实现、验证、证据、结果、负责人和版本间的受控映射。

AI 可以编写需求吗？

它可以找出像需求的候选文字，但只有获授权的流程才能创建或批准需求。把候选放在已接受的基线之外。

什么是双向追踪？

正向追踪检查需求是否已被实现和验证；反向追踪检查设计、实现和测试是否有已批准需求或有记录的理由支持。

一项测试可以覆盖多条需求吗？

可以，前提是复核人确认该规程和证据验证了每个关联条件；不要凭共同用词推断覆盖。

链接测试计划就够了吗？

不够。计划只表明打算验证，还要另外记录执行结果、环境和版本、证据位置及已复核的处置。

多久更新一次 RTM？

需求或关联产物变化时，以及在规定评审关口时更新。只在审计前刷新的追踪很可能已过时。

孤立需求怎么办？

指定负责人并定处置：需设计、需测试、推迟、废止、重复、无效或未解决。不要隐藏它，也不要让 AI 编造链接。

RTM 能证明监管合规吗？

不能单独证明。它能整理已批准的义务和证据，但是否合规由合资格的专家和适用的保证流程判定。

来源

1. NASA, Requirements Management — https://www.nasa.gov/reference/6-2-requirements-management/
2. NASA Software Engineering Handbook, Bidirectional Traceability Between Software Test Procedures and Software Requirements — https://swehb.nasa.gov/spaces/7150/pages/16449898/SWE-072%2B-%2BBidirectional%2BTraceability%2BBetween%2BSoftware%2BTest%2BProcedures%2Band%2BSoftware%2BRequirements
3. NASA Software Engineering Handbook, Requirements Validation — https://swehb.nasa.gov/spaces/SWEHBVD/pages/102695440/SWE-055%2B-%2BRequirements%2BValidation
4. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 8 月 29 日。

延伸阅读

• 将现场检查问题关联到证据与要求
• 将确认的需求整理成网站结构