可追溯性涉及三类用户：在需求工程中构建面向未来的架构
连接工具链，以保持发展势头，并推动整个需求工程流程的无缝集成
在本系列的第三部分中，伊恩·坎宁安将揭示，为何将可追溯性视为一种“一刀切”的做法会破坏信任并阻碍进展。
构建复杂系统是为了应对未来的挑战。当初衷逐渐淡忘、工具链脱节时，可追溯性往往会成为令人沮丧的根源，而非信心所在。我们坚信，工程需要的是清晰明确，而非凭空猜测。了解为何将可追溯性视为单一活动会失败，并学习如何设计访问机制，以尊重角色与架构交互的三种根本不同的方式。
在可追溯性方面，目前最让您感到困扰的是哪一部分：建立它、使用它，还是信任它？
在上一篇文章中，我们探讨为何为组织中的每个角色设计单一界面往往会增加复杂性，而非降低复杂性。为了进一步深入，我们需要将一种常见的假设与现实区分开来。可追溯性通常被视为一项单一活动，但实际上并非如此。它由三种本质上截然不同的交互组成。这一点至关重要，因为减少偏差的切实可行的方法是针对这三种交互进行明确的设计，而不是假设一种方法适用于所有人。
可追溯性的三大核心交互
- 需求工程师需要精确地建立和维护可追溯性链接，确保需求、模型和设计成果之间的关联在不同工具和集成环境中保持完整。
- 下游工程和验证角色需要在变更过程中评估影响范围，依靠可追溯性来了解哪些内容受到影响、哪些测试用例适用以及哪些内容尚未经过验证。
- 决策者和合规相关方需要有信心地确认意图和验证结果，并相信可追溯性能够反映跨越组织边界的正确结构和正确版本。
如果对这些交互机制缺乏清晰的理解和支持，摩擦就会加剧。偶尔使用的用户会避开该系统。数据导出量激增。追踪链接变得过时，或在海量的电子表格中丢失。需求工程师再次沦为最后的解释者，既要阐明意图，又要说明该意图是否已得到实际验证。
从更深层次来看，这本不该是必要的。工程工作不应仅仅为了做出决策，就不得不反复重建上下文。
当这三种交互得到有意识的支持时，评审将聚焦于决策和意图，而非重建上下文。覆盖范围变得清晰，验证证据也变得可靠。需求工程师将减少用于解释和辩护含义的时间，而将更多时间投入到工程实现中。其关键启示很简单：若想让系统被广泛使用并赢得信任，就必须针对每种交互设计不同的可追溯性访问方式。
至此，本系列的核心模式应已清晰。可追溯性只有在反映不同角色实际交互方式时才有效。任何解决方案都必须反映这一现实。
作为起点，这三种交互中哪一种在您当前的组织中产生了最大的阻力？
加入讨论，共同塑造系统设计的未来。在LinkedIn上关注Iain Cunningham，并在评论区分享您的经验。