第四章 需求描述标准写法：用户故事格式、验收条件编写、边界与异常说明、优先级标识
需求描述的规范性直接影响团队对需求的理解一致性和后续开发测试效率。本章围绕用户故事格式、验收条件、边界与异常、优先级标识四个核心维度，建立可复用的标准写法流程。
适用场景
- 产品团队需向开发、测试、UI等角色传递明确需求时
- 需求条目需要统一模板以降低沟通成本时
- 需求评审前需确保描述完整、优先级清晰时
- 需求库（如Jira、Confluence）需要标准化录入时
前置条件
- 已确定需求条目所属Epic或Feature
- 已识别目标用户角色（如“注册用户”、“管理员”）
- 已明确该需求的业务价值
- 团队已约定用户故事模板（如标准Connextra模板）
操作步骤
- 编写用户故事：采用标准格式“作为<角色>，我想要<功能>，以便<价值>”。
- 定义验收条件：列出至少3~5条可验证的场景，每条以Given-When-Then结构描述。
- 补充边界与异常：明确输入范围、数据限制、错误反馈、并发风险、系统降级行为等。
- 标识优先级：按照MoSCoW或P0-P3体系标记，并注明依赖关系。
- 同行评审：由另一名PO或技术负责人检查描述完整性。
团队约定： 用户故事中的“价值”应避免使用“系统能够”、“支持”等模糊词汇，必须指向具体用户收益。
输入输出物
| 类型 | 输入物 | 输出物 |
|---|---|---|
| 用户故事 | Epic/Feature 描述、用户角色模板 | 标准用户故事文本（As a/ I want/ So that） |
| 验收条件 | 用户故事、业务规则文档 | Given-When-Then 场景列表（3~8条） |
| 边界与异常 | 技术约束文档、历史缺陷记录 | 边界值描述、异常响应策略 |
| 优先级 | 业务价值评估、依赖关系图 | 优先级标签（P0/P1/P2/P3 或 Must/Should/Could/Won't） |
责任边界
- 产品经理（PO）： 负责用户故事编写、优先级设定、验收条件初步定义。
- 技术负责人： 补充边界与异常（尤其涉及系统性能、并发、安全）。
- QA代表： 验证验收条件的可测性，补充缺失的负面场景。
- 团队所有成员： 参与评审，确保需求理解一致。
记录材料
- 需求条目卡： 包含编号、标题、用户故事、验收条件、边界异常、优先级、状态。
- 需求评审纪要： 记录评审时间、参与人、未达成一致项及待办。
- 需求变更日志： 任何对上述四要素的修改均需记录变更原因和版本。
异常处理
| 异常情况 | 处理方式 |
|---|---|
| 用户故事价值描述模糊 | 退回到PO，要求用“用户痛点在XX场景下得到解决”重写 |
| 验收条件与用户故事不直接相关 | 删除无关条件，补充能验证故事价值的核心场景 |
| 边界/异常完全缺失 | 技术负责人必须提供至少2个边界值场景，否则不允许进入开发 |
| 优先级冲突（如两个故事均标记P0但资源冲突） | 由PO和Scrum Master协调，调整其中一个为P1或拆分 |
验收标准
- 用户故事遵循“As a …, I want …, so that …”格式，角色、功能、价值均无歧义。
- 验收条件覆盖正向、负向、边界三类场景，每条条件可独立测试。
- 边界与异常说明至少包含：数值上限/下限、空值处理、网络超时、并发写入冲突。
- 优先级标签清晰，且与依赖关系一致（如被依赖的条目优先于依赖者）。
- 以上四项全部通过同行评审，评审意见记录在需求库或协作平台。
团队常见误区： 验收条件写成“系统应能正确处理用户输入”这种无法精确定义的短语。正确写法应包含具体前置条件、操作动作和期望结果，例如：
Given 用户已登录且购物车为空
When 用户点击“清空历史记录”
Then 系统弹窗提示“确认清空？”，不触发后台数据删除