对于系统工程师、业务分析师和产品负责人来说，需求可追溯性（即能够将需求追溯到下游开发、测试、验证、确认和风险活动的能力）是毫无疑问的优点和需求。在诸如医疗设备、汽车、半导体、航空航天和金融服务等行业，追溯性是为了证明其符合相关行业标准的必要条件。除了合规性要求外，追溯性也有助于评估对所有相关需求以及相关下游活动产生影响的更改的效果。然而，许多组织并未充分利用追溯性带来的最大潜在价值。
一、事后可追溯性
上述两个主要的需求追溯性用例都是对请求的反应：需要向第三方证明符合标准的合规性，以及需要分析变更请求的影响。这两个用例都将需求视为静态和被动的。需求被记录下来，并在软件、硬件、电气开发测试和风险评估中与下游的工件创建链接，这些链接然后存储在一个系统中。这个系统然后等待外部请求的进来，以证明已经遵循了一种过程，或者确定哪些元素可能受到变更的影响。这两个用例都体现了一种事后的思维方式，限制了通过建立需求追溯性所能达到的价值。
二、与其他业务关键功能的类比
想要从新的视角来看待我们认为自己已经非常了解的东西，通常会找到一种不同的上下文并从新的视角去审视它，这种方法往往很有帮助。因此，让我们尝试一下，将产品开发过程中的追溯性与新客户获取过程中的追溯性进行对比。
对工程师来说，这两个过程最初可能看起来相差很远，不适合进行类比，但从根本上来看，它们其实是非常类似的。它们都从记录下的价值（需求与机会）开始，然后必须经过多个阶段，涉及到许多其他的功能，才能达到期望的结果（发布产品或者赢得业务）——在此过程中可能会出现各种问题，导致延迟、增加成本甚至失败。
我想重点关注的是这两个过程是如何管理的。在销售过程中，价值的元素（即商机）是活跃的——每天都在积极测量、分析，并追踪异常情况。关键的过程度量被定义为可接受的性能范围。根据所有商机通过各个阶段的移动情况，系统会自动计算当前的过程性能。对于停留在某个阶段过长（相比平均驻留时间）的商机，系统会发出警报，并根据系统中的商机预测未来一段时间的性能。
相比之下，对于大多数产品开发组织来说，需求追溯性是静态的，处于事后分析状态，并不像销售中追踪商机那样活跃。要让需求追溯性活跃起来（就像销售商机一样），追溯性需要在以下领域应用软件支持的最佳实践：
- 必须定义过程指标
- 必须捕捉到对过程指标的实际表现
- 一旦定义了标准的指标性能，就必须将当前的表现与标准进行比较
- 需要定义例外情况
- 需要设置警报，以在出现例外情况时发出通知
- 需要将学习成果融入到过程改进中
一旦采取这些步骤来提高需求追溯性，那么需求就会变得活动，而不是静态，而且性能的改善就有可能实现：减少负面产品结果的风险，提高过程性能；产品开发过程可以像所有其他关键业务过程一样，被数据驱动、测量和管理。没有测量，就无法对其他组织的性能进行基准测试。没有学习的方法，没有知识，也没有改进的方法。
您还在停滞不前吗？
可能有些人更愿意让产品开发过程保持神秘，避免数据驱动的分析、测量和过程性能改进。过去也有一些首席收入官（CRO）有同样的想法。现在很难找到任何有这种心态的现任CRO。那些能够通过数据领导并驱动性能改进的人会得到领导的支持，从而提升他们的职业生涯。现在，产品领导的同样机会在桌面上，将需求追溯性转变为活动需求，以减少负面产品结果的风险，并提高端到端产品开发过程的性能。
