- 与产品负责人协商承诺。
- 举办获取研讨会并进行访谈。
- 审查现有文档和产品。
- 准备、分发和分析调查。
- 创建和评估原型、分析模型和其他需求视图。
- 执行可行性、风险、安全性、故障和危害分析。
- 将需求信息输入数据库。
- 审查需求规范。
- 根据需求开发测试用例并遍历测试用例。
- 在审查或测试分析之后修订需求规范。
业务分析师和经理有时会问，下一个项目“满足需求”需要多长时间。
与软件和产品开发中的许多问题一样，这个问题的正确答案是“视情况而定”。
多个变量导致了这个问题。已发布的各种行业平均值表明，典型项目工作量中应有多少比例用于需求开发，其中包括需求收集（也称为需求引出）等活动。
但是，来自不同基准的数据不一致，这些“典型”项目是否与您自己的项目相似值得怀疑。在这篇文章中，根据我的书《更多关于软件需求》改编，我将提供一些建议，告诉您如何确定在需求收集等方面投入的适当时间和精力。
行业基准
以下是基准可能有用也可能没用的例子。表 1（见下文）列出了一些行业基准数据，这些数据包括几个不同类别的项目用于需求获取和原型设计的平均总工作量百分比和平均计划时间（数据来自 Capers Jones 的“软件评估、基准和最佳实践”）。这些基准适用于规模为 10,000 个功能点（约 100 万行代码）的大型项目。您的项目与这些基准有多相似？
表 1. 大型项目需求工作基准
使用此类行业基准还有另一个问题。数据无法表明这些项目有多成功，也无法定义每个项目的“成功”意味着什么。这些数据也无法表明更成功的项目团队是否比不太成功的团队投入了更多精力进行需求获取活动——它们只是实际绩效的平均值。
虽然典型的项目团队可能只将 10% 或更少的精力投入到需求收集等方面，但只要团队不陷入分析瘫痪，投入更多精力将带来巨大回报。与许多人的看法相反，花更多精力改进需求开发流程实际上可以加速开发。
当我在柯达公司工作时，从事一些小型项目时，我的团队通常会将总工作量的 15% 到 18% 投入到需求活动上。我们发现，这种投入减少了交付后的返工量。很难确定原因和结果，但我相信维护水平低的最大因素是我们培养的广泛用户参与。
我无法告诉您下一个项目需要花多长时间收集需求。但是，图 1 列出了一些可以加速需求流程的条件，以及延长开发有效需求所需时间的其他几个因素。
图 1. 影响需求开发所需时间的因素。
您自己的经验
首先，最好的办法是收集一些数据，了解您自己的项目在需求收集上花费了多少精力。这将帮助您判断您的需求开发流程在过去的效果如何。在估计未来项目所需的需求工作量时，请使用这些历史数据。使用图 1 中的考虑因素调整您的初始估计，以补偿您的下一个项目与基准项目之间的差异。考虑任何会影响您自己项目的其他因素。您可以将图 1 中显示的每个因素按 0（无影响）到 5（主要影响）的等级加权。此分析可以帮助您发现可能延长需求开发工作的风险因素。
另一个需要考虑的因素是项目所遵循的开发生命周期。并非所有的需求获取工作都应分配给项目的早期阶段，就像顺序或瀑布生命周期中的情况一样（图 2 中的虚线）。不要以离散的“需求阶段”来思考，而要考虑一组跨越项目生命周期的需求相关活动。具体来说，一旦出现系统需求规范 (SRS) 的一组需求基线并且开始出现变更请求，就会持续执行需求管理。
图 2. 遵循不同开发生命周期的项目随时间的需求工作量分布会有所不同
代和增量方法
遵循敏捷开发方法（如 Scrum）的项目采用增量方法，快速构建产品的一小部分。这样可以快速将潜在有用的功能交到用户手中，以便用户可以改进其需求，开发人员可以跟上不断变化的业务需求。敏捷项目将有频繁但较小的需求收集工作（图 2 中的实线）。
与传统项目不同，敏捷项目的需求工作是前端加载的，而是贯穿整个项目。初始需求探索会导致各种优先级的预期功能积压。当将特定特性或功能分配给特定迭代时，团队将细化该功能的需求，使其达到所需的详细程度，以使开发和测试能够自信地进行。
多年前，我的软件开发小组的一个成功项目就采用了这种增量方法。该项目每三周向内部企业用户社区发布一次有用的功能。每个三周周期的第一部分都用于项目规划、开发和收集该增量的需求。团队针对该增量进行了足够的需求开发，快速实施，并逐个向用户提供新功能。用户对这些增量提供了反馈，这有助于引导项目的其余部分实现最大价值。
并非所有项目都适合这种细粒度的增量交付。例如，在重新设计现有应用程序时，新系统需要大量的功能，然后用户才能切换到它。无论您的团队在每个项目周期中处理的增量有多大，他们都需要了解该增量的需求，以避免大量重新设计、代码和测试。
规划需求获取
与项目的许多方面一样，需求收集比最初看到的要复杂得多。在确定分析师可能需要执行的任务时，请考虑是否需要进行以下活动：
您的团队可能不会在每个项目上执行所有这些活动，他们可能必须执行其他任务作为需求引出、分析、规范和验证的一部分。您了解分析师实际执行的任务以及这些任务需要多长时间，这将提高您估计未来项目所需的需求开发工作量的能力。
Jama Software 已与 Karl Wiegers 合作，分享其书籍和文章中的授权内容。Karl Wiegers 是一名独立顾问，不是 Jama 的员工。您可以通过 ProcessImpact.com 与他联系。
