- 如果用户必须有多种方式访问特定功能以提高可用性，那么与仅需要一种访问机制相比，这将需要更多的开发工作。
- 强加的设计和实施约束（例如多个外部接口以实现与现有操作环境的兼容性）可能会导致大量的接口工作，即使您没有提供额外的新产品功能。
- 严格的性能要求可能需要大量的算法和数据库设计工作来优化响应时间。
- 严格的可用性和可靠性要求可能意味着需要大量工作来构建故障转移和数据恢复机制，并且会对您选择的系统架构产生影响。
- 建议（有人建议）
- 已批准（已分配给基线）
- 已实施（代码已设计、编写并进行单元测试）
- 已验证（需求在集成到产品后通过了测试）
- 已推迟（需求将在未来的版本中实施）
- 已删除（您决定根本不实施它）
- 已拒绝（想法从未被批准）
- 在给定的时间段内提交了多少变更请求？
- 这些请求中有多少是开放的，有多少是关闭的？
- 有多少请求被批准，有多少被拒绝？
- 团队在实施每项批准的变更方面花费了多少精力？
- 这些请求平均开放了多长时间？
- 平均而言，每个提交的变更请求影响了多少个单独的需求或其他工件？
Jama Software 已与 Karl Wiegers 合作，分享其书籍和文章中的授权内容。Karl Wiegers 是独立顾问，不是 Jama Software 的员工。您可以通过 ProcessImpact.com 联系他。
在本章中，我们讨论了准确衡量需求，以及为什么有纪律的组织会收集有关所有项目的一组重点指标。
这些指标可以深入了解产品的大小；项目或单个任务所消耗的精力、时间和金钱；项目状态；以及产品的质量。由于需求是项目的重要组成部分，因此您应该衡量需求工程活动的几个方面。在本章中，改编自 Karl Wiegers 的书《更多关于软件需求》，我们介绍了几个与项目需求活动相关的有意义的指标。
产品规模
最基本的指标是工作内容中的需求数量。您的项目可能使用用例、功能需求、用户故事、功能描述、事件响应表和分析模型的组合来表示需求。但是，团队最终会实现功能需求，即系统在特定条件下应如何运行的描述。
通过简单地计算分配给给定产品版本或开发迭代基线的各个功能需求来开始您的需求测量。如果不同的团队成员无法计算需求并得到相同的答案，您不得不怀疑他们会遇到哪些其他类型的歧义和误解。了解发布中有多少需求将有助于您判断团队的完成进度，因为您可以监控剩余的工作积压。如果您不知道需要处理多少需求，您怎么知道什么时候完成？
当然，并非所有功能需求都会消耗相同的实施和测试工作量。如果您要将功能需求作为系统规模的指标，您的分析师将需要以一致的粒度编写它们。一个指导原则是分解高级需求，直到所有子需求都可以单独测试。也就是说，测试人员可以设计一些逻辑相关的测试来验证需求是否正确实现。计算子需求的总数，因为这些是开发人员将实现和测试人员将测试的内容。替代需求规模估算技术包括用例点和故事点。所有这些方法都涉及估计实现定义的功能块所需的相对工作量。
当然，功能需求并不是全部。严格的非功能性需求可能会消耗大量的设计和实施工作量。一些功能来自指定的非功能性需求，例如安全需求，因此这些功能将适当地纳入功能需求规模估算中。但并非所有非功能性需求都会反映在此规模估算中。请务必考虑非功能性需求对您的工作量估算的影响。考虑以下情况：
您还会发现，无论您使用什么需求规模指标，跟踪需求随时间的增长都是有益的。我的一位客户发现，他们的项目在交付前通常会增长约 25%。令人惊讶的是，他们的大多数项目也比计划的进度超出了约 25%。巧合吗？我想不是。
需求质量
考虑收集一些有关需求质量的数据。需求规范检查是此类信息的良好来源。统计您发现的需求缺陷，并将它们分为不同的类别：缺失需求、错误需求、不必要的需求、不完整、模糊等等。使用缺陷类型频率和根本原因分析来调整您的需求流程，以便团队将来减少此类错误。例如，如果您发现缺失需求是一个常见问题，则您的引出方法需要进行一些调整。也许您的业务分析师没有提出足够多的问题或正确的问题，或者您可能需要让更合适的用户代表参与需求开发过程。
如果团队成员认为他们没有时间检查所有需求文档，请尝试检查仅几页的样本。然后计算样本的平均缺陷密度（即每页规范中发现的缺陷数量）。假设样本代表整个文档（一个很大的假设），您可以将未检查的页面数乘以此缺陷密度，以估计仍可能潜伏在规范中的未发现缺陷数量。经验不足的检查员可能只会发现实际存在的缺陷的一半，因此请使用未发现缺陷的估计数量作为下限。检查抽样可以让您评估文档的质量，以便您可以确定检查其余需求规范是否具有成本效益。答案几乎肯定是肯定的。
此外，记录在需求确定基线后发现的需求缺陷，例如在设计、编码和测试期间发现的需求相关问题。这些代表在需求开发期间通过质量控制过滤器泄漏的错误。计算团队在需求阶段发现的需求错误总数的百分比。尽早消除需求缺陷比在团队已经设计、编码和测试错误需求后纠正它们要便宜得多。
从检查数据计算的两个有用指标是效率和有效性。效率是指在检查工作中，每个工时发现的缺陷的平均数量。有效性是指工作产品中原来存在的缺陷中，通过检查发现的缺陷的百分比。有效性将告诉您检查（或其他需求质量技术）的效果如何。效率将告诉您通过检查发现缺陷的平均成本。您可以将该成本与处理项目后期或交付后发现的需求缺陷的成本进行比较，以判断提高需求质量是否具有成本效益。
本系列的第二篇文章将讨论与需求状态、变更请求以及需求开发和管理活动所花费的努力相关的指标。
需求状态
跟踪每个需求的状态以监控整个项目的状态，也许可以定义一个需求属性来存储此信息。状态跟踪可以帮助您避免软件项目跟踪中普遍存在的“完成百分之九十”问题。每个需求在任何时候都会具有以下状态之一。
当然，其他状态选项也是可能的。一些组织使用“已审阅”状态，因为他们希望在将需求分配给基线之前确认需求质量很高。其他组织使用“已交付给客户”来表示需求实际上已经发布。
当你问开发人员进展如何时，他可能会说：“分配给这个子系统的 87 个需求中，61 个已经验证，9 个已经实现但尚未验证，17 个尚未完全实现。” 很有可能并非所有这些需求都大小相同，需要的实现工作量也不同，或者提供的客户价值也不同。但是，如果我是项目经理，我会觉得我们很好地掌握了该子系统的规模以及距离完成还有多远。这比“我完成了大约 90%。看起来不错！”更有参考价值。
变更请求
需求管理的大部分工作涉及处理需求的添加、修改和删除。因此，请跟踪需求变更请求的状态和影响。您收集的数据应该可以让您的团队回答以下问题：
在确定特定版本的需求基线后，监控整个开发过程中纳入了多少变更。请注意，单个变更请求可能会影响不同级别和类型的多个需求（用户需求、功能需求、非功能需求）。要计算给定时间段内的需求波动，请将变更数量除以该时间段开始时（例如，在定义基线时）的需求总数：
目的不是试图消除需求波动。变更需求通常有充分的理由。但是，我们需要确保项目可以管理需求变更的程度并仍然履行其承诺。随着产品接近完成，变更的成本会更高，而持续的高水平批准变更请求会让您很难知道何时可以发货产品。随着开发的进展，大多数项目应该会更抵制进行变更，这意味着当您接近给定版本的计划完成日期时，接受变更的趋势应该接近于零。迭代开发方法为团队提供了多次将变更纳入后续迭代的机会，同时仍使每个迭代都按计划进行。
如果您收到许多变更请求，则表明诱导过程中忽略了许多需求，或者随着项目逐月拖延，新想法不断涌现。记录变更请求的来源：营销、用户、销售、管理、开发人员等。变更请求的来源将告诉您应该与谁合作以减少被忽略、修改和误解的需求数量。
长期未解决的变更请求表明您的变更管理流程运行不佳。我曾经访问过一家公司，那里的一位经理讽刺地承认，他们有几年前的增强请求，但仍在等待处理。该团队应将一定数量的未决请求分配给特定的计划维护版本，并将其他长期推迟的变更请求转换为已拒绝状态。这将有助于项目经理将团队的精力集中在变更积压中最重要和最紧急的项目上。
努力
最后，我们建议您记录团队在需求工程活动上花费的时间。这些活动包括需求开发（获取和编写良好的需求）和需求管理（处理变更、跟踪状态、记录可追溯性数据等）。
我经常被问到项目应该为这些功能分配多少时间和精力。答案在很大程度上取决于项目的类型和规模、开发团队和组织以及应用领域。如果您跟踪自己团队在这些关键项目活动上的投资，您可以更好地估计为未来项目规划多少工作量。
假设在之前的一个项目中，您的团队将 10% 的工作量花在需求活动上。回想起来，您得出结论，需求定义得太差，如果在开发质量需求方面投入更多资金，项目将受益匪浅。下次您的团队处理类似项目时，项目经理最好将总项目工作的 10% 以上分配给需求工作。
在积累数据时，将项目开发工作量与某种产品规模指标关联起来。记录的需求应该可以让你了解规模。你可以将工作量与单独可测试的需求、用例点、功能点或其他与产品规模成比例的东西的数量联系起来。如图 1 所示，这种关联可以衡量你的开发团队的生产力，这将有助于你估计和确定单个发布内容的范围。如果你收集一些产品规模数据并跟踪相应的实施工作量，你将能够更好地为将来的类似项目创建有意义的估计。
图 1. 将需求大小与项目工作量关联起来，可以衡量团队的生产力。每个点代表一个单独的项目。
有些人担心启动软件测量工作会耗费太多时间，他们认为这些时间应该花在做“真正的工作”上。但我的经验是，一个合理而有针对性的度量程序根本不需要花费太多时间或精力。这主要是开发一个简单的基础设施来收集和分析数据，并让团队成员养成记录一些关于他们工作的关键数据的习惯。一旦你在组织中建立了一种测量文化，你会惊讶地发现你可以从数据中学到很多东西。
