需求用例的写法

一、为什么写需求用例

流程图为需求用例提供了关键路径，而需求用例则是对业务场景的全面还原。本文将从以下四个方面阐述用例的信息：

• 用例的定义
• 用例的粒度
• 用例的例子
• 用例的关键点解释

我写需求文档有几大准则，是需要时刻铭记和实践的：

• 字不如表，表不如图；
• 使用最少的字去描述，多利用各种符号；
• 排版要舒适，不能反人类；
• 尽量无歧义、准确、全面。

二、什么是用例

用例（use case）是系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。所以用例可以简单的理解成业务场景、使用场景。

三、用例的粒度

我们经常在拆解用例的时候，会陷入一个迷思：究竟一个用例要按照什么粒度进行拆分呢？什么样大小的才是一个合适的用例？

用徐峰老师在《有效需求分析》一书中做的用例定义来说：“用例即业务场景，而一个完整的业务场景应该是独立的、可汇报的、可暂停的单元。”

四、一个完整的用例

下面用“取钱”的例子，来展示一个完整的用例要怎么写清楚。

PS：以下为个人的需求模板，每个公司对于需求的描述不尽相同，这里旨在表述清楚用例的关注内容，不做模板的规范定义，有不同观点欢迎探讨交流。

五、用例关键字段解释

功能描述

是对一个用例的概括描述，表述清楚用户和系统需要完成的功能是什么。

优先级

分为4个等级：紧急，高，中，低。根据实际的业务需求来定义用例的优先级。

使用频率

分为高，低。代表该用例在实际的用户操作中属于高频操作还是低频操作，高频操作通常都是关键重要的操作。

前置条件

用户在执行用例之前，系统需要检查什么状态。

主干流程

用例里的流程描述，都是以用户意图为角度来描述的，体现的是用户与系统之间的交互过程。很多时候，我们会陷入一个描述的误区，太过细致的描绘了人机界面，和用户的操作动作，使得流程的描述过于细致和繁琐，不易阅读和提取关键信息。所以，在描述流程中，一定要写明用户做什么，系统做什么。

后置条件

用户在结束用例之前，系统需要检查已确保什么状态。

异常流程

异常流程是在做产品设计过程中是非常重要，但又很容易被忽略的过程。用例分析中应多考虑一些异常情况流程，减少需求评审时的尴尬时刻。

六、布局

列表页面：

各查询项为空，展示占位文本；

后台分页；

默认每页显示10项结果；

列表中可查看所有该登录账户有权限查看的数据；

默认按更新时间排序。

新增页面：

各输入项为空，展示占位文本；

默认选择….

修改页面：本条数据上次成功保存内容。

数据页面：

展示当前实时数据；

默认展示最近7天数据趋势图。

UC000.2：…

UC000.3：…

七、补充说明

需要用户输入的数据项，例如筛选、新建时的输入项

每个输入项需要考虑：

字段名称（简洁、易于理解，注意与概念相似字段进行区分）

是否必填（填写与否有何影响？）

使用组件（从规定的组件库中选取，适当描述组件性质）

占位文本（Input字段，输入框中的占位文字，提示用户可输入的内容）

数据来源（可选选项的来源）

权限限制（用户权限对本字段有无影响？）

字段单位

字段类型（整数、小数、字母、符号等）

字段长度（≤？汉字）

字段范围（数值范围，可否为0？最大为？小数是否自动补齐？）

数据格式

搜索特点（模糊搜索）

可选选项（1- …；2-…）

解释说明（是否需要文字提示用户字段含义或用法）

极限情况（初始状态、极限状态）

可否重复（能否与其他条目的同一字段重复）

可否修改（修改后对本条数据、或其他系统的数据的影响、对客户端的影响；什么时候可以修改）

是否联动（与其他数据、与其他系统、与客户端）

是否排序（排序规则）

展示预览（为空时；输入时；输入完；查看时；列表中；客户端；极限时）

只读字段（不同情况下怎么展示只读）

错误提示（为空或不满足约束条件时的提示语，提示方式）

备注说明

3.4.2 展示/列表项

用户在列表中查看或展示给用户，不能进行操作的数据项

每个展示项需要考虑：

字段名称

字段来源（新建、其他系统）

初始状态（列表、预览、数据报表…）

分页类型（前台or后台，默认一页几条数据）

无数据时（如何展示？）

展示样式（多种情况：为空时、多个值、很长时）

排序规则

备注说明