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

7.1 需求工程

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

问题

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

注意：

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

起始

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

获取

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

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

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

细化

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

协商

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

规格说明

• 规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型，一组使用场景、一个原型或上述各项的任意组合。
• 规格说明往往是要写一个需求规格说明书。
• 需求规格说明书“标准模板”
  说明：
• 在开发规格说明时保持灵活性有时是必要的。
• 对大型系统而言，文档最好采用自然语言描述和图形化模型来编写。
• 而对于技术环节明确的较小产品或系统，使用场景可能就足够了。

确认

• 确认：是对需求工程的工作产品进行质量评估。
• 需求确认要检查规格说明以保证：所有的系统需求已被无歧义地说明；不一致性、疏漏和错误已被检测出并被纠正；工作产品符合为过程、项目和产品建立的标准。
• 正式技术评审是最主要的需求确认机制。确认需求的评审小组包括软件工程师、客户、用户和其他利益相关者，他们检查系统规格说明，查找内容或解释上的错误，以及可能需要进一步解释澄清的地方、丢失的信息、不一致性、冲突的需求或不现实的需求。

需求确认检查表

• 需求说明清晰吗？有没有可能造成误解？
• 需求的来源（如人员、规则、文档）弄清了吗？需求的最终说明是否已经根据或对照最初来源检查过？
• 需求是否用定量的术语界定？
• 其他哪些需求与此需求相关？是否已经使用交叉索引或其他机制清楚地加以说明了？
• 需求是否违背某个系统领域的约束？
• 需求是否可以测试？如果可以，能否说明测试检验了需求？
• 对已经创建的任何系统模型，需求是否可跟踪？
• 对整体系统/产品目标，需求是否可跟踪？
• 规格说明的构造方式是否有助于理解、引用和翻译成更技术性的工作产品？
• 对已创建的规格说明是否建立了索引？
• 和系统性能、行为及运行特征相关的需求的说明是否清楚？哪些需求是隐含出现的？

管理

• 需求变更一般会贯穿于系统的整个生存期。
• 需求管理是用于帮助项目组在项目进展中标识、控制和跟踪需求以及变更需求的一组活动。
• 需求管理从标识开始。每个需求被赋予唯一的标识符。一旦需求被标识，便开始建立跟踪表，每个跟踪表将标识的需求与系统或其环境的一个或多个方面相关联。

7.2 建立根基

• 需求工程需要做的基础工作
• 启动需求工程所必须要的步骤

1）确认利益相关者

• 利益相关者是直接或间接从正在开发的系统中获益的人。
• 容易理解的利益相关者：业务操作管理人员，产品管理人员、市场营销人员、内部和外部客户、最终用户、顾问、产品工程师、软件工程师、支持和维护工程师以及其他人员。
• 每个利益相关者对系统都有不同的考虑，当系统成功开发后所能获得的利益也不相同，失败时所面临的风险也不同。
• 在开始阶段，需求工程师应该创建一个人员列表，列出那些有助于获取到需求的人员。
• 最初的人员列表将随着接触的利益相关者人数增多而增加，因为每个利益相关者都将被询问“你认为我还应该和谁交谈？”

2）识别多重观点

• 利益相关者的视角不同，需求视角也不同。
• 当从多个角度收集信息时，所形成的需求可能存在不一致或相互矛盾。
• 需求工程师的工作就是把所有利益相关者提供的信息分类，分类方法应该便于决策制定者为系统选择一个内部一致的需求集合。

3）协同合作

• 需求工程师的工作是标识公共区域（即所有利益相关者都同意的需求）和矛盾区域或不一致区域（即某个利益相关者提出的需求和其他利益相关者的需求相矛盾）。
• 很多情况下，利益相关者的协作是提供他们各自关于需求的观点，而一个有力的“项目领导者”可能要对删减哪些需求做出最终判断。

4）首次提问
如何开始提问？可以准从以下三组问题提问法。

• 与环境无关的
• 有助于更好理解
• 关组沟通效率

第一组，与环境无关的问题，主要集中于客户和其他利益相关者，以及整体目标和收益。

例如，需求工程师可以问：

• 谁是这项工作的最初提出者？
• 谁将使用该解决方案？
• 成功的解决方案将带来什么样的经济收益？
• 对于这个解决方案你还需要其他资源吗？

这些问题有助于识别所有的利益相关者。

