UseCase事件描述叙事流规范

文化/fasiondog

整理的用例需求编写规范。分享部分UseCase事件描述叙事流规范。其中。标准5~10、12来自哪里《编写有效用例》（[美国] Alistair Cockburn 该）一本书，自身实践和要求。

事件流包括正常事件流、可选事件流、异常事件流程，前述三者合在一起的本质就是用文字描写叙述的流程。

事件流由文字描写叙述的步骤组成，写作过程中应遵循下面准则，这些准则是对用例写作过程中的常见问题和最佳实践的总结。下述规范中如没有特殊说明，事件流同一时候指正常事件流、可选事件流、异常事件流。

准则1：文字描写叙述与流程图保持一致

事件流的本质其实就是文本描写叙述的流程。

因此，对用例辅以说明的流程图应与文字表述的事件流保持一致。其实，用例是以文字描写叙述为主，流程图为辅。编写用例应该养成“先写文字后绘图”的习惯。保持一致意味着：

• 流程图中的动作（含推断）的数量与事件流中的步骤数量一致（因为不同的图形表示方法的限制。最低程度应保证和正常事件流中的步骤数量一致）
• 流程图中的动作（含推断）与事件流中的步骤描写叙述一致

准则2：步骤描写叙述遵循“主+谓+宾”结构

句子的结构应简单明了：“主语+谓语动词+直接宾语”。辅以必要的修饰词。

准则3：一个步骤描写叙述中仅包括一个主语

在一个步骤中仅包括一个主语。这意味着一个步骤描写叙述中能够是一个运行者运行一个动作。也能够是一个运行者运行多个连贯的动作，但不能出现多个运行者运行多个不同的任务。

比如：

错误的描写叙述形式：
1.【用户】输入订购号码，【系统】发现这个号码与本月中奖号码匹配。将用户和订购号码注冊为当月的中奖者，发电子邮件给销售经理，祝贺客户，并告诉他们怎样领取奖金

正确的描写叙述形式1：
1.【用户】输入订购号码。
2.【系统】发现这个号码与本月中奖号码匹配。将用户和订购号码注冊为当月的中奖者，发电子邮件给销售经理，祝贺客户，并告诉他们怎样领取奖金。

正确的描写叙述形式2：
1.【用户】输入订购号码。
2.【系统】发现这个号码与本月的中奖号码匹配。
3.【系统】将用户和订购号码注冊为当月的中奖者。
4.【系统】发电子邮件给销售经理。
5.【系统】祝贺客户，并告诉他们怎样领取奖金。

在编写用例时，能够依据此准则。对较冗长的多个步骤进行合理的合并。所谓合理，是指合并后的步骤。应不影响可选事件流、异常事件流的插入点。

准则4：在步骤中明白标识參与人

通过在步骤中使用“【參与人】”的方式明白标识“參与人（Actor）”，防止因遗漏主语（以及部分宾语），而使读者不知道谁是活动的运行者。演示样例：

“【用户】插入ATM卡并输入PIN。”

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

缺少经验的用例编写者（尤其是对系统内部实现有所了解的开发者）在描写叙述用例场景时。常常有意或无意实现系统内部结构并试图从系统内部动作来描写叙述系统。他们可能写出这种句子“读取ATM卡和PIN号码。并从账户剩余金额中扣除一定数量。”

而从系统外部来编写用例，则是：

1.【用户】插入ATM卡并输入PIN号码；
2.【系统】从账户剩余金额中扣除一定数量。

准则6：显示过程向前推移

选择过小的步骤将导致用例过长。假设一个用例有13~17个步骤。说明每个步骤完毕的工作过少。假设将一些小的步骤合并。能够使用例的可读性更好、更清晰。而且保持原有的基本信息。一般，一个用例的步骤数量应控制在7个以内。

为了有效合并用例步骤，应找到具有较高层次目标的步骤。能够提出这种问题“为什么參与人须要做这件事？”。可能。须要多次询问此问题才干得到惬意的答案，而这个问题的答案就是步骤实现的目标。

下面是一个通过问“为什么”来提高目标层次的样例。

“用户按下Tab键”

为什么用户要按下Tab键？是为了将焦点移到地址框中。

为什么她要将焦点移到地址框中呢？由于在系统開始工作前。她要输入username和地址。她想让系统完毕一些工作，为了使系统工作，她必须输入她的username和地址。

因此，一个清晰描写叙述过程向前移动的主动语态句子是：

“【用户】输入名字和地址”

准则7：显示參与人的意图而不是动作

通过操纵用户界面来描写叙述用户的动作，这是编写用例时常见的一种严重错误，它使得编写的目标处于一个非常低的层次。界面细节描写叙述使得需求文档质量变差，主要体如今：

