需求用例文档编写建议 --事件流程（基本流程和扩展流程）部分

每个用例表示用户为实现某个目标与系统的一次交互，而事件流程则是对实现该目标的描述，事件流程包括基本流程（又称为主成功流程）和可选流程（又称为扩展流程）；对这部分的编写应该清晰的描述不同的对象（用户、系统）完成目标的活动序列，例如，像这种方式：球员甲将球传给球员乙，球员乙运球，球员乙将球传给球员丙。

编写一个良好的事件流程有以下准则：

准则一：使用简单语法

主语＋谓语＋宾语，例如： “系统从帐户余额扣除一定数量金额“，简单的语句与用户沟通起来对需求的理解会更准确。

准则二：明确写出“谁控制球”（比喻）

控球的执行者会做下列事情：自己运球或将球传给别人，在步骤结束时要问问“把球给谁了”。

准则三：从系统外部的角度来编写用例

始终站在用户的角度来编写，而不是系统的角度，例如，不要出现这样的描述“系统读取卡号和密码，并从帐号余额中扣除一定的金额”，而要从系统外部的角度来编写，如：

1）用户输入ATM卡并输入密码

2）系统从帐号余额中扣除一定的金额

准则四：描述过程向前推进

每一个步骤都要离目标更进一步，步骤不要太细，也不能太粗，一般对基本流程3-10步是合适的，过多则会使用例文档显得太长。

准则五：描述执行者的意图而不是动作

编写用例常见的问题就是在操作界面来描述，这应该需要避免，例如：

用例1

1） 系统要求用户输入名字；

2） 用户输入名字；

3） 系统要求用户输入地址；

4） 用户输入地址；

5） 用户点击“确认”

6） 系统显示用户简介

修改后：

1） 用户输入名字和地址

2） 系统显示用户简介

虽然在操作界面进行描述能很精确的定义需求，但过多关注细节会花费大量的精力，同时文档也会变得很长，难以维护。

准则六：包含“合理”的活动集

对场景的描述可以把每个部分作为一个单独的执行步骤，也可以以不同的方式合并其中的几个部分，如何分隔要尽量按“是否合理”进行。一个常用的步骤模板如下：

1） 用户向系统发送请求数据

2） 系统验证请求

3） 系统更新内部状态

4） 系统显示成功处理结果

任何用例流程的描述，都可以在上述基础上进行适当的扩展完成。

准则七：“确认”而不是“检查与否”

描述中不要出现“如果”字句，例如

2） 系统检查密码是否正确

3） 如果密码正确，系统显示主页面

要修改为：

2） 系统确认密码正确

3） 系统显示主页面

对于密码错误的流程，则放到可选流程中处理

准则八：习惯描述“循环执行步骤X到Y，直到条件满足”

例如“用户重复步骤3－4，直到完成选购”

准则九：对于可选流程，格式如下：

如准则七的中的例子

2a：无效密码：

1）系统显示登陆失败页面

2b：用户没有响应（超时）

1）系统自动关闭该页面

参考资料：

《编写有效用例》