需求可追溯性与影响分析
§1摘要与结论
以需求库为中枢，把需求条目、属性与上下游制品（干系人需求、系统需求、设计、测试、代码）建立可查询的追踪关系，并以结构化查询支持变更影响分析的需求管理平台化落地。
别名：Requirements Traceability、需求追溯矩阵、Traceability Matrix、需求管理平台、影响分析 | 英文：Requirements Traceability and Impact Analysis | 类型：技术 / tooling
§2局部关系图
§3原理 · 为什么
需求的长期价值在于可追踪、可评估影响，而不在于文档是否写全。ISO/IEC/IEEE 29148:2018 把需求工程规定为一组过程并定义各阶段信息项，要求需求之间以及需求与其它生命周期制品之间建立可追溯关系：从干系人需求到系统[软件]需求，再到设计、测试与代码，形成双向链路。当需求以唯一标识的条目进入活的库而非冻结的文档，追溯便从一次性台账变成持续可查询的关系网络。它使变更影响分析成为可能——一条需求变化时，系统能回答它由谁提出、派生自哪条上游需求、被哪些设计与测试覆盖、影响哪些制品——也为覆盖度核查与合规举证提供结构化依据，把需求集的一致性与完整性从评审者记忆转移到可验证的数据上。对需求密集、合规要求高的系统，这种结构化关系还是评审与验收的事实基础：评审者可以核查每条需求是否有来源、是否被实现与验证，而不是凭文档是否齐全下判断。它把「需求之间彼此关联、需求驱动制品」这一假设显式化，使遗漏与冲突在早期暴露。
§4机制 · 如何运作
技术实现由三部分构成。其一是需求库与唯一标识：每条需求携属性（优先级、依据、假定难度、状态、来源干系人），可被稳定引用。其二是显式追踪关系：以受控动词定义链接类型（派生、满足、验证、实现、冲突），把需求横向（彼此依赖）与纵向（上下游制品）连接，并据此生成可视图与覆盖度报告。其三是影响分析查询：沿追踪图正向与反向遍历，计算某条需求变更所触及的设计、测试与代码集合，识别未被任何测试覆盖或无上游依据的孤立需求。ISO 29148 的 traceable 特性与各信息项格式为这套关系提供了标准落点；工具把链路维护、覆盖率统计与影响查询自动化，减少人工台账的维护成本与遗漏。
§5工程 · 怎么落地
落地通常以需求管理或 ALM 平台承载，并与版本控制、issue 跟踪、测试管理贯通，使需求状态能随实现与测试结果回填。工程要点是克制：只建立对决策有用的链路类型，避免为追求完整而把一切关系都显式化，否则矩阵迅速膨胀成无人维护的负担；用门控规则强制关键链路（如每条系统需求必须可追溯到上游干系人需求、每条高优先级需求必须有测试覆盖），而非要求全部人工填报。应把追踪关系与实际工作流绑定——提交变更时由系统提示受影响需求与测试——而不是要求团队额外维护一张与工作脱节的关系表。变更控制应复用追踪图：变更请求关联受影响需求集，评审据影响范围决定取舍。需披露立场：本节点两条行业来源 VEN-013（Modern Requirements，需求管理工具厂商）与 VEN-012（Possession Planning，从业者站点）均为厂商/二手来源，其需求特性清单与 ISO 正文存在措辞差异，引用时须以标准条款为准。
§6权衡卡
链路随时间腐化：代码与测试演进后旧链接失效却无人清理，覆盖度报告给出虚假的安全感；链接粒度过细会制造海量低价值关系，粒度过粗则无法支撑影响分析。
因此应聚焦少数高价值链路、让追踪随工作流自动生成、定期清理失效链接，并接受覆盖度是启发信号而非精确结论。
可追溯性有明确的维护成本，且容易追求形式完整而失去价值。
工具化还引入厂商锁定：需求库格式与追溯模型常与特定平台绑定，迁移成本高，选择时须评估导出与互操作能力。
此外，过度依赖工具会把需求关系误当成沟通本身，纸面链路替代不了干系人对齐。
需要警惕的是，链路齐备但语义错误的关联同样会误导影响分析，关键链路仍须人工复核；判断投入是否值得的标准是它是否真的降低了变更时的排查成本，而非矩阵是否看起来完整。
- 把追溯当作合规仪式、只在审计前突击补齐，是典型失效模式——矩阵齐全但无人据此决策。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7案例带
OpenSpec 规约驱动解析
对比规约驱动开发工具链 OpenSpec 与 Superpower 的元模型、工件依赖 DAG 与安全门控，提炼「规约先于实现」工程形态的解析案例。
去中心化聊天架构逆向
对一个仅有 58 份设计文档、尚未实现的开源去中心化聊天项目做架构逆向：从设计文本提炼 18 个模块及其依赖关系，重建模块依赖 DAG 与三条核心数据流 DAG，并输出全景理解与深度需求分析。
插件 DAG RC5→RC7 升级
一次知识库随上游源码版本升级的级联维护：以三层差异分析把 219 个包收敛为 26 个实质变更包，经编译、运行时、组合三类依赖判定更新 DAG 数据后全量重生成页面，并以静态门控加渲染验证收口。
插件 DAG 两次级联升级
在同一知识库上继续两轮上游级联升级：处理数百次提交与包的增删，暴露「依赖声明不等于运行时引用」、分层须按最长路径深度、纯外部依赖边不得入主图等差分陷阱，并以全量门控校验收口。
技术知识中枢交付法
从模糊需求到上线，把 AI Agent 驱动的端到端交付固化为四阶段加双共识加迭代的可迁移方法论的实战提炼案例。
§8信源与核验
核验结论：追溯是需求条目之间及其与设计/测试/代码之间的可查询关系网络；矩阵只是其一种视图，只有当关系随工作流维护、可支撑影响分析与覆盖度核查时才产生价值 [VEN-012]
核验结论：厂商与从业者站点（如 VEN-013/VEN-012）在标准特性上加入了 implementation-free、traceable 等条目或调整归类，与 ISO §5.2.5/§5.2.6 的表述存在差异，应以标准条款为准 [VEN-013]
§9原始关系清单
展开：本节点的全部原始关系边（4 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 案例印证 | ← CAS-X-14 | OpenSpec 规约驱动解析 E-18 | 印证：requires 工件 DAG 建立需求到实现可追溯链 |
| 组合 | → TEC-F-02 | 需求技术债识别与度量 E-930 | 追溯链路为需求债度量提供覆盖缺口 |
| 实现 | → MTH-F-04 | 需求规格说明 E-926 | 追溯与影响分析落地需求规格说明 |
| 实现 | → MTH-F-06 | 需求属性与优先级 E-927 | 需求属性与追踪关系在平台中落地 |