- 建议（有人建议）
- 已批准（已分配给基线）
- 已实施（代码已设计、编写并进行了单元测试）
- 已验证（需求在集成到产品后通过了测试）
- 已推迟（需求将在未来的版本中实施）
- 已删除（您决定根本不实施它）
- 已拒绝（这个想法从未被批准）
- 在给定的时间段内提交了多少变更请求？
- 这些请求中有多少是开放的，有多少是关闭的？
- 有多少请求被批准，有多少被拒绝？
- 团队在实施每项批准的变更方面花费了多少精力？
- 这些请求平均开放了多长时间？
- 平均而言，每个提交的变更请求影响了多少个单独的需求或其他工件？
本文继续探讨与需求相关的方法
需求状态
在本章中，我们将详细介绍在状态请求更改中处理需求添加、修改和删除。
跟踪每个需求随时间的状态以监控整体项目状态，也许可以定义一个需求属性来存储此信息。状态跟踪可以帮助您避免软件项目跟踪中普遍存在的“完成百分之九十”问题。每个需求在任何时候都会具有以下状态之一。
当然，其他状态选项也是可能的。一些组织使用“已审阅”状态，因为他们希望在将需求分配给基线之前确认需求是高质量的。其他组织使用“已交付给客户”来表示需求已实际发布。
当您询问开发人员进展如何时，他可能会说：“分配给此子系统的 87 个需求中，有 61 个已验证，9 个已实施但尚未验证，17 个尚未完全实施。” 很有可能并非所有这些需求都大小相同，消耗的实施工作量也不同，或者提供的客户价值也不同。但是，如果我是项目经理，我会觉得我们很好地掌握了该子系统的规模以及距离完成还有多远。这比“我完成了大约 90%。看起来不错！”更有参考价值！
变更请求
需求管理的大部分工作涉及处理需求的添加、修改和删除。因此，请跟踪需求变更请求的状态和影响。您收集的数据应该可以让您的团队回答以下问题：
在确定特定版本的需求基线后，监控整个开发过程中纳入了多少变更。请注意，单个变更请求可能会影响不同级别和类型的多个需求（用户需求、功能需求、非功能需求）。要计算给定时间段内的需求波动，请将变更数量除以该时间段开始时（例如，在定义基线时）的需求总数：
目的不是试图消除需求波动。变更需求通常有充分的理由。但是，我们需要确保项目可以管理需求变更的程度并仍然履行其承诺。随着产品接近完成，变更的成本会更高，而持续的高水平批准变更请求会让您很难知道何时可以发货产品。随着开发的进展，大多数项目应该会更抵制进行变更，这意味着当您接近给定版本的计划完成日期时，接受变更的趋势应该接近于零。迭代开发方法为团队提供了多次将变更纳入后续迭代的机会，同时仍使每个迭代都按计划进行。
如果您收到许多变更请求，则表明诱导过程中忽略了许多需求，或者随着项目逐月拖延，新想法不断涌现。记录变更请求的来源：营销、用户、销售、管理、开发人员等。变更请求的来源将告诉您应该与谁合作以减少被忽略、修改和误解的需求数量。
长期未解决的变更请求表明您的变更管理流程运行不佳。我曾经访问过一家公司，那里的一位经理讽刺地承认，他们有几年前的增强请求，但仍在等待处理。该团队应将某些未解决的请求分配给特定的计划维护版本，并将其他长期推迟的变更请求转换为已拒绝状态。这将有助于项目经理将团队的精力集中在变更积压中最重要和最紧急的项目上。
努力
最后，我建议您记录团队在需求工程活动上花费的时间。这些活动包括需求开发（获取和编写良好的需求）和需求管理（处理变更、跟踪状态、记录可追溯性数据等）。
我经常被问到项目应该为这些功能分配多少时间和精力。答案在很大程度上取决于项目的类型和规模、开发团队和组织以及应用领域。如果您跟踪自己团队在这些关键项目活动上的投资，您可以更好地估计为未来项目规划多少工作量。
假设在之前的一个项目中，您的团队将 10% 的工作量花在需求活动上。回想起来，您得出结论，需求定义得太差，如果在开发质量需求方面投入更多资金，项目将受益匪浅。下次您的团队处理类似项目时，项目经理最好将总项目工作的 10% 以上分配给需求工作。
在积累数据时，将项目开发工作量与某种产品规模指标关联起来。记录的需求应该可以让你了解规模。你可以将工作量与单独可测试的需求、用例点、功能点或其他与产品规模成比例的东西的数量相关联。如图 1 所示，这种关联可以衡量你的开发团队的生产力，这将有助于你估计和确定单个发布内容的范围。如果你收集一些产品规模数据并跟踪相应的实施工作量，你将能够更好地为将来的类似项目创建有意义的估计。
有些人担心启动软件测量工作会耗费太多时间，他们认为这些时间应该花在做“真正的工作”上。但我的经验是，一个合理而有针对性的度量程序根本不需要太多的时间或精力。这主要是开发一个简单的基础设施来收集和分析数据，并让团队成员养成记录一些关于他们工作的关键数据的习惯。一旦你在组织中形成了测量文化，你会惊讶地发现你可以从数据中学到多少东西。
