需求分析方法
用户故事、用例图、需求获取与需求管理。
1. 从”点外卖却收到一本书”说起
1.1 一个需求失败的经典场景
想象你在外卖 App 上点了一份”黄焖鸡米饭”，结果骑手送来了一本书。你当然会愤怒。但更糟的是，如果这是一个软件项目——你想要的和你理解的，从一开始就是两回事。
现实中这样的例子比比皆是：
- 产品经理说”做个推荐功能”，开发做成了”按销量排序”——因为”推荐”没定义清楚
- 用户说”登录要简单”，开发做成”手机号+验证码”——但用户想要的是”微信一键登录”
- 需求文档写了”支持多语言”，开发做了”中英文切换”——但产品要的是”自动识别用户语言”
这些问题的共同根源：需求没有被”搞清楚、写明白、对齐验证”——这正是**需求工程（Requirement Engineering）**要解决的核心问题。
1.2 什么是需求工程
需求工程是系统地获取、分析、记录、验证需求的过程——确保”我们建造的是正确的系统”（做正确的事），而不仅仅是”正确地建造系统”（正确地做事）。
需求工程做不好，后面的设计、编码、测试都是”在错误的地基上盖楼”——返工成本成倍放大。
2. 需求层次：从”为什么”到”怎么做”
2.1 三个层次
业务需求 → 用户需求 → 系统需求
(为什么) (做什么) (怎么做)| 层次 | 来源 | 示例 |
|---|---|---|
| 业务需求 | 利益相关者 | 提升用户留存率 20% |
| 用户需求 | 最终用户 | 用户能快速找到所需商品 |
| 系统需求 | 开发团队 | 搜索响应时间 < 200ms |
理解：
- 业务需求回答”为什么做”——业务目标（留存率、收入、效率）
- 用户需求回答”用户要做什么”——用户视角的功能描述
- 系统需求回答”系统要怎么做”——技术视角的可实现描述
需求工程师的职责：把”业务需求”翻译成”用户需求”，再和开发团队一起翻译成”系统需求”。每一层翻译都可能失真，所以每层都要验证。
2.2 功能需求 vs 非功能需求
| 类型 | 说明 | 示例 |
|---|---|---|
| 功能需求 | 系统应该做什么 | 用户可以创建订单 |
| 非功能需求 | 系统应该做到什么程度 | 订单创建响应时间 < 500ms |
非功能需求（FURPS+ 分类）：
| 类别 | 说明 | 示例 |
|---|---|---|
| Functionality | 功能性 | 功能完整性 |
| Usability | 可用性 | 学习曲线、操作步骤 |
| Reliability | 可靠性 | MTBF、容错能力 |
| Performance | 性能 | 响应时间、吞吐量 |
| Supportability | 可支持性 | 可维护性、可扩展性 |
初学者最容易忽略非功能需求。功能需求好定义（“能下单”），非功能需求（“下单要快""系统要稳定”）常常没人写——直到上线后才发现性能不达标、可用性不满足。
3. 需求获取：怎么把”想要”挖出来
3.1 六种获取技术
| 方法 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 访谈 | 深入了解需求 | 信息丰富 | 耗时 |
| 问卷调查 | 大范围收集 | 覆盖面广 | 深度不够 |
| 观察 | 了解实际工作流 | 真实场景 | 可能影响行为 |
| 原型 | 需求不明确 | 直观反馈 | 成本较高 |
| 文档分析 | 现有系统改造 | 基于事实 | 可能过时 |
| 焦点小组 | 收集多方意见 | 多角度 | 组织难度大 |
3.2 需求获取流程
1. 识别利益相关者（谁关心这个系统？）
2. 确定获取策略（用什么方法？）
3. 执行获取活动（去问、去观察、去试）
4. 整理和记录需求（写下来）
5. 验证需求完整性（够了吗？准吗？）关键技巧：需求获取最怕”用户说的不是心里想的”。常用追问技巧：
- “为什么需要这个功能？“（挖业务价值，而不是直接实现）
- “如果不做这个功能，会发生什么？“（判断真实优先级）
- “这个功能谁会用它？什么时候用？“（明确场景）
4. 用户故事：敏捷世界的需求载体
4.1 标准格式
作为 [角色]，
我希望 [功能]，
以便 [业务价值]三个要素：
- 角色：谁在使用（用户、管理员、运营）
- 功能：要做什么
- 价值：为什么做（这是最容易漏掉、也最重要的）
作为 注册用户，
我希望 能够收藏喜欢的文章，
以便 下次可以快速找到它们4.2 INVEST 原则
好的用户故事应该满足：
| 原则 | 含义 |
|---|---|
| Independent | 故事之间尽量独立 |
| Negotiable | 故事是可协商的 |
| Valuable | 对用户或业务有价值 |
| Estimable | 可以估算工作量 |
| Small | 足够小，一个 Sprint 内完成 |
| Testable | 可以验证是否完成 |
4.3 用户故事拆分
大故事（史诗 Epic）需要拆成可执行的小故事：
| 拆分模式 | 说明 | 示例 |
|---|---|---|
| 按工作流步骤 | 拆分流程中的步骤 | 搜索 → 筛选 → 下单 |
| 按数据变体 | 拆分不同数据类型 | 国内支付 → 国际支付 |
| 按操作 | 拆分 CRUD 操作 | 创建订单 → 查看订单 |
| 按业务规则 | 拆分不同规则 | 普通用户 → VIP 用户 |
| 按界面 | 拆分不同界面 | 移动端 → 桌面端 |
5. 用例图：需求的图形化表达
5.1 用例图元素
用例图（Use Case Diagram）用图形描述”谁（参与者）能用系统做什么（用例）”：
| 元素 | 符号 | 说明 |
|---|---|---|
| 参与者 | 小人 | 与系统交互的外部实体 |
| 用例 | 椭圆 | 系统提供的功能 |
| 系统边界 | 矩形 | 系统范围 |
| 关联 | 实线 | 参与者与用例的关系 |
| 包含 | «include» | 必然执行的行为 |
| 扩展 | «extend» | 条件执行的行为 |
| 泛化 | 空心箭头 | 一般到特殊 |
5.2 用例描述模板
用例图只画”框架”，真正的内容在用例描述里：
用例名称: 用户登录
参与者: 注册用户
前置条件: 用户已注册
主流程:
1. 用户输入用户名和密码
2. 系统验证凭据
3. 系统创建会话
4. 系统跳转到首页
备选流程:
2a. 凭据无效: 提示错误，允许重试
2b. 账户锁定: 提示联系管理员
后置条件: 用户已登录用例描述的威力：它强迫你写清楚”主流程 + 备选流程”——备选流程（异常路径）往往是被遗忘需求的重灾区。
6. 需求管理：需求是会变的
6.1 需求变更控制
需求不是”一次定死”的，但变更必须受控：
变更请求 → 影响分析 → 变更评审 → 批准/拒绝 → 实施 → 验证| 步骤 | 关键活动 |
|---|---|
| 变更请求 | 记录变更内容和原因 |
| 影响分析 | 评估对进度、成本、质量的影响 |
| 变更评审 | CCB（变更控制委员会）决策 |
| 实施 | 修改需求和设计 |
| 验证 | 确认变更正确实施 |
关键认知：需求变更不可怕，可怕的是**“无记录、无评估”的随意变更**。受控的变更是”管理”，不受控的变更是”灾难”。
6.2 需求追踪矩阵
需求追踪矩阵（RTM）把需求与设计、代码、测试关联起来，保证”每个需求都有落实、都有验证”：
| 需求ID | 需求描述 | 设计文档 | 代码模块 | 测试用例 | 状态 |
|---|---|---|---|---|---|
| REQ-01 | 用户登录 | HLD-3.1 | auth.py | TC-01~03 | 完成 |
| REQ-02 | 密码重置 | HLD-3.2 | reset.py | TC-04~06 | 开发中 |
RTM 的价值：上线前检查矩阵——有没有”设计里没有、代码里没有、测试里没有”的需求？有没有”代码里实现了、但需求里没有”的功能（过度开发）？
6.3 需求验证
| 方法 | 说明 |
|---|---|
| 需求评审 | 同行评审需求文档 |
| 原型验证 | 用原型确认需求理解 |
| 验收测试 | 用户确认需求满足 |
| 需求基线 | 确认的需求版本冻结 |
7. 常见误区
误区一：需求 = 用户说的原话。 → 用户说的往往是”解决方案”，不是”真实需求”。要追问”为什么”，找到背后的业务价值。
误区二：需求文档越详细越好。 → 文档要”准确”和”可验证”，不是”厚”。一本没人读的 200 页需求文档，不如 10 页清晰的对齐文档。
误区三：需求分析是”分析阶段”的事，做完就完了。 → 需求贯穿整个生命周期（敏捷里尤其如此）。需求会变，管理好变化比”一次定死”更重要。
误区四：只定义功能需求，忽略非功能需求。 → 性能、安全、可用性这些”看不见”的需求，恰恰是上线后最容易出问题的。