第二组，有助于软件开发组更好地理解问题，并允许客户表达其对解决方案的看法。

例如：

• 如何描述由某成功的解决方案产生的“良好的”输出？
• 该解决方案强调了什么问题？
• 能向我们展示（或描述）解决方案的使用环境吗？
• 存在影响解决方案的特殊性能问题或约束吗？

第三组，关注于沟通活动本身的效率。
例如：

• 你是回答这些问题的合适人选吗？你的回答是“正式的”吗？
• 我的提问和你想解决的问题相关吗？
• 我的问题是否太多了？
• 还有其他人员可以提供更多的信息吗？
• 还有我应该问的其他问题吗？

这些问题将有助于“打破坚冰”，并有助于交流的开始，而且这样的交流对需求导出至关重要。

提问一般采用会议形式进行，但是会议形式的问与答并不一定是会取得成功的好方法。

事实上，问答会议应该仅仅用于首次接触，然后就应该用问题求解、协商和规格说明等需求获取方式来取代。

7.3 需求获取

• 需求获取或称需求收集
• 需求获取将问题求解、细化、协商和规格说明等方面结合在一起。
• 需求获取的方法：

7.3.1 协作收集需求

协作收集需求的目标是标识问题，提出假设解决方案的相关元素，协商不同方法以及确定一套解决需求问题的方案。

协作需求收集方法原则：

• 会议由软件工程师和其他利益相关者共同举办和参与。
• 制定筹备和参与会议的规则。
• 建议拟定会议议程，正式到涵盖所有的要点，也不能太正式以鼓励思想的自由交流。
• 由一个“主持人”（可以是客户、开发人员或其他人）控制会议。
• 采用“方案论证手段”（工作表，电子公告牌。聊天室）

7.3.2 质量功能部署（QFD）

• QFD是一种将客户要求转化成软件技术需求的技术。
• QFD的目的是最大限度地让客户从软件工作过程中获得满意。
• QFD强调理解“什么对客户有价值”，然后再整个工程活动中部署这些价值。

QFD确认的需求分类
可以把用户关心的质量需求分三类：

• 常规需求：向客户陈述的目标。如果有这些需求，客户会满意。
• 期望需求：指没有清晰表述的基础功能，但是缺少了会引起客户不满。
• 兴奋需求：超出客户期望预期的需求，这些需求存在会令人非常兴奋。

QFD过程

• 首先，通过客户访谈和观察、调查以及检查历史数据（如问题报告）为需求收集活动获取原始数据。
• 然后，把这些数据翻译成需求表（客户意见表），并由客户评审。
• 接下来，使用各种图表、矩阵和评估方法抽取期望的需求并努力导出令人兴奋的需求。

7.3.3 使用场景

• 如果，软件团队搞不清楚不同类型最终用户如何使用系统功能和特征，那么，就很难转移到更技术化的软件工程活动。
• 此时，开发人员和用户可以创建一系列的场景。
• 场景通常称为用例，它提供了系统将如何被使用的描述。

7.3.4 获取工作产品

不同的项目导出工作产品不同，但大多数系统而言，需求获取后的工作产品包括：

• 要求和可行性陈述。
• 系统或产品范围的界限说明。
• 参与需求导出的客户、用户和其他利益相关者的列表。
• 系统技术环境的说明。
• 需求列表以及每个需求使用的领域限制。
• 一系列使用场景，有助于深入了解系统或产品在不同运行环境下的使用。
• 任何能够更好地定义需求的原型。

这些产品的每一个都需要评审

7.3.5 敏捷需求获取

• 通过向所有利益相关者提问生成用户故事，以便获取需求。
• 写到小记事卡片上，方便选择和管理。
• 用用户的语言编写，使得开发人员注意力集中到用户需求本身，而不是工作任务。
• 批评者：该方法缺少对全局商业目标和非功能需求考量

7.3.6 面向服务的方法

• 面向服务开发的需求获取关注由应用系统所定义的服务。
• 比如：您进入一家高级酒店，可享受的服务有哪些？
• 精细设计客人与酒店员工的联系和触点，就是面向服务的方法。
• 面向服务的方法强调理解客户、创造性思维、快速建立解决方案。
• 每种需求都应可以追溯到一种特定服务。

7.4 开发用例

