软件工程--实践者的研究方法[理解需求]

7.1 需求工程

• 需求工程是指不断理解需求的大量任务和技术。
• 从软件过程的角度来看，需求工程是一个软件工程活动，始于沟通并持续到建模活动。
• 它必须适应过程、项目、产品和人员的需要。
• 理解问题的需求是软件工程师面临的最困难问题之一。

问题

• 客户难道不知道需要什么吗？
• 最终用户难道对给他们带来实际收益的特征和功能难道认识的不清楚吗？
• 客户清楚了，**能表达清楚吗？**一致吗？
• 表达清楚了，**理解清楚了吗？**一致吗？
• 需求在项目的实施过程**会改变吗？**改了怎么办？如何控制？
• 需求工程为设计和构造奠定了坚实的基础，若无需求工程，软件很可能无法满足客户的需求。
• 软件工程师和项目利益相关者都应该参与需求工程。
• 比如：在设计和开发某个一流的计算机软件时，如果软件解决的问题不对，那么即使软件再精巧也满足不了任何人的要求。因此理解客户需求很重要。
• 需求工程包括七个明确的任务：
  起始、获取、细化、协商、规格说明、确认、管理。

注意：

• 这些任务会并行发生
• 这些任务要全部适应项目的要求

起始

• 多数项目都是在确定了商业要求或发现了潜在的新市场、新服务时开始的。
• 业务领域的利益相关者定义业务用例，确定市场的宽度和深度，进行粗略的可行性分析，并确定项目范围的工作说明。
• 起始阶段的工作：软件工程师会询问一些似乎与项目无直接关系的问题。
• 目的是对问题、方案需求方、期望方案的本质、客户和开发人员之间初步的交流和合作的效果建立初步的认识。

获取

• 询问客户、用户和其他人：
  系统或产品的目标是什么？
  想要实现什么？
  系统和产品如何满足业务的要求？
  最终系统或产品如何用于日常工作？
• 获取过程中最重要的是建立商业目标
• 这些问题看似简单，但实际上导出需求却是非常困难。

为什么获取对客户需求的清晰理解非常苦难呢？

• 范围问题：系统的边界不清楚，或客户/用户的说明带有多余的技术细节，这些细节可能会混淆而不是澄清系统的整体目标。
• 理解问题：客户/用户并不完全确定需要什么，对其计算环境的能力和限制所知甚少，对问题域没有完整的认识，与系统工程师在沟通上有问题，他们会省略那些认为是“明显的”信息，确定的需求和其他客户/用户的需求相冲突，需求说明有歧义或不可测试。
• 易变问题：需求随时间变化。

细化

• 细化的核心任务是开发一个精确的需求模型，用以说明软件的功能、特征和信息的各个方面。
• 细化由一系列的用户场景建模和求精任务驱动。
• 用户场景被分解为精炼分析类。细化定义每个分析类的属性，确定每个类所需要的服务，确定类之间的关联和协作关系，并完成各种UML图作为补充。

协商

• 需求工程师必须通过协商过程来调解客户提出的过高的目标要求和相互冲突的需求。
• 可以让客户、用户和其他利益者对各自的需求排序，然后按优先级讨论冲突。
• 使用迭代，评估成本和分析，处理冲突，删除，组合或修改需求，以便相关各方均能达到一定的满意度。

规格说明