# 第1章 需求工程

> **考试重要度**：★★★★  
> **核心内容**：需求的定义与层次、需求获取与分析技术、需求文档编写、需求管理

---

## 📢 开篇故事：一个失败的工资系统

A公司从300人发展到5000人，原来的手工工资管理方式完全跟不上了。总经理李云找到技术主管王奇说：

> "我们急需一个新工资系统！员工自己登记时间卡，系统自动算工资，五个月搞定，明白吗？"

王奇说："能不能再详细说说？比如有哪些角色用这个系统？每类人需要什么功能？数据怎么流转？"

李云不耐烦："我不就是用户吗？你们自己看着办不就行了？"

💬 **这个故事告诉我们什么？**

1. **老板 ≠ 用户**。老板说的是"业务需求"（高层次目标），但不是具体"用户需求"。
2. **需求不是想当然的**。开发人员不能凭空猜测用户要什么。
3. **不同角色有不同需求**。出纳、会计、财务主管、普通员工——每个人要的功能都不一样。
4. **需求需要花时间获取**。反复沟通、深入调查，急不得。

---

## 💡 一、什么是软件需求？

> **一句话定义**：需求就是用户对软件系统"应该做什么"和"应该做到什么程度"的期望。

### 三个权威定义

| 来源 | 定义 |
|------|------|
| **IEEE** | 用户解决问题所需的**条件或能力**；系统必须满足的**约束**；上述内容的**文档化表达** |
| **Davis** | 从软件外部可见的、满足用户的**特点、功能及属性**的集合 |
| **Sommerville** | 问题信息与系统**行为、特性、设计和实现约束**的描述集合 |

💬 **大白话**：需求就是三件事——**做什么功能**、**做到什么标准**、**有什么限制**。

---

## 💡 二、需求的三个层次

这是考试的重点！需求像一座三层金字塔：

```
        ┌──────────────┐
        │  业务需求     │  ← 老板视角："我们要什么"
        │  Business     │
        ├──────────────┤
        │  用户需求     │  ← 用户视角："我能用它干什么"
        │  User         │
        ├──────────────┤
        │  系统需求     │  ← 开发者视角："具体怎么实现"
        │  System       │
        └──────────────┘
```

| 层次 | 说明 | 举例（工资系统） |
|------|------|------------------|
| **业务需求** | 组织的高层次目标，回答"为什么要做这个系统" | "用计算机替代手工工资管理，五个月上线" |
| **用户需求** | 用户使用系统完成的任务，回答"用户能干什么" | "财务人员可以录入员工时间卡信息" |
| **系统需求** | 开发人员要实现的具体功能和约束，回答"系统必须做到什么" | "系统自动根据工时和销售额计算工资单" |

### 系统需求又分三类

| 类型 | 说明 | 举例 |
|------|------|------|
| **功能需求** | 系统必须提供的功能 | 录入时间卡、计算工资、生成工资单 |
| **非功能需求** | 系统的质量属性和约束 | 工资计算5秒内完成、数据不能丢失 |
| **领域需求** | 行业特有的要求 | 遵循《中国图书馆分类法》编目图书 |

---

## ✍️ 边学边练（一）

**题目**：下面哪一个是正确的需求层次顺序（从高到低）？

A. 用户需求 → 业务需求 → 系统需求  
B. 业务需求 → 用户需求 → 系统需求  
C. 用户需求 → 系统需求 → 业务需求  
D. 业务需求 → 系统需求 → 用户需求

**答案：**
**正确答案：B**

记住口诀：**"老板定方向（业务），用户说任务（用户），开发写代码（系统）"**，从抽象到具体。

---

## 💡 三、需求为什么重要？

### 数据说话

| 成功因素 | 占比 | 失败因素 | 占比 |
|----------|------|----------|------|
| 用户参与 | **15.9%** | 需求不完善 | **13.1%** |
| 管理层支持 | 13.9% | 缺乏用户参与 | 12.4% |
| 清晰的需求 | 13.0% | 资源不足 | 10.6% |

💬 **一句话**：需求的锅是最大的锅。需求搞错了，后面全白做。

### 五个常见需求败因

1. **需求不完整** — 只问了领导，没问实际操作的人
2. **缺乏用户参与** — 用户觉得"我不懂技术，你们自己弄"
3. **不切实际的期望** — "10年内每天24小时100%可用"（技术上做不到）
4. **需求变更频繁** — 今天加一个，明天改一个，后天不要了
5. **做了没人用的功能** — 开发了很多功能，实际使用率极低

---

## 💡 四、需求工程的核心流程

> **需求工程** = 所有跟需求有关的活动，分成"开发"和"管理"两大类。

```
需求开发（做对需求）：  获取 → 分析 → 定义（写文档）
需求管理（管好需求）：  验证 → 跟踪 → 变更控制
```

### ① 需求获取 — 怎么收集需求？

💬 **打个比方**：需求获取就像医生问诊——你不会直接让病人给自己开药，而是通过望闻问切来了解病情。

**六大获取技术**：

| 技术 | 怎么做 | 适用场景 |
|------|--------|----------|
| **联合分析小组** | 用户 + 领域专家 + 分析员坐在一起 | 大型复杂项目 |
| **用户访谈** | 一对一或小组面谈 | 深入了解具体业务 |
| **问卷调查** | 发放问卷收集大量反馈 | 用户分散、人数多 |
| **观察工作流程** | 到现场看用户怎么干活 | 发现"隐形的需求" |
| **原型法** | 做个简单的界面模型给用户试用 | 用户说不清楚自己要什么 |
| **文档分析** | 研究现有的规章制度、报表等 | 理解业务规则 |

