人们对需求术语的困惑甚至延伸到整个学科的称谓上。有些作者将整个范围都称为“需求工程”。有些人统称为“需求管理”。还有些人认为这些活动属于广义上的业务分析的一个分支。我们发现，最好将需求工程分为需求开发和需求管理，如图所示。不管项目遵循什么样的开发生命周期-纯瀑布法、分阶段开发方法、迭代开发、增量开发、敏捷方法或者混合各种开发方式--这些需求工作都要完成。根据项目生命周期，在项目的不同阶段实施这些活动，只不过深度或广度有所差异。
需求开发
所示,我们将需求开发细分为:获取、分析、规范说明和验证(Abranet al.2004)。这些细分囊括的活动涉及产品需求的开发、评估、记录和确认。下面介绍每个细分中的一些基本活动。
获取
需求获取涵盖需求发现的所有活动，例如访谈、研讨会、文档分析、原型等。主要活动如下所示。
识别产品的预期客户群和其他干系人。理解客户任务、目标以及与这些任务相关的业务目标。了解新产品的应用环境。与每一类客户群的代表一起工作,理解他们对功能有哪些需要以及对质量有怎样的预期。
以用途为核心还是以产品为核心?
虽然有多种策略可用，但我们在进行需求获取活动时，通常采取以用途为核心或者以产品为核心的方法。以用途为核心的策略强调的是对用户目标的理解和探求，以便提取必要的系统功能。以产品为核心的方法侧重于特性，目的是领先市场或者业务取得成功。以产品为中心的策略，其风险在于开发人员辛辛苦苦实现的特性并没有得到很高的利用，虽然它们当时看似都是奇思妙想。我们建议先理解业务目标和用户目标，然后根据自己得出的见解来确定合适的产品特性和特征。
分析
分析需求涉及深入并准确理解每个需求,然后将各个需求以不同的方式表达出来。下面是一些基本活动。
- 分析来自用户的信息，将其任务目标与功能需求、质量预期、业务规则、建议解决方案和其他信息区别开。
- 将概要需求进行适当的细分。
- 从其他需求信息中引出功能需求。
- 理解质量属性的相对重要性。
- 将需求分配给系统架构所定义的软件组件。
- 协商需求实现的优先级别。
找出需求中的遗漏的或多余的、不必要的需求，以便定义范围。
规范说明
需求规范说明以一种连贯并结构清晰的方式来表达和存储收集到的需求知识。主要活动如下。
将收集到的用户需求转换为书面形式的需求和图表，供目标读者理解、检查和使用。
验证
需求验证是指确认需求信息是正确的，能使开发人员制定出能满足业务目标的解决方案。其中心活动如下所示。
- 检查记录下来的需求，在交给开发团队认可之前解决所有问题。
- 开发验收测试和标准，保证产品的开发是建立在需求基础之上的，能够满足客户需要并达成业务目标。
迭代是成功需求开发的关键。规划出多周期的需求探究活动，我们要逐步优化概要需求，使其进一步准确和细化，并与用户共同确认得出正确的需求。这可能是费力不讨好的活儿。但如果想解决新软件系统的不确定性，这个工作就是不可避免的。
重点提示
获得“完美的”需求完全是痴心妄想。从实际角度来看，需求开发的目标是大家对“足够好”的需求达成共识后，着手产品开发的下一步一不管是整个产品的1%还是100%一而风险在可控范围之内。主要风险在于不得不进行大量未经计划的返工，因为团队在开始设计和开发前，没有充分理解下一个工作模块的需求。
需求管理
需求管理活动如下所示。
- 及时确定需求基线，提交一个供当前时间段使用的参考，提出一套大家商定的、经过评审和批准的功能需求与非功能需求，通常针对具体的产品发布或者开发迭代。
- 评估提议需求变更可能产生的影响,然后以可控方式将获准的变更融入项目。
- 随着需求的演化，保持项目计划与需求同步。
- 根据预估的需求变更可能带来的影响，商定新的承诺。
- 定义各个需求之间存在的关系和依赖。
- 跟踪每个需求到它们各自对应的设计、源代码和测试。
- 在整个项目过程中跟踪需求状态和变更活动。
需求管理的目标不是抑制变更或加大其难度，而是为了预测和协调不可避免且实际存在的变更，最终最小化变更对项目的破坏性影响。图从另外一个视角为我们阐明需求开发与需求管理之间的区别。
