需求工程

1. 软件需求

1.1 概念

1. 软件需求：指 用户对系统 在功能、行为、性能、设计约束等方面的 期望。

1.2 软件需求的层次

1. 业务需求：
   1. 整体全局视角，反映 企业 或 客户 对系统高层次的目标要求
   2. 通常来自 项目投资人、客户、市场营销部门 或 产品策划部门
   3. 通过业务需求可以确定 项目视图 和 范围。
2. 用户需求：
   1. 用户视角，描述用户的具体目标，或用户要求系统必须能完成的任务
   2. 通常采取 用户访谈 和 问卷调查 等方式，对用户使用的场景进行整理，从而建立用户需求。

业务需求和用户需求构成了 用户原始需求文档 的内容。

3. 功能需求（系统需求）：
   1. 系统的角度，说明软件的需求
   2. 包括：
      1. 功能需求：也称为行为需求，规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要
      2. 非功能需求：指系统必须具备的属性或品质，又可以细分为软件质量属性（如可维护性、可靠性、效率等）和其他非功能需求
      3. 设计约束：也称为限制条件或补充规约，通常是对系统的一些约束说明（如必须采用国有自主知识产权的数据库系统，必须运行在 UNIX 操作系统之下等）

2. 需求工程

2.1 概念

1. 需求工程：指应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述待开发系统及其行为特征和相关约束。

2.2 活动阶段

1. 需求获取：指通过与用户的交流、对现有系统的观察以及对任务进行分析，识别和收集与软件系统相关的各种需求
2. 需求分析：在需求获取的基础上，为最终用户所看到的系统建立一个 概念模型，作为对需求的抽象描述，并尽可能多地捕获现实世界的语义。
3. 需求文档化：形成需求规格，生成需求模型构件的精确的、形式化的描述，作为用户和开发者之间的一个 协约（Contract）
4. 需求确认与验证：以需求规格说明为输入，通过评审、原型演示或符号执行等途径，分析需求规格的正确性和可行性
5. 需求管理：支持系统的需求演进，对 需求基线 进行管理，确保需求在整个软件生命周期中得到有效的控制和维护

2.3 需求陈述的特性

1. 完整性、正确性：需求必须完整、准确地描述待开发功能
2. 可行性：需求必须在系统及其运行环境的能力与约束范围内可实现
3. 必要性：需求必须源自用户的真实需要，而不是多余或无关功能
4. 优先级区分：需求应按重要性和紧迫性分配优先级，而不是全部视为同等重要，否则会影响资源分配和开发顺序

3. 需求获取

3.1 概念

1. 一个确定和理解 不同的项目干系人的需求和约束的过程。
2. 获得系统必要的特征，或者是获得用户能接受的、系统必须满足的约束
3. 目的：理解利益相关者对系统的真实需求，并将这些需求清晰地记录下来
4. 需求获取（需求抽取）通常为一个 迭代过程，其中的活动包括：
   1. 需求发现
   2. 需求分类和组织
   3. 需求协商
   4. 需求文档化

3.2 步骤

1. 开发高层的业务模型
2. 定义项目范围和高层需求
3. 识别用户角色和用户代表
4. 获取具体的需求
5. 确定目标系统的业务工作流
6. 需求整理与总结

3.3 方法

1. 用户访谈：1 对 1~3，有 代表性的用户
   1. 成本高，需要领域知识支撑
   2. 其形式包括 结构化 和 非结构化 两种
2. 问卷调查：用户多，无法一一访谈，成本低
3. 现场观察：针对较为 复杂的流程 和操作
4. 采样：从种群中系统地选出 有代表性的样本集 的过程
   1. 样本数量 = $0.25*(可信度因子 / 错误率)^2$
5. 情节串联板：一系列图片，通过这些图片来讲故事
6. 联合需求计划（JRP）：通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求
   1. 高度组织的群体会议，各方参与，了解想法，消除分歧
   2. 避免专业化的语言，交互好，成本高
7. 原型化方法：通过 简易系统 方式，解决早期需求不确定问题
8. 头脑风暴法：一群人围绕新业务，发散思维，不断产生新的观点
9. 需求记录技术：任务卡片、场景说明、用户故事、Volere 白卡

4. 需求分析

4.1 概念

一个好的需求应该具有 无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性 等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。

4.2 核心任务

1. 建模：建立系统的逻辑模型（如数据流图、实体关系图、状态转换图等）
2. 梳理：分析需求之间的关系、优先级和约束条件，识别并消除模糊、冲突或不一致的部分
3. 转化：将用户的原始业务需求转化为计算机化的系统需求

4.3 主要方法

1. 结构化分析（SA）
2. 面向对象分析（OOA）

4.4 结构化的需求分析

