11 KiB
第1章 需求工程
考试重要度：★★★★
核心内容：需求的定义与层次、需求获取与分析技术、需求文档编写、需求管理
📢 开篇故事：一个失败的工资系统
A公司从300人发展到5000人，原来的手工工资管理方式完全跟不上了。总经理李云找到技术主管王奇说：
"我们急需一个新工资系统！员工自己登记时间卡，系统自动算工资，五个月搞定，明白吗？"
王奇说："能不能再详细说说？比如有哪些角色用这个系统？每类人需要什么功能？数据怎么流转？"
李云不耐烦："我不就是用户吗？你们自己看着办不就行了？"
💬 这个故事告诉我们什么？
- 老板 ≠ 用户。老板说的是"业务需求"（高层次目标），但不是具体"用户需求"。
- 需求不是想当然的。开发人员不能凭空猜测用户要什么。
- 不同角色有不同需求。出纳、会计、财务主管、普通员工——每个人要的功能都不一样。
- 需求需要花时间获取。反复沟通、深入调查，急不得。
💡 一、什么是软件需求？
一句话定义：需求就是用户对软件系统"应该做什么"和"应该做到什么程度"的期望。
三个权威定义
| 来源 | 定义 |
|---|---|
| IEEE | 用户解决问题所需的条件或能力；系统必须满足的约束；上述内容的文档化表达 |
| Davis | 从软件外部可见的、满足用户的特点、功能及属性的集合 |
| Sommerville | 问题信息与系统行为、特性、设计和实现约束的描述集合 |
💬 大白话：需求就是三件事——做什么功能、做到什么标准、有什么限制。
💡 二、需求的三个层次
这是考试的重点！需求像一座三层金字塔：
┌──────────────┐
│ 业务需求 │ ← 老板视角："我们要什么"
│ Business │
├──────────────┤
│ 用户需求 │ ← 用户视角："我能用它干什么"
│ User │
├──────────────┤
│ 系统需求 │ ← 开发者视角："具体怎么实现"
│ System │
└──────────────┘
| 层次 | 说明 | 举例（工资系统） |
|---|---|---|
| 业务需求 | 组织的高层次目标，回答"为什么要做这个系统" | "用计算机替代手工工资管理，五个月上线" |
| 用户需求 | 用户使用系统完成的任务，回答"用户能干什么" | "财务人员可以录入员工时间卡信息" |
| 系统需求 | 开发人员要实现的具体功能和约束，回答"系统必须做到什么" | "系统自动根据工时和销售额计算工资单" |
系统需求又分三类
| 类型 | 说明 | 举例 |
|---|---|---|
| 功能需求 | 系统必须提供的功能 | 录入时间卡、计算工资、生成工资单 |
| 非功能需求 | 系统的质量属性和约束 | 工资计算5秒内完成、数据不能丢失 |
| 领域需求 | 行业特有的要求 | 遵循《中国图书馆分类法》编目图书 |
✍️ 边学边练（一）
题目：下面哪一个是正确的需求层次顺序（从高到低）？
A. 用户需求 → 业务需求 → 系统需求
B. 业务需求 → 用户需求 → 系统需求
C. 用户需求 → 系统需求 → 业务需求
D. 业务需求 → 系统需求 → 用户需求
答案： 正确答案：B
记住口诀："老板定方向（业务），用户说任务（用户），开发写代码（系统）"，从抽象到具体。
💡 三、需求为什么重要？
数据说话
| 成功因素 | 占比 | 失败因素 | 占比 |
|---|---|---|---|
| 用户参与 | 15.9% | 需求不完善 | 13.1% |
| 管理层支持 | 13.9% | 缺乏用户参与 | 12.4% |
| 清晰的需求 | 13.0% | 资源不足 | 10.6% |
💬 一句话：需求的锅是最大的锅。需求搞错了，后面全白做。
五个常见需求败因
- 需求不完整 — 只问了领导，没问实际操作的人
- 缺乏用户参与 — 用户觉得"我不懂技术，你们自己弄"
- 不切实际的期望 — "10年内每天24小时100%可用"（技术上做不到）
- 需求变更频繁 — 今天加一个，明天改一个，后天不要了
- 做了没人用的功能 — 开发了很多功能，实际使用率极低
💡 四、需求工程的核心流程
需求工程 = 所有跟需求有关的活动，分成"开发"和"管理"两大类。
需求开发（做对需求）： 获取 → 分析 → 定义（写文档）
需求管理（管好需求）： 验证 → 跟踪 → 变更控制
① 需求获取 — 怎么收集需求？
💬 打个比方：需求获取就像医生问诊——你不会直接让病人给自己开药，而是通过望闻问切来了解病情。
六大获取技术：
| 技术 | 怎么做 | 适用场景 |
|---|---|---|
| 联合分析小组 | 用户 + 领域专家 + 分析员坐在一起 | 大型复杂项目 |
| 用户访谈 | 一对一或小组面谈 | 深入了解具体业务 |
| 问卷调查 | 发放问卷收集大量反馈 | 用户分散、人数多 |
| 观察工作流程 | 到现场看用户怎么干活 | 发现"隐形的需求" |
| 原型法 | 做个简单的界面模型给用户试用 | 用户说不清楚自己要什么 |
| 文档分析 | 研究现有的规章制度、报表等 | 理解业务规则 |
⚠️ 关键认知：很多需求是隐形的——用户觉得"这还用说吗"，但实际上不说就不会被实现。所以要主动挖掘。
② 需求分析 — 怎么理清需求？
两种基本方法：
| 方法 | 核心思想 | 使用的图 |
|---|---|---|
| 结构化分析 (SA) | 把大问题分解成小问题，逐层细化 | DFD数据流图、ER图、状态转换图 |
| 面向对象分析 (OOA) | 基于用例，用对象来组织系统 | 用例图、类图、顺序图等UML图 |
💬 SA像切蛋糕：一层层切，直到每一块都能一口吃掉。
💬 OOA像拼乐高：先找到有哪些"积木块"（类），再定义他们怎么拼在一起（关系）。
③ 需求定义 — 写需求文档
两份核心文档：
| 文档 | 谁看 | 用什么语言 | 什么程度 |
|---|---|---|---|
| 用户需求说明书 | 用户审核 | 自然语言+业务术语 | 比较粗略 |
| 软件需求规格说明书(SRS) | 开发团队 | 技术语言+图形模型 | 非常详细 |
💬 区别：用户需求说明书像"装修意向书"（我要北欧风、三室两厅），SRS像"施工图"（客厅长5米宽4米，插座位置距地30cm）。
🔑 优秀需求的七个标准
| 标准 | 含义 |
|---|---|
| 完整性 | 所有功能都说清楚了，不缺项 |
| 正确性 | 描述的功能确实是用户要的 |
| 无歧义 | 所有人读出来是同一个意思（别用"可能""差不多"） |
| 可行性 | 技术上能做、预算内能做 |
| 有优先级 | 分清楚哪些先做、哪些后做 |
| 必要性 | 每个需求都有存在的理由 |
| 可验证性 | 能通过测试来确认是否实现了 |
④ 需求验证 — 怎么确认需求是对的？
验证什么：
- ✅ 有效性：写的功能是不是用户真实需要的
- ✅ 一致性：有没有前后矛盾的描述
- ✅ 完备性：有没有漏掉的需求
- ✅ 可检验性：能不能设计测试来验证
主要方法：需求评审 — 开发方和客户方一起逐条审查，签字确认后形成"需求基线"。
⑤ 需求跟踪
双向跟踪：
- 正向跟踪：需求 → 设计 → 代码 → 测试，确保每个需求都有实现
- 逆向跟踪：代码 → 设计 → 需求，确保每一行代码都有需求来源
⑥ 需求变更控制
💬 需求变更像改装修方案——墙都砌好了你说要拆？不是不行，但要评估影响、调整预算、重新排期。
变更控制流程：提出变更 → 评审影响 → 审批 → 修改 → 重新确认
✍️ 边学边练（二）
题目：图书馆系统有以下描述，请区分功能需求、非功能需求和领域需求。
- 系统要能实现图书借阅和归还的登记
- 每次借书登记必须在1秒内完成
- 图书编目要遵循《中国图书馆分类法》
- 借书登记出错率不超过万分之一
- 某些文献只能在阅览室阅读，不能外借
答案：
- ① 功能需求 — 描述系统要做什么（借阅登记、归还登记）
- ② 非功能需求（性能） — 描述系统要做到什么程度（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章 用例图