2. 需求描述规范编制
适用场景
本规范适用于跨团队需求初始化阶段，当产品经理、业务分析师或需求提出方需要将原始业务诉求转化为可被开发团队理解和执行的粒度单元时。典型触发场景包括：
- 新功能或模块的首次需求拆解
- 已有需求因干系人变更需重新对齐
- 需求进入 sprint 规划前需补充验收标准
- 跨团队协同中需统一需求表述口径
前置条件
- 已完成干系人识别，并明确需求来源（客户、内部运营、管理层等）
- 已收集至少一份用户访谈纪要或原始需求描述文件
- 团队已约定统一的协同工具（如 Jira、ClickUp、Notion）
- 产品负责人已确认本次需求优先级及时间窗口
操作步骤
| 步骤 | 动作 | 输出物 | 注意事项 |
|---|---|---|---|
| 1 | 将原始需求拆解为独立的用户场景 | 场景清单 | 每个场景对应一个独立的价值点 |
| 2 | 为每个场景编写用户故事： As a [角色], I want [功能], so that [价值] | 用户故事正文 | 保持一句话，避免多个意图 |
| 3 | 为每个用户故事定义验收条件（Acceptance Criteria） | 验收检查表 | 使用 Given/When/Then 格式，覆盖主路径与异常路径 |
| 4 | 填写字段约定：故事点、优先级、标签、关联 Epic | 字段完备的故事条目 | 按照团队约定的字段模板填写 |
| 5 | 组织团队成员进行故事评审（三幕结构） | 评审记录 | 至少包含开发、测试、产品三方参与 |
关键提示：用户故事不是需求规格文档，它是“承诺对话”的占位符。验收条件才是可执行契约，必须足够明确以驱动开发和测试工作。
输入输出物
| 输入 | 来源 | 输出 | 去向 |
|---|---|---|---|
| 原始需求说明 用户访谈纪要 | 业务方 / 用户研究 | 结构化需求描述模板 | 开发团队、测试团队、架构师 |
| 现有系统功能清单 | 技术团队 | 用户故事列表（含字段） | 产品待办列表（Backlog） |
| 优先级矩阵 | 产品负责人 | 验收条件检查表 | Sprint 规划会 |
责任边界
- 产品经理 / 业务分析师：负责用户故事初稿编写、验收条件第一轮定义、字段填充。
- 开发团队代表：在评审环节质疑故事完备性、预判技术实现风险、补充非功能验收条件。
- 测试团队代表：基于验收条件编写测试用例，必要时建议拆分故事。
- Scrum Master / 项目协调：确保评审按时举行，记录偏差项并推动闭环。
记录材料
- 用户故事卡（电子或物理）：包含 As a…、I want…、so that… 三要素及对应验收条件列表。
- 字段定义表：记录团队约定字段含义，例如“故事点=规模估算，优先级=MoSCoW 法”。
- 评审会议日志：记录每轮评审的反对意见、修改决议、待办项。
异常处理
| 异常情况 | 可能原因 | 应急措施 | 预防方案 |
|---|---|---|---|
| 用户故事无法通过评审 | 需求模糊、多个意图混杂 | 现场拆分为更细粒度故事 | 编写前完成场景清单梳理 |
| 验收条件与开发实现冲突 | 验收条件覆盖了非功能约束或技术不可行项 | 标记为“技术待确认”，会后与架构师协同修正 | 验收条件编写阶段引入技术代表早期参与 |
| 字段约定不一致 | 不同角色对字段含义理解不同 | 立即在评审中口头统一，记录到团队 wiki | 发布《字段定义手册》并定期复盘 |
| 故事过大超过一个 sprint 容量 | 未充分分层拆解 | 垂直切分为多个 MVF（最小可用功能） | 使用“故事切片”练习培养拆解习惯 |
典型陷阱：验收条件写成了“系统应该实现……”，缺乏具体数据和示例。正确做法：
Given 用户已登录且购物车有3件商品
When 用户点击“结算”
Then 系统展示订单总额应为商品价格总和（不含运费）
Given 用户已登录且购物车有3件商品
When 用户点击“结算”
Then 系统展示订单总额应为商品价格总和（不含运费）
验收标准
- 完整性：每个用户故事包含完整的 As a/I want/so that 三要素。
- 可测试性：验收条件至少覆盖 1 条主路径和 1 条异常路径，且每个条件可被独立验证。
- 一致性：同一 Epic 下所有故事的角色和术语保持统一。
- 字段完备性：故事点、优先级、标签、关联 Epic 字段均已填写且符合团队定义。
- 可评审性：故事正文与验收条件可在 5 分钟内被开发/测试人员理解。
需求描述模板（标准输出）
用户故事模板（Jira / ClickUp 条目示例）
标题: [短标识] 作为[角色]，我想要[功能]，以便[价值]
As a [用户角色]
I want [具体功能/行为]
So that [业务价值 / 目的]
验收条件清单:
Given [初始上下文]
When [用户操作]
Then [期望结果]
示例:
Given 用户已登录且个人资料完整度 > 80%
When 用户在个人中心点击“匹配相似用户”
Then 系统返回至少3个与当前用户兴趣标签重合度 ≥ 70% 的其他用户列表
字段约定:
- 故事点: 0.5 / 1 / 2 / 3 / 5 / 8 / 13（非数字则留空）
- 优先级: P0(阻塞) / P1(必须) / P2(重要) / P3(锦上添花)
- 标签: 如 #前端 #API #支付 #数据迁移
- 关联Epic: 填写Epic的ID或名称
- Sprint: (留空，由规划时赋值)
- 负责人: (留空，开发认领后填写)团队对齐动作：将上述模板拷贝到团队协同工具的字段配置中，并作为全局模板启用。所有新创建的需求条目强制从该模板派生。
需求描述规范核心流程图
下图展示了从原始需求到结构化需求描述模板的关键流转路径，团队需严格按照节点顺序执行，避免跳过评审环节。
流程图说明：节点从原始需求开始逐步细化，经过场景拆解、用户故事、验收条件、字段填充到评审。若评审不通过则返回节点3（用户故事编写）或节点4（验收条件）修正。此流程确保了每个需求条目在进入 Backlog 前已具备可交付的契约化描述。