需求分析与用户故事（Requirements Analysis）
概述
大多数开发失败不是因为代码写得差，而是因为需求没想清楚。"做一个用户管理系统"不是需求，"用户可以通过邮箱注册并在 3 秒内收到验证邮件"才是需求。本技能提供从模糊想法到可执行需求的完整转化流程。
何时使用
- 项目启动前的需求梳理
- 将客户/产品经理的口头描述转化为结构化文档
- Sprint 计划时拆分和排列用户故事
- 评审需求文档是否完整、可测试
五步需求工作流
| 步骤 | 动作 | 关键问题 |
|---|---|---|
| 1. 澄清目标 | 明确要解决什么问题、为谁解决 | 如果不做这个功能，谁会受影响？ |
| 2. 识别用户 | 列出所有角色和使用场景 | 谁会用？在什么情况下用？ |
| 3. 编写用户故事 | 用标准格式描述每个需求 | 用户想要什么？为什么想要？ |
| 4. 定义验收标准 | 为每个故事写 Given/When/Then | 怎么判断"做完了"？ |
| 5. 排列优先级 | 用 MoSCoW 方法分级 | 哪些必须做？哪些可以晚做？ |
用户故事格式
标准格式：
作为 [角色]，我想要 [动作]，以便 [收益]
As a [role], I want [action], so that [benefit]
好的用户故事示例：
作为注册用户，我想要通过邮箱重置密码，以便在忘记密码时恢复账户访问。
差的用户故事示例：
用户需要密码重置功能。（缺少角色、缺少收益、不可测试）
验收标准（Acceptance Criteria）
使用 Given/When/Then 格式，附带具体数据：
场景：注册用户重置密码
假设（Given）用户已注册且邮箱已验证
当（When）用户点击"忘记密码"并输入注册邮箱
那么（Then）系统在 30 秒内发送包含重置链接的邮件
并且（And）链接有效期为 24 小时
并且（And）使用过的链接不能重复使用
范围控制
每个需求文档必须明确三个列表：
| 列表 | 作用 | 示例 |
|---|---|---|
| 范围内（In Scope） | 本次迭代必须交付 | 邮箱注册、密码重置 |
| 范围外（Out of Scope） | 明确不做 | 第三方登录、手机号注册 |
| 未来计划（Future） | 后续迭代考虑 | SSO 集成、多因子认证 |
作用：防止范围蔓延（Scope Creep），强制团队做出明确取舍。
非功能需求清单
| 维度 | 需要定义的内容 |
|---|---|
| 性能 | 响应时间目标（如 P95 < 200ms）、并发用户数 |
| 安全 | 认证方式、数据加密要求、合规标准（GDPR 等） |
| 可访问性 | WCAG 等级（A/AA/AAA）、屏幕阅读器支持 |
| 浏览器/设备 | 支持的浏览器版本、移动端适配要求 |
| 可用性 | SLA 目标（如 99.9%）、灾备方案 |
优先级排序：MoSCoW 方法
| 等级 | 含义 | 占比建议 |
|---|---|---|
| Must（必须） | 没有就不能上线 | 约 60% |
| Should（应该） | 重要但有替代方案 | 约 20% |
| Could（可以） | 锦上添花 | 约 15% |
| Won't（不做） | 本次明确不做 | 约 5% |
必须做 / 禁止做
必须做（MUST DO）：
- 开始编码前写好验收标准（Acceptance Criteria）
- 定义明确的"完成标准"（Definition of Done）
- 提前识别边界情况（Edge Cases）和异常流程
- 用具体数字替代模糊描述（"快"改为"P95 < 200ms"）
禁止做（MUST NOT）：
- 带着模糊需求开始编码（"做个好用的界面"不是需求）
- 迭代中途随意追加范围（Scope Creep）
- 假设未明确说明的需求（不确定就问）
- 把技术方案写进需求文档（需求说"做什么"，不说"怎么做"）