• 用例：user case，直译：使用的例子
• 用例表述的是：最终用户如何在一特定环境下和系统交互。
• 用例表示方法：可以是叙述性的文本、任务或交互的概要、基于模板的说明或图形的表示。
• 不管形式如何，用例都是从最终用户的角度描述了软件或系统。

开发用例的第一步
第一步：定义“参与者”

• 参与者是在将要说明的功能和行为环境内使用系统或产品的各类人员（或设备）
• 参与者是任何与系统或产品通信的事物，且对系统本身而言参与者是外部的。
• 当使用系统时，每个参与者都有一个或多个目标。
• 参与者与最终用户并非一回事。
• 典型的用户可能在使用系统时扮演了许多不同的角色。
• 参与者表示了一类外部实体（经常是人员，但不限于人员），在用例中他们仅扮演一种角色。
• 例如，考虑一个机床操作员（一个用户），他和生产车间（其中布置了许多机器人和数控机床）内的某个控制计算机交互。在仔细考察需求后，控制计算机的软件需要四种不同的交互模式（角色）：编程模式、测试模式、检测模式和纠错模式。
• 4个参与者可定义为：程序员、测试员、监控员和故障检修员。
• 思考：一个教务管理系统的参与者有哪些？

开发用例

• 需求获取是一个逐步演化的活动。
• 第一次迭代，往往只能识别主要的参与者，而对系统了解更多之后，才能识别出次要的参与者。
• 主要参与者直接且经常使用软件，和他们交互可以获取所需的系统功能并导出系统的预期收益。
• 次要参与者为系统提供支持，以便主要参与者能够完成他们的工作。
• 参与者确定后，开发用例可以考虑如下问题：
  谁是主要参与者、次要参与者？
  参与者的目标是什么？
  场景开始前有什么前提条件？
  参与者完成的主要工作或功能是什么？
  按照故事所描述的还可能需要考虑什么异常？
  参与者的交互中有什么可能的变化？
  参与者必须通知系统外部环境的改变吗？
  参与者希望从系统获取什么信息？
  参与者希望得知意料之外的变更吗？

用例图

• 在细化之前，往往会首先开发出用例图
• 如下图：
  参与者
  用例
  系统边界
  以及参与者和用例直接的关联
  

7.5 构建分析模型

• 分析模型的目的是为基于计算机的系统提供必要的信息、功能和行为域的说明。
• 分析模型会随着理解的深入而动态变更。
• 需求模型演化中，某些元素将变得相对稳定，为后续设计任务提供稳固的基础。有些元素可能是不稳定的，这表明利益相关者仍然没有完全理解系统的需求。
• 后续详细介绍，下面简单概述以下。

需求模型的元素

需求模型中的元素包括：

• 基于场景的元素
• 基于类的元素
• 基于行为的元素
• 基于数据流的元素

实践中，我们可以选择上述一种进行需求建模，也可以多种结合。

基于场景的元素

• 基于场景的方法从用户的视角描述系统。
• 导出需求的过程如图所示：
  

基于类的元素

每个使用场景都暗示着当一个参与者和系统交互时所操作的一组对象，这些对象被分成类。

例如：

• 传感器Sensor类，可以用类图描述。
• 类相互之间的协作以及类之间的关联和交互等也需要描述，UML中有规范。
• 传感器Sensor的类图
  

基于行为的元素

• 系统运行起来以后，很多元素不是静态的，需求分析模型必须提供描述行为的建模元素。
• 例如：
  系统中某些对象的状态，在系统运行后会不断转换。可以使用状态图表现其变化，状态图方法可以描绘系统状态以及导致系统改变状态的事件。
• 关于行为建模，后续还有详细讨论。

基于数据流的元素

• 信息在软件系统中流动时会被转换，系统接受多种形式的输入；使用并将其转换；生成多种形式的输出。
• 早期，常用数据流图建模，而且形成了比较完善的结构化分析和设计方法。
• 随着系统庞大和复杂，该方法已经逐渐被抛弃。但在一些局部，我们还是可以采用的。

7.6 避免常见错误

实施需求工程时必须避免三种错误：

• 特性偏好：以功能覆盖率代表系统质量。软件失败的常见原因之一时缺少可使用的质量而不是丢失部分功能。解决方法：关注关键功能，必要的功能是必须交付的。
• 灵活性偏好：过分强调产品自适应性和配置便利，过分强调灵活性。灵活往往导致复杂。
• 性能偏好：过分强调性能。性能应和商业需求一致，与其他系统兼容。