项目80%的问题，出现在需求阶段
非原话，共勉。80%的需求问题，是需求遗漏或考虑不周，涉及功能范围改动的较少。
存在问题
上级基于公司年度复盘复盘数据，提出来的本年度关键指标
背景
项目的准交率不太理想，测试在最后阶段老是加班加点；
问题基本是PRD引发的，要求提升需求质量；
短期内肯定是无法有质的改变，所以要求控制评审的需求缺陷率，而不是后续的变更率；
现状
现有文档结构，基本上包含：
| 层级 | 名称 | 说明 |
|---|---|---|
| 1 | 功能名称 | 大功能的名称，如考勤管理 |
| 2 | 业务场景 | 描述对应的业务场景，类似用户故事 |
| 业务流程 | 如果有相关的先后顺序，或者多人协作，需要补充 | |
| 界面原型 | 原型截图 | |
| 业务规则 | 包含下面第三层级的内容 | |
| 3 | 系统流程 | 系统上，数据如何流转，或者页面如何切换 |
| 功能说明 | 以功能点为最细颗粒度，逐个说明改动点。一般包含操作前提、操作说明和操作提示三个大块 | |
| 字段说明 | 对应功能页面的字段说明 | |
| 状态说明 | 如果存在状态流转，需定义状态名和状态流转（进入、离开） |
问题
这里面其实有非常多的问题，乍一看就有：
- 对照起来麻烦，原型截图和功能说明远，字段说明和功能说明分离
- 功能说明，格式不够细，不能很好的指导产品人员查漏补缺
- 状态说明在最后面，不利于阅读、理解
因此，应当引入更合理、更细致的格式，辅助产品人员提升需求质量。结合内部自动化测试的倾向，最终决定基于用例的形式，撰写PRD
参考《编写有效用例》一书，进行相关的调整
用例
其实用例这东西，不是单纯测试写的，开发也可以写TestCase。
定义
此处提到的用例，是系统用例，基于功能点去细化内部的逻辑。即：
描述不同条件下，系统对某一项目相关人员的请求所作出的响应
一般UML用例图，更多的体现用户完整动作/愿望（基本都能映射到功能）：
完整模板
<用例名应该是一个用主动语态动词短语来表示的用例目标>
使用语境：<目标较长的描述，如果需要，还包括触发事件>
范围：<设计范围，在设计时将系统作为一个黑盒来考虑>
级别：<概要、用户目标、子功能三者之一>
主执行者：<主执行这的角色名称或主执行者的描述>
项目相关人员和利益：<用例中项目相关人员和关键利益的列表>
前置条件：<我们所希望的，周围环境已经达到的状态>
最小保证：<在所有退出操作前，如何保证得到必须的信息>
成功保证：<目标完成时环境的状态>
触发事件：<什么引发了用例，可能是时间事件>
主成功场景：
<在这里写出从触发事件到目标完成以及清楚的步骤>
<步骤编号#><动作描述>
扩展：
<在这里写出扩展，每次写一个扩展，每一个扩展都指向主场景中的特定步骤>
<被改变步骤><条件>：<动作或子用例>
<被改变步骤><条件>：<动作或子用例>
技术和数据变化列表：
<在这里写出场景中因技术或数据变化而引起的可能分支>
<步骤或变化编号#><变化列表>
<步骤或变化编号#><变化列表>
相关信息
<项目所需要的所有附加信息>
思考
上面的形式，过于冗长，不能平衡效率和质量。
所以要精简范围、级别、主执行者、项目相关人员和利益等，最小宝成和成功保证这种也可省略，放到通用需求中。
另外，大量文字不利于快速阅读，可能会降低效率。所以加入UML相关图形进行描述，配上文字说明
落地模板
1.1业务模块1
1.1.1 应用场景
实际业务中存在的问题，即用户诉求。
1.1.2 业务分析
借助业务流程图，分析上述场景
1.1.3 用例图
归纳出满足用户诉求，系统应该具备的
1.1.1 用例1
1.1.4.1 概要说明
简要介绍该用例的作用和目的
1.1.4.2 事件流
1.1.4.2.1 前置条件
1.1.4.2.2 基本流
1.1.4.2.3 备选流
1.1.4.2.4 特殊需求
1.1.4.2.5 后置条件
1.1.4.3 界面原型
1.1.4.4 测试要点
demo
以CRM里面，常见的客户分配为例：
前置条件：已经成功执行查询用例，查看销售代表负责的客户
触发事件：点击【分配客户】按钮
基本流：
1、在列表分配弹框中，选择自己需要的客户，点击【分配】按钮
2、显示等待中页面
3、服务器处理成功，返回成功信号
4、弹出成功提示“分配成功”
5、刷新客户列表，加载最新的数据
关键节点说明：
| 节点名称 | 活动说明 |
|---|---|
| 显示等待中页面 | 需要前端处理，不能有闪屏的感觉，要有1秒左右的等待 |
备选流：
1a.选择的销售代表已经被停用:
1a1.警告提示“选择的人员已经被停用”
3a.服务器返回错误：
3a1.直接Toast提示
3b.服务器返回分配失败的错误信息：
3b1.弹出警告提示“成功X条，失败Y条。失败原因：”，原因包含以下场景：
依次进行以下检测，并提示原因：
a) 选择业代已被停用，原因提示“选择的人员或岗位已经被停用”；
b) 登录账号已被停用，原因提示“您的账号已经被停用”；
c) 客户已被删除或根据编码找不到客户，原因提示“名称为KKK的客户不存在”；
d) 客户已被停用，原因提示“名称为KKK的客户已经被停用”；
后置条件：执行成功，更新客户的负责人字段
发生频率：初始化时候频繁使用，后续每月使用
对于用例中界面字段的可编辑性、默认值，乃至具体的UI组件类型，需要进行单独说明：
| 字段 | 是否可编辑 | 默认值 | 说明 |
|---|---|---|---|