1. 结构化特点：自顶向下，逐步分解，面向数据。
2. 结构化的需求分析的三大模型：
   1. 功能模型（数据流图 DFD）：包括 外部实体、加工、数据存储、数据流。
   2. 行为模型（状态转换图）：
      1. 描述：描绘系统的状态及引起系统状态转换的事件，刻画系统在不同事件下的动态行为。
      2. 核心要素：包含 状态（初态、终态、中间状态）、事件（触发转换的控制信息）和动作。
   3. 数据模型（E-R图）：描述系统中数据的静态结构，即 实体、属性 以及 实体之间的联系。
   4. 数据字典（DD）：描述了系统的分解，为数据流图中的每个数据流、文件、加工，以及组成数据流或文件的数据项做出说明。
      1. 包含四类条目：数据流、数据项、数据存储 和 基本加工。
      2. 加工逻辑也称为 “小说明”。
      3. 常用的加工逻辑描述方法有：结构化语言、判定表 和 判定树 3种。
         

5. 需求定义与验证

5.1 软件需求规格说明书 SRS

1. 概念：是 需求开发活动 的产物，编制该文档的目的是使 项目干系人 与 开发团队 对 系统的初始规定 有一个共同的理解，使之成为整个开发工作的基础。
2. 作用： SRS 是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。

5.2 需求定义方法

1. 严格定义（预先定义）：需求的严格定义建立在以下的基本假设之上：
   1. 所有需求都能够被预先定义
   2. 开发人员与用户之间能够准确而清晰地交流
   3. 采用图形（或文字）可以充分体现最终系统
2. 原型方法：迭代的循环型开发方式。需要注意的问题：
   1. 并非所有的需求都能在系统开发前被准确地说明
   2. 项目干系人之间通常都存在交流上的困难，原型提供了克该服困难的一个手段
   3. 特点：需要实际的、可供用户参与 的系统模型。有合适的系统开发环境。反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。

5.3 需求验证

1. 概念：也称为需求确认，目的是与用户一起确认需求无误，对需求规格说明书 SRS 进行评审和测试。
2. 两个步骤：
   1. 需求评审：正式评审和非正式评审
   2. 需求测试：设计概念测试用例
3. 需求验证通过后，要请用户签字确认，作为验收标准之一，此时，这个需求规格说明书就是需求基线，不可以再随意更新，如果需要更改必须走需求变更流程。

6. 需求管理

6.1 概念

1. 是一个对系统 需求变更、了解和控制 的过程，是对 需求基线 进行管理。
2. 对需求文档有三个过程：
   1. 变更控制：确保对需求的变更是一个非常严格的过程，需要有严格的审批记录和跟踪。防止需求乱变
   2. 版本控制：需要记录不同时间的 需求版本 变化
   3. 需求跟踪：从提出需求到实现，到测试，以及客户反馈，都需要一个过程
3. 需求基线：
   1. 通过了评审的 需求说明书 就是需求基线。
   2. 软件需求开发的最终文档经过评审标准后，则定义了开发工作的 需求基线。这个基线在客户和开发者之间构筑了计划产品功能需求和非功能需求的一个 需求约定，是需求开发和需求管理之间的桥梁。
   3. 基准：指对产品需求保持一个共识。

6.2 主要活动

1. 变更控制：建立控制点和批准变更的机制，评估变更带来的影响，确保需求基线的任何改动都经过审批
2. 版本控制：记录需求文档的演变历史，管理需求基线在不同时间点的版本，确保项目各方使用正确的文档版本
3. 需求跟踪：建立需求与其他系统元素（如设计、代码、测试用例）之间的双向追溯关系，确保需求被完整实现且无遗漏
4. 需求状态跟踪：定义并记录需求在生命周期中的当前状态（如已建议、已批准、已实现、已验证），掌握需求的执行进度

6.3 变更产生的原因

1. 外部环境的变化
2. 需求和设计做的不够完整
3. 新技术的出现
4. 公司机构重组造成业务流程的变化

7. 需求变更管理

7.1 需求变更管理的过程

1. 问题分析与变更描述
2. 变更分析和成本计算
3. 变更实现

7.2 变更控制委员会（CCB，Change Control Board）

1. 概念：
   1. 也称为 配置控制委员会，是 决策机构，是需求变更管理中的关键组成部分
   2. 负责决定哪些需求变更或新产品特性应当应用，哪些错误应当纠正，并且确定变更实施的版本
   3. 广义上，CCB 对项目中 任何 基线工作产品的变更都可以做出决策
   4. 在需求变更中，变更审批 由 CCB 负责审批
2. 成员：
   1. 由多方成员共同组成，通常包括 用户 和 实施方的决策人员
3. 工作内容：
   1. 通过 评审手段 来决定项目是否能变更，但不提出变更方案
4. 过程步骤：
   1. 指定决策
   2. 交流情况
   3. 重新协商约定

7.3 需求跟踪

1. 概念：包括编制每个需求同系统元素之间的联系文档，是要在整个项目的工件之间形成 水平可追踪性。
2. 跟踪方式：
   1. 正向跟踪：表示用户原始需求是否都实现了
   2. 反向跟踪：表示软件实现的是否都是用户要求的，不多不少，可以用原始需求和用例表格（需求跟踪矩阵）来表示
   3. 双向跟踪：正向和反向的合称
3. 需求跟踪矩阵：保存了需求与后继工作成果的对应关系
4. 跟踪能力：是优秀需求规格说明书的一个特征。