• 文档冗长拖沓使阅读困难、维护费用高昂。

• 不论什么用户界面的变化都将导致用例文档失效

通常情况下。当一些连续步骤的数据在同一方向上运动时。能够将这些步骤合并成一个步骤（视情况而定。合理合并）。如以下的演示样例及对它的改动：

改动前：
1.【系统】要求用户输入姓名
2.【用户】输入姓名
3.【系统】要求用户输入地址
4.【用户】输入地址
5.【用户】点击“确定”
6.【系统】显示用户的简单介绍

改动后：
1.【用户】输入姓名与地址
2.【系统】显示用户的简单介绍

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

大家常常会遇到描写叙述系统检查某个条件的步骤。而在步骤描写叙述中，使用“检查”这个动词并不好，这样说并没有让过程明显的向前发展，它并非真正的目的，同一时候它使得检查的结果是不确定的。那么为什么系统要检查条件？答案是为了确认、验证或确保某些事情。

这些都是非常好的能够表示目标的动词。比如。能够将“系统检查password是否正确”替换为：

“【系统】验证password正确”

准则9：习惯用语：“用户让系统A与系统B交互”

在编写用例时。可能会遇到例如以下情况，正在设计的系统A须要从系统B中获取信息。或者与系统B有一个交互过程。

通常能够使用两个步骤来描写叙述：

1.【用户】通知【系统A】从【系统B】获取数据
2.【系统A】从【系统B】获取后台数据。

上述写法尽管能够接受。但在某些情况下显得笨拙和冗余，尤其是用例比較复杂时。更好的写法例如以下：

1.【用户】命令【系统A】从【系统B】获取后台数据

准则10：习惯用语：“循环运行步骤X到Y，直到条件满足”

有时候，我们会遇到须要反复的步骤。

对于仅仅有一个步骤须要反复。能够直接在步骤中描写叙述，如：“【用户】在各种各样的产品文件夹中寻找、直到发现所须要的产品。”

对于多个步骤须要反复的情况，能够把表达反复运行的语句放在这些反复步骤的前面或后面。比如：

1.【客户】提供账号或名字和地址
2.【系统】查出客户的爱好信息
3.【客户】选择一个商品，并做上购买的标记
4.【系统】将该商品增加客户的“购物车”中
  客户反复步骤3、4，直到客户指明自己完毕了选购
5.【客户】购买全部在“购物车”中的商品

还有一种形式：
1.【客户】提供账号或名字和地址
2.【系统】查出客户的爱好信息
  步骤3、4可反复运行
3.【客户】选择一个商品，并做上购买的标记
4.【系统】将该商品增加客户的“购物车”中
5.【客户】购买全部在“购物车”中的商品

注意：在表达反复语句前面不须要加上序号。

准则11：命名可选与异常事件流分支

为可选事件流、异常事件流中的分支进行适当的命名。有助于測试和理解。通过简单的命名，有利于检视分支的覆盖情况，保证全部的分支情况都得到了处理。

比如某系统登录时的异常事件流：

5a.（录入password方式认证失败）假设password方式认证失败，返回步骤3
5b.（连续输入password错误限制）假设连续3次输出password错误，则锁定登录。用例结束。

5c.（录入指纹方式认证失败）假设指纹认证方式失败，返回步骤3a

准则12：条件处理的缩排方式

缩进那些指明条件怎样处理的运行步骤，并在字母后又一次从编号1開始。运行步骤遵循前面的准则。

演示样例：

5a.假设输入password错误：
  5a1.（password错误）假设password错误。系统提示错误信息，返回步骤4。
  5a2.（连续password错误限制）假设连续3次输入password错误。账户锁死。用例结束。
  5a3.（累计password错误限制）假设当日password错误达到10次，账户锁死，用例结束。

准则13：同一条件处理的分支应在一起

提出此准则的原因是在某些条件处理的分支中，被分别放置在可选事件流和异常事件流中，影响阅读和理解，也不利于检视发现错误。

错误的示比例如以下：
正常事件流:
……
3.柜面通过核心系统检验账户支取方式为预留password；
……
可选事件流：
3a．柜面通过核心系统检验账户支取方式为印鉴——
  3a1．柜面提示“请检查密封”
  3a2．柜员后检查凭证，单击提交随机密钥，回报6

修改后，它是统一的事件的替代流:
可选的事件流：
3a．（印章的方式平局）账户取款设定方式斩：
  3a1．【系统】提示客户检查凭证；
  3a2．【出纳员】检查签名后，。确认提交系统，运行步骤6。
3b．（税票秘密，画画等有效证件）假设占非印度秘密的方式绘制，画画等有效证件，【系统】提示“税票秘密帐户不支持的金融账户开放”，用例结束。