# 需求分析

> 计算机科学 · CIE A-Level
> 来源: https://www.owlsprep.com/zh/study/cie-9618-u12-requirement-analysis/

需求分析是软件开发生命周期中第一个关键阶段，在此阶段你需要确定新系统必须实现什么功能，以及必须遵守哪些约束。本模块涵盖了CIE 9618考试的所有核心考点。

**先修:** [对软件开发生命周期的基本理解](https://www.owlsprep.com/zh/study/cie-9618-u12-sdlc-stages/)

## 学习目标

- 区分功能性需求和非功能性需求
- 识别所有相关利益相关者及其需求
- 为不同场景选择并论证合适的需求调研方法
- 为软件项目生成有效、可测试的需求文档

## 需求的核心类型

**需求分析** — 针对新建或修改的软件系统，获取、分析、记录和验证利益相关者需求的过程

*例:* 收集学校教职工的输入，以构建新的考勤跟踪系统

所有需求分为两个核心类别，CIE考试经常要求你对需求进行分类：

- **功能性需求**：描述系统*必须完成*的内容 — 具体功能、操作、输入、输出和流程。
- **非功能性需求**：描述系统*必须达到的性能要求* — 对速度、安全性、可用性、可靠性、成本和兼容性的约束。

**例题:** 将以下新网上银行应用的需求分类为功能性或非功能性：(a) 应用必须允许用户在账户之间转账，(b) 根据行业规定，应用必须对所有静态用户数据进行加密。

1. 首先，回忆两种需求类型的区别：
2. 功能性 = 系统做什么，非功能性 = 系统运行的约束条件
3. (a) 转账是应用执行的特定操作 → 这是一个
4. (b) 数据加密是应用必须满足的安全性约束 → 这是一个
5. 最终答案：(a) 功能性，(b) 非功能性

> **考试提示:** 即使分类看起来很明显，考试答题时也要将你的分类和定义关联起来，才能获得满分。

## 利益相关者识别

只有先识别出所有相关利益相关者，才能正确收集需求。遗漏利益相关者会导致需求不完整，最终造成项目失败。

**利益相关者** — 对软件系统的开发、使用或结果有利益关系的任何个人、团体或组织

*例:* 终端用户、业务经理、IT支持团队、监管机构、客户

**例题:** 某医院正在构建新的患者记录系统。请说出两个利益相关者，以及每个利益相关者各自独有的一项需求。

1. 1. 识别除终端用户之外受系统影响的不同群体：
2. 2. 第一个利益相关者：医生（终端用户）。需求（功能性）：系统必须允许医生在2次点击内访问患者5年的病史。
3. 3. 第二个利益相关者：医院合规团队（间接利益相关者）。需求（非功能性）：系统必须将所有患者记录保存10年，以符合法规要求。

> **考试提示:** 答题时不要忘记间接利益相关者（如监管机构或IT支持团队） — 考官经常考察你是否记得这些群体。

## 需求调研方法

需求调研是从利益相关者处收集需求的过程。CIE考试经常要求你为给定场景推荐并论证一种方法的合理性。

| 方法 | 适用场景 | 主要缺点 |
| --- | --- | --- |
| 访谈 | 小群体、详细需求 | 大样本量下耗时久 |
| 问卷调查 | 大群体、通用需求 | 无法对不清晰回答深入探究 |
| 观察法 | 理解现有工作流程 | 具有侵入性，可能改变员工行为 |
| 文档分析 | 审查现有系统记录 | 文档可能已经过时 |

**例题:** 开发人员正在为一家拥有400名结账员工的大型连锁超市构建新的结账系统。请推荐一种合适的需求调研方法来从员工处收集需求，并说明你的选择理由。

1. 1. 背景：我们需要高效地从大量员工那里收集输入。
2. 2. 推荐方法：问卷调查
3. 3. 论证：问卷调查可以快速、低成本地分发给所有400名员工，从具有代表性的大样本中收集输入。对每位员工进行访谈会耗费太多时间和资源。
4. 4. 局限性说明：如果开发人员需要深入了解员工如何使用当前结账流程，他们会将问卷调查与对小样本员工的观察结合使用。

> **考试提示:** 一定要结合题目中的具体场景论证你的选择，不要只列出通用的优缺点。

## 文档编制与验证

收集需求后，必须对其进行清晰记录和验证，以确认它们是完整、一致、可测试和可实现的。模糊的需求是项目范围蔓延的主要原因。

> **tip**
>
> 所有好的需求都是可测试的：将诸如“系统应该很快”这类模糊表述替换为可测量的表述，比如“系统在2秒内加载结账页面”，这样就可以在测试阶段进行验证。

**例题:** 重写模糊需求“应用必须易于使用”，使其具备可测试性。

1. 1. 添加一个可以在测试中验证的具体、可测量的标准。
2. 2. 一个合格的可测试需求是：90%的首次用户可以在首次打开应用后的3分钟内完成购买。

## 常见错误

- **错误做法:** 将性能/约束需求归类为功能性需求
  - 原因: 混淆了系统功能和系统性能要求
  - 正确做法: 始终将速度、安全性、可用性和合规性约束归类为非功能性需求
- **错误做法:** 仅将终端用户和客户列为利益相关者
  - 原因: 忽略了间接利益相关者，比如监管机构、IT支持和维护团队
  - 正确做法: 列出所有受系统影响的群体，包括不直接使用系统的群体
- **错误做法:** 为数百名利益相关者推荐访谈法
  - 原因: 访谈对于大群体来说太慢，资源消耗太大
  - 正确做法: 从大样本利益相关者收集需求时推荐问卷调查
- **错误做法:** 在文档中接受模糊、不可测试的需求
  - 原因: 模糊需求无法验证，导致系统无法满足利益相关者的需求
  - 正确做法: 重写所有需求，加入具体、可测量的标准
- **错误做法:** 将需求分析视为项目开始时的一次性步骤
  - 原因: 随着项目推进和利益相关者明确需求，需求经常会发生变化
  - 正确做法: 在需求获取后进行验证，并在整个项目生命周期中重新确认变更

## 速查表

| 概念 | 核心定义 | 示例 |
| --- | --- | --- |
| 功能性需求 | 系统必须做的事情 | 处理客户付款 |
| 非功能性需求 | 系统必须达到的性能要求 | 在<1秒内完成付款处理 |
| 利益相关者 | 对系统有利益关系的任何参与方 | 终端用户、监管机构、经理 |
| 问卷调查 | 面向大群体的需求调研方法 | 收集400名结账员工的输入 |
| 访谈 | 面向小群体的需求调研方法 | 从CEO处收集详细需求 |
| 可测试需求 | 具体、可测量的结果 | 90%的用户在<3分钟内完成结账 |

## 下一步

需求分析是所有成功软件开发项目的基础，它直接为软件开发生命周期的所有后续阶段提供输入。需求被完全获取和验证后，你将进入下一步，创建技术设计和模型，将利益相关者的需求转化为可用于构建的系统蓝图。掌握需求分析概念对于CIE 9618大纲后续的项目管理、系统测试和系统评估等主题也至关重要。本主题经常在试卷1和预发布案例分析部分进行考察，因此在这里打下扎实的基础会帮助你在期末考试中稳定得分。

- [软件设计方法](https://www.owlsprep.com/zh/study/cie-9618-u12-software-design-methods/)
- [测试](https://www.owlsprep.com/zh/study/cie-9618-u12-testing/)
- [调试](https://www.owlsprep.com/zh/study/cie-9618-u12-debugging/)

---

来自 [OwlsPrep](https://www.owlsprep.com) —— A-Level / IB / AP / IGCSE 免费学习指南，依据官方考纲编写。原页面：https://www.owlsprep.com/zh/study/cie-9618-u12-requirement-analysis/