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

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

  (2010-01-12 11:20:56)

转载▼

标签：  用例   杂谈

分类： 产品设计

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

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

准则二：明确写出“谁控制球”（比喻） 
控球的执行者会做下列事情：自己运球或将球传给别人，在步骤结束时要问问“把球给谁了”。 

准则三：从系统外部的角度来编写用例 
始终站在用户的角度来编写，而不是系统的角度，例如，不要出现这样的描述“系统读取卡号和密码，并从帐号余额中扣除一定的金额”，而要从系统外部的角度来编写，如： 
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）系统自动关闭该页面 

参考资料： 
《编写有效用例》