第3章 用户故事编写：As a / I want / So that 格式与验收条件

用户场景

以某电商平台“优惠券使用”功能为例。用户完成商品选择后进入结账页面，期望输入优惠券码立即获得折扣。当前流程在用户点击“提交订单”后才提示优惠券失效，无法提前抵用，导致大量用户放弃结算。

业务问题

• 结账流程缺乏优惠券应用入口，用户需跳转到个人中心手动复制券码再返回，操作路径过长。
• 后台优惠券验证逻辑与订单提交耦合，无法在用户输入时实时反馈有效性。
• 优惠券使用率低于行业均值（15% vs 32%），月损失约120万元潜在GMV。

需求拆解

初始用户故事：

该故事颗粒度过大，属于“史诗故事”。按功能边界拆解为5个子故事：

• 作为购物者，我希望在结账页面看到优惠券输入框，以便知道此处可应用优惠。
• 作为购物者，我输入优惠券码后希望看到实时验证结果，以便确认券是否可用。
• 作为购物者，验证通过后我希望订单金额自动更新，以便确认优惠已生效。
• 作为购物者，我希望看到优惠券应用失败的具体原因，以便修正或切换券码。
• 作为购物者，已使用的优惠券应标记为“已使用”，避免重复使用。

方案表达

通过故事拆解颗粒度（如上表），团队可精确估算开发工作量，避免史诗故事过大导致延期风险。

指标验证

• 优惠券输入框可见率 ≥ 98%（埋点统计结账页曝光量）
• 优惠券实时验证成功率 ≥ 99.5%
• 优惠券使用率从15%提升至≥28%
• 用户输入券码到金额更新的平均响应时间 ≤ 500ms

验收标准

采用Given-When-Then + 额外验收条件的格式：

故事地图

将拆解后的子故事按用户旅程和时间顺序排列，形成故事地图，用于规划发布节奏：

验收条件附加

每个子故事必须在卡片中附加“验收条件块”，包含：

• 前置条件（数据库状态、用户登录、商品存在）
• 操作步骤（精确到UI元素和点击/输入）
• 预期结果（数值变化、提示文案、跳转）
• 性能底线（响应时间、并发容量）

示例（输入框展示子故事）：

交付物模板

本章交付物包括：

PRD片段中对“输入框展示”子故事的具体写法示例（YAML格式）：

story-id: US-COUP-001
title: 结账页面展示优惠券输入框
actor: 购物者
-capability: 在结账页面看到优惠券输入框
value: 知道此处可输入优惠券
acceptance-criteria:
  - "登录用户在结账页面，输入框出现在订单金额下方"
  - "输入框标签为'优惠券码'，按钮为'应用'"
  - "未登录用户不显示"
  - "输入框在所有设备上响应式适配"
points: 2
prototype: https://link.to.mockup/checkout-coupon
release: v1.0-sprint-2

原型说明要点：在结账页面原型中添加注释，明确输入框的默认状态（空）、输入后状态（字符下画线）和应用按钮的点击热区（不小于44px）。金额更新区域需使用动态面板，验证通过后显示新的订单总额并添加“已优惠XX元”提示。

验收要点：测试用例需包括：①输入有效券码并点击应用→金额更新、券标记已用；②输入失效券码→红色错误提示且金额不变；③网络断开时点击应用→toast“网络异常，请重试”；④快速连续点击两次应用→只触发一次验证，防重复提交；⑤输入框未填写时点击应用→弱提示“请输入优惠券码”。