272 lines
11 KiB
Markdown
272 lines
11 KiB
Markdown
# 第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)
|