用户故事描述规范

前言：用户故事格式

故事标题
用户故事标题

描述内容
作为[用户角色或岗位]，通过[完成活动]，以便于[实现什么目的或价值]

业务规则

1. 业务规则1
2. 业务规则2
3. ......
   
   测试规则
4. 测试描述1
5. 测试描述2
6. ......
   
   方案(原型)链接
   blog.luluvip.cn/
   
   

一、故事标题

用户故事的描述在列表中进行管理时，不利于快速理解，也不能一行展示。为每个故事取个标题（名字）就很有必要。

类似邮件的主题，用户故事的标题是为了让读者能快速了解这个用户故事的要点和大致范围；怎么写好标题也是有章可循的。 常见的做法有：

1. 用户角度的动宾短语

如：创建商品、输入名称、修改头像等等这是动作+对象形式，擅长描述从用户看到的活动或功能。

2. 系统角度的动宾短语

此处的系统是指待开发的对象。

如，toast提示网络异常，记录用户访问次数，显示搜索结果，显示倒计时。擅长描述系统要执行的反馈和操作。

3. 主谓宾短语

有时动宾短语不能推断主语时使用主谓宾短句，或者可能有可能混淆时需要明确主语，此时就需要增加动作主语，如，超级管理员重置普通管理员的口令；A系统推送批量客户和合同信息。

随着时间推移，新增的用户故事有不少是基于原有的功能来再提升修改，这时往往要在标题里加上状语来区分，比如根据客户所在城市来查询客户列表，在客户没有登记电话号码时强制客户登记号码。 状语要清晰得说明用户故事所处的情况，能够区分类似的用户故事。

二、故事描述

固定格式“作为……（用户角色），我想要……（完成活动），以便于……（实现价值）”的格式。故事描述一这种三段式表述，相比较于传统需求表述，体现了需求方和需求价值的重要性，也为保证了需求描述的可协商性。

三、业务规则描述

为了完成故事，有时需要制定故事的实现规则，涉及的名词定义等。规则描述由产品经理初步制定，在故事讨论后，进行修订确认。写作方式就是一条条穷举列出。注意这里不涉及原型页面和交互规则。

四、测试规则描述

为了避免用户故事误读，让抽象的需求变得具体和可测试，需要制定对应测试验收规则，测试规则可描述此用户故事被实现时需要满足的条件（如检查按钮是否存在，主体业务规则是否生效），不需要描述成很详细的测试用例

五、原型方案

方案文件一般为附件或原型链接。

参考文章：点击进入