需求可追溯性：你本周可以使用的现场检查清单
需求可追溯性是将每个需求从其来源（业务需求、利益相关者请求、法规义务）追踪到设计决策、实施选择和测试活动的能力，以确认它已在交付的系统或产品中被正确处理。在资本和技术项目中，需求可追溯性差是范围蔓延、测试缺口和验收争议的主要原因。需求可追溯性矩阵（RTM）是管理可追溯性的主要工具。
检查清单第一部分：建立可追溯性
为每个需求唯一编号。 未唯一编号的需求无法追踪。在构建RTM之前为每个需求分配一个唯一标识符。简单的编号方案（REQ-001，REQ-002）优于创建管理开销的有意义但复杂的方案。
按类型对需求分类。 区分功能性需求（系统或产品必须做什么）、非功能性需求（必须做得多好——性能、可靠性、安全性）和法规或合规需求。不同需求类型可能有不同的可追溯性义务。
记录每个需求的来源。 对于每个需求，记录它来自哪里——哪个利益相关者要求了它、哪个监管文件要求了它，或它支持哪个业务流程。没有记录来源的需求通常是镀金（由团队添加而没有真正的业务需求），如果压力需要可以安全地减少范围。
检查清单第二部分：在设计和构建过程中维护可追溯性
将每个需求链接到处理它的设计元素。 对于每个需求，记录哪个设计元素（架构组件、模块、接口、数据库表）负责处理它。如果需求没有链接到任何设计元素，它就没有被设计——这意味着它没有被构建。
将每个设计元素链接到其测试用例。 对于每个设计元素，记录哪些测试用例将验证它是否已被正确实施。如果设计元素没有测试用例，就没有方法知道它是否有效。
需求变更时更新RTM。 需求变更必须通过RTM追踪：哪些设计元素受影响？哪些测试用例需要更新或添加？未追踪的需求变更是测试缺口和回归错误的常见原因。
检查清单第三部分：在评审和验收中使用RTM
在每次设计评审时，使用RTM确认每个需求至少有一个分配的设计元素。没有设计覆盖的需求是应该升级的风险。
在测试开始时，使用RTM确认每个需求至少有一个测试用例。如果存在覆盖缺口，在测试开始之前——而非之后——写缺失的测试用例。
在验收时，使用RTM生成可追溯性覆盖率报告：多少百分比的需求已经测试，多少百分比的测试通过。在所有强制性需求有通过测试结果之前，不应授予验收。
XNM为公共部门及资本项目客户提供项目管理和需求管理顾问服务。欢迎联系XNM项目群与项目交付咨询团队，探讨贵项目的需求可追溯性和范围管理。