⚠️ **关键认知**：很多需求是**隐形的**——用户觉得"这还用说吗"，但实际上不说就不会被实现。所以要主动挖掘。

### ② 需求分析 — 怎么理清需求？

两种基本方法：

| 方法 | 核心思想 | 使用的图 |
|------|----------|----------|
| **结构化分析 (SA)** | 把大问题分解成小问题，逐层细化 | DFD数据流图、ER图、状态转换图 |
| **面向对象分析 (OOA)** | 基于用例，用对象来组织系统 | 用例图、类图、顺序图等UML图 |

💬 **SA像切蛋糕**：一层层切，直到每一块都能一口吃掉。  
💬 **OOA像拼乐高**：先找到有哪些"积木块"（类），再定义他们怎么拼在一起（关系）。

### ③ 需求定义 — 写需求文档

**两份核心文档**：

| 文档 | 谁看 | 用什么语言 | 什么程度 |
|------|------|------------|----------|
| **用户需求说明书** | 用户审核 | 自然语言+业务术语 | 比较粗略 |
| **软件需求规格说明书(SRS)** | 开发团队 | 技术语言+图形模型 | 非常详细 |

💬 **区别**：用户需求说明书像"装修意向书"（我要北欧风、三室两厅），SRS像"施工图"（客厅长5米宽4米，插座位置距地30cm）。

### 🔑 优秀需求的七个标准

| 标准 | 含义 |
|------|------|
| **完整性** | 所有功能都说清楚了，不缺项 |
| **正确性** | 描述的功能确实是用户要的 |
| **无歧义** | 所有人读出来是同一个意思（别用"可能""差不多"） |
| **可行性** | 技术上能做、预算内能做 |
| **有优先级** | 分清楚哪些先做、哪些后做 |
| **必要性** | 每个需求都有存在的理由 |
| **可验证性** | 能通过测试来确认是否实现了 |

### ④ 需求验证 — 怎么确认需求是对的？

**验证什么**：
- ✅ 有效性：写的功能是不是用户真实需要的
- ✅ 一致性：有没有前后矛盾的描述
- ✅ 完备性：有没有漏掉的需求
- ✅ 可检验性：能不能设计测试来验证

**主要方法**：**需求评审** — 开发方和客户方一起逐条审查，签字确认后形成"需求基线"。

### ⑤ 需求跟踪

**双向跟踪**：
- **正向跟踪**：需求 → 设计 → 代码 → 测试，确保每个需求都有实现
- **逆向跟踪**：代码 → 设计 → 需求，确保每一行代码都有需求来源

### ⑥ 需求变更控制

💬 **需求变更像改装修方案**——墙都砌好了你说要拆？不是不行，但要评估影响、调整预算、重新排期。

**变更控制流程**：`提出变更 → 评审影响 → 审批 → 修改 → 重新确认`

---

## ✍️ 边学边练（二）

**题目**：图书馆系统有以下描述，请区分功能需求、非功能需求和领域需求。

1. 系统要能实现图书借阅和归还的登记
2. 每次借书登记必须在1秒内完成
3. 图书编目要遵循《中国图书馆分类法》
4. 借书登记出错率不超过万分之一
5. 某些文献只能在阅览室阅读，不能外借

**答案：**
- ① **功能需求** — 描述系统要做什么（借阅登记、归还登记）
- ② **非功能需求（性能）** — 描述系统要做到什么程度（1秒内）
- ③ **领域需求** — 行业特有的规则约束
- ④ **非功能需求（可靠性）** — 错误率的量化指标
- ⑤ **领域需求** — 版权法对图书馆业务的特殊约束

⚠️ **易错点**：区分功能需求和非功能需求的关键在于——**功能需求说"做什么"，非功能需求说"做多好"**。

---

## 📝 章末自测

**1. 填空题**
- 需求的三个层次从高到低依次是：（ ___ ）（ ___ ）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）
- 优秀需求的七个特性中，"所有人读出来是同一个意思"指的是（ ___ ）（ ___ ）性
- 结构化分析的三个模型是：功能模型（DFD）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）

**2. 简答题**
- 简述"用户需求说明书"和"软件需求规格说明书(SRS)"的区别。
- 结构化分析(SA)和面向对象分析(OOA)的核心区别是什么？

**3. 应用题**
- 某在线购物系统，请分别写出一条：业务需求、用户需求、功能需求、非功能需求。

**答案：**
**填空题答案**：
- 业务需求、用户需求、系统需求
- 无歧义性
- 数据模型（ER图）、行为模型（状态转换图）

**简答题答案**：
- 用户需求说明书用自然语言+业务术语描述，内容粗略，给用户审核用；SRS用技术语言+图形描述，内容精细，是开发的直接依据。
- SA把系统按功能层层分解，用DFD、ER图等；OOA基于用例识别对象，用UML图来描述，是目前的主流方法。

**应用题参考答案**：
- 业务需求："建立一个在线购物平台，提升销售额30%"
- 用户需求："注册用户可以浏览商品、加入购物车、下单支付"
- 功能需求："系统应提供商品搜索功能，支持按名称、类别、价格范围筛选"
- 非功能需求："页面加载时间不超过3秒，支持1000人同时在线"

---

## 📘 真题演练

**题目**（教材课后习题）：下列哪些是需求获取的技术？（多选）

A. 用户访谈  
B. 代码走查  
C. 问卷调查  
D. 原型法  
E. 观察用户工作流程  
F. 单元测试

**答案：**
**正确答案：A、C、D、E**

B（代码走查）和F（单元测试）属于开发/测试阶段的活动，不是需求获取技术。

需求获取的六大技术：联合分析小组、用户访谈、问卷调查、观察工作流程、原型法、文档分析。

---
> 🔗 下一篇：[第3章 用例图](第03章-用例图.md)