第2章 需求分析基础
如何收集需求？用户故事与用例图（UML）入门
需求分析是技术方案设计的起点。没有清晰的需求，后续的架构、编码、测试都会失去方向。本章将带你掌握需求收集的核心方法，并学会使用用户故事和UML用例图这两种经典工具来结构化表达需求。
2.1 需求收集的四大渠道
高效的需求收集需要多维度交叉验证，避免单一视角带来的偏差。以下是最常用的四种方式：
| 方法 | 适用场景 | 产出物 |
|---|---|---|
| 用户访谈 | 探索性、小规模定性分析 | 访谈纪要、痛点清单 |
| 问卷调查 | 大规模定量验证 | 统计报告、优先级排序 |
| 现场观察 | 理解真实工作流 | 用户旅程图、操作日志 |
| 文档分析 | 已有系统或规范参考 | 功能清单、数据字典 |
💡 实践建议： 在项目启动阶段，至少组合使用访谈 + 问卷两种方法，既能获得深度洞察，又能覆盖足够样本量。
2.2 用户故事：让需求有温度
用户故事（User Story）是敏捷需求的标准格式，它从用户视角描述功能价值。标准模板：
作为<角色>，我想要<功能>，以便<商业价值>。例如：
- 作为 普通用户，我想要 一键重置密码，以便 在忘记密码时快速恢复访问。
- 作为 管理员，我想要 查看用户操作日志，以便 审计异常行为。
用户故事的 INVEST 原则
| 字母 | 含义 | 说明 |
|---|---|---|
| I | Independent（独立的） | 故事之间尽量解耦 |
| N | Negotiable（可协商的） | 细节可讨论，非铁板钉钉 |
| V | Valuable（有价值的） | 对用户或业务有明确价值 |
| E | Estimable（可估算的） | 团队能评估工作量 |
| S | Small（小的） | 粒度适中，可在一次迭代完成 |
| T | Testable（可测试的） | 有明确的验收标准 |
2.3 UML用例图：系统功能的全局视图
用例图（Use Case Diagram）是UML中用于描述系统功能与参与者关系的图形化工具。它不涉及内部实现，只关注外部可见的功能。
核心元素
- 参与者（Actor）：与系统交互的人或外部系统，用火柴人表示。
- 用例（Use Case）：系统提供的完整功能，用椭圆表示。
- 关系：关联（直线）、包含（<<include>>）、扩展（<<extend>>）、泛化（空心箭头）。
用例图 vs 用户故事
| 维度 | 用户故事 | 用例图 |
|---|---|---|
| 形式 | 文本卡片 | 图形化模型 |
| 粒度 | 较小，一个故事一个功能点 | 较大，一个用例包含完整流程 |
| 适用阶段 | 迭代计划、需求细化 | 系统分析、范围界定 |
| 用户参与度 | 高，用户可自行编写 | 中，需要分析师引导 |
🔗 最佳实践： 先用用例图确定系统边界和主要功能模块，再针对每个用例编写若干用户故事来细化具体需求。两者互补，而非替代。
2.4 实战演练：从用户故事到用例图
假设我们要设计一个会议室预订系统。以下是收集到的部分用户故事：
- 作为员工，我想要查看空闲会议室，以便快速预订。
- 作为员工，我想要取消我的预订，以便释放资源。
- 作为管理员，我想要设置会议室容量和设备，以便维护基础数据。
将这些故事抽象为用例图：
验收标准示例（用户故事配套）
场景：员工成功预订会议室
给定 员工已登录系统
当 员工选择空闲时段并提交预订
则 系统显示预订成功，并发送确认邮件
场景：预订冲突
给定 该时段已被预订
当 员工尝试预订同一时段
则 系统提示“该时段已被占用”，并推荐其他空闲时段本章小结
需求分析不是一次性活动，而是贯穿项目始终的持续对话。掌握用户故事和用例图，你就拥有了从用户视角和系统视角双向描述需求的能力。下一章我们将学习如何对需求进行结构化拆解，为技术设计打下坚实基础。