需求工程

需求工程的概述

Alan Davis 把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动”

Herb 定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理

Matthias Jarke和Klaus Pohl提出了三阶段周期的说法：获取、表示和验证

需求获取

系统分析人员通过与用户的交流、对现有系统的观察及对任务进行分析，确定:

1. 系统或产品范围的限制性描述
2. 与系统或产品有关的人员
3. 特征列表
4. 系统的技术环境的描述
5. 系统功能的列表及应用于每个需求的领域限制
6. 描述不同运行条件下系统或产品使用状况的应用场景
7. 为更好地定义需求而开发的任意原型

需求获取的工作产品为进行需求分析提供了基础

需求分析与协商

需求分析

1. 对需求进行分类组织
2. 分析每个需求之间的关系
3. 检查需求的一致性、重叠和遗漏的情况
4. 并根据用户的需要对需求进行排序

需求协商

在需求获取阶段，经常出现以下问题：

1. 用户提出的要求超出软件系统可以实现的范围或实现能力
2. 不同的用户提出了相互冲突的需求

系统建模

建模工具在用户和系统分析人员之间建立了统一的语言和理解的桥梁.

系统分析人员借助建模技术，对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图。

常用的分析和建模方法有:

• 面向数据流方法
• 面向数据结构方法
• 面向对象的方法

需求规约

需求规约是分析任务的最终产物，通过建立完整的数据和信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。

需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用。

需求验证

作为需求开发阶段工作的复查手段，需求验证对功能的正确性、完整性和清晰性，以及其它需求给予评价。

为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。

需求分析过程

在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求开发活动不会是线性地、顺序地完成。实际上，这些活动是交叉的、递增的和反复的。

访谈与调查

• 在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活性。
• 一般按照如下原则进行准备：
  1. 所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化；
  2. 不要限制用户对问题的回答，这有可能会引出原先没有注意的问题
  3. 提问和回答在汇总后应能够反映用户需求的全貌

观察用户操作流程

到用户的实际工作环境中（系统实施前的用况）:

• 对用户的工作流程进行观察
• 了解用户实际的操作环境、操作过程和操作要求
• 对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识

组成联合小组

采用便利的应用规约技术(Facilitated Application Specification Techniques , FAST) ：

• 打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组
• 发挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势并增进解和协调

FAST基本原则：

1. 在中立的地点举行由开发者和用户出席的会议
2. 建立准备和参与会议的规则
3. 建议一个足够正式的议程以便可以进行自由的交流
4. 一个“协调者”(他可以是用户、开发者或其他外人)来控制会议
5. 使用一种“定义机制”(它可以是工作表、图表、墙上胶黏纸或墙板)
6. 目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的需求

FAST会议步骤：

1. 确定一个FAST会议的时间地点，并在会议日之前将产品请求发布给所有的与会者
2. 要求每个FAST 出席者，会前列出一组围绕系统环境、对象的操作、对象之间的交互功能，并列出约束列表(如，成本、规模大小、权重)和性能标准列表(如，速度、精度)。这些列表可以不是穷尽的，但是，希望每套列表反映的是每个人对系统的感觉。
3. 进行FAST 会议时，当团队的每个成员提出单个列表后，整个团队将创建一个组合的列表，该组合列表删去冗余项，并加入在表达过程中出现的新思想。在建好所有主题的组合列表后，开始讨论活动。缩短、加长或重新组合列表以适当地反映将被开发的产品
4. 一旦创建了意见一致的列表，应该将团队分为更小的小组，每个小组力图为每个列表中的一个或多个项开发出小型的规约（即对包含在列表中的单词或短语的精细化）。每个小组然后将他们开发的每个小规约提交给所有的FAST 出席者讨论，进行添加、删除或进一步的精化等工作。
   在所有讨论过程中，团队可能提出某些不能在会议过程中解决的问题，此时要保留问题列表以使这些思想在以后的活动中产生作用。
5. 在小规约完成后，每个FAST 小组提出一个针对产品的确切标准列表，并将该列表提交给团队，然后创建一个意见一致的确定的标准列表。这个列表作为需求获取的结果，为需求分析和建模提供基础信息。

用况（Use Case）

当需求收集起来后，分析员就可以创建一组标识串，构造系统的使用场景。

创建用况模型的主要步骤如下：

1. 确定谁会直接使用该系统，即参与者（Actor）
2. 选取其中一个参与者
3. 定义该参与者希望系统做什么，参与者希望系统作的每件事将成为一个用况
4. 对每件事来说，何时参与者会使用系统，通常会发生什么，这就是用况的基本过程
5. 描述该用况的基本过程

就是说找个人在某时在这个系统做些什么，回发生什么事

需求分析、协商和建模

需求分析原则

1. 必须能够表示和理解问题的信息域
2. 必须能够定义软件将完成的功能
3. 必须能够表示软件的行为(作为外部事件的结果)
4. 必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节
5. 分析过程应该从要素信息移向细节信息

信息域

信息域：包括信息内容、信息流、以及信息结构。

信息内容表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成。例如，数据对象“工资”是一组重要数据体的组合：领款人的姓名、净付款数、付款总额、扣除额等等

信息流表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息(数据和/或控制)，然后进一步被变换为输出（理解为接口）

信息结构表示了各种数据和控制项的内部组织形式：数据或控制项将被组织为n维表还是树形结构构的语境内，什么信息是和其他信息相关的包含在单个结构中，还是使用不同的结构信息结构中的信息如何和在另一个结构中的信息相关p>

抽象、分解与多视点分析

问题抽象方法要求分析人员在分析过程中捕捉用户描述或问题本身固有的一般-特殊关系

首先关注一般问题的解决途径，进而指导特殊问题的解决方法。

问题分解的目的是要能以层次化的方式对问题进行分解和不断细化。

1. 较大规模或较为复杂的问题可以被分解为若干子问题进行理解和分析
2. 分解可以逐级进行，直至子问题被分解为一个容易分析理解的部分

需求验证

需求验证目的是要检验需求是否能够反映用户的意愿

需要检查以下内容:

1. 系统定义的目标是否与用户的要求一致；
2. 系统需求阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求；
3. 被开发项目的数据流与数据结构是否确定且充足；
4. 主要功能是否已包括在规定的软件范围之内，是否都已充分说明；
5. 约束条件或限制条件是否符合实际；
6. 开发的技术风险是什么；
7. 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认。

需求管理

需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动

需求跟踪有两种方式，正向跟踪与逆向跟踪

正向跟踪：以用户需求为切入点，检查《需求规约》中的每个需求是否都能在后继工作产品中找到对应点

逆向跟踪：检查设计文档、代码、测试用况等工作产品是否都能在《需求规约》中找到出处