翻译：基本用例模板、例子和用法

最近因为开始新的项目,准备给项目组的兄弟们做个用例的培训,便于交流的同时,在使用中希望他们因为这种前期的深度参与了解需求更加全面和深刻,在后面的开发执行中少走弯路.

作为培训教材,翻译了国外比较有名的写用例书作者的模板和例子,分享给可能需要的人.虽然web2.0的时代讲究快速敏捷开发,一般不采用这么厚重的需求分析方式,但是这中间的设计思路和方向依然是有效率的借鉴.

同时强烈推荐大家好好看看后面关于如何按需、分步使用用例部分的说明.更加具有现实的操作借鉴意义.

英文原文地址


中文如下(说明的导语就不啰嗦翻译了):

用例: 《号码》 《名称应该是简短的动词词组》

--------------------------------------------------

基本信息：

目标描述: 《a longer statement of the goal, if needed》

范围: 《what system is being considered black-box under design》

层级: 《one of: Summary, Primary task, Subfunction》

前提条件: 《what we expect is already the state of the world》

成功的结束条件: 《the state of the world upon successful completion》

失败的结束条件: 《the state of the world if goal abandoned》

主要角色: 《a role name for the primary actor, or description》

用例触发器: 《the action upon the system that starts the use case, may be time event》

----------------------------------------

主要的成功场景：

《从触发到目标达成的步骤。以及此后的清理步骤》

《步骤 #》 《行为描述》

----------------------

扩展：

《扩展放在这里，每次一个，每个指向到主要场景中的步骤》

《替代步骤》 《条件》 : 《行为或者子用例》

--------------------

子变体（译注：执行任务的不同可能。如果有哪位有合适的译法，请不吝赐教）：

《将会导致场景分支的子变体放在这里》

《步骤或者变体# 》 《子变体的列表》

----------------------

关联信息 (可选)

优先级: 《how critical to your system / organization》

性能目标: 《the amount of time this use case should take》

发生频率: 《how often it is expected to happen》

上级用例: 《可选,包含此用例的用例名称》

下级用例: 《可选, 此用例的子用例》

主要角色的相关信息: 《如. 交互, 静态文件, 数据库》

次要角色: 《完成用例需要的其他角色》

次要角色信息: 《如. 交互, 静态文件, 数据库, timeout》
（译者注：这里的timeout没找到合适的词，原样保留，希望方家指导）

----------------------------

现存问题 (可选)

《关于本用例待讨论的问题》

---------------------------

日程：

到期时间: 《date or release of deployment》

...any other schedule / staffing information you need...

例子:

用例: 5 购买物品

--------------------------------------------------

基本信息：

目标: 用户向公司直接提交请求，希望所购物品送达并支付。

范围: 公司

层级: 概要

前提条件: 我们知道用户的及其地址等。

成功的结束条件: 用户拿到物品，我们收到物品的钱。

失败的结束条件: 物品没有送达，用户没有支付。

主要角色: 用户, 为用户执行的任何代理（或者计算机）

用例触发器: 购买需求进入公司

----------------------------------------

主要的成功场景：

1. 用户提出购买请求

2. 公司获知用户的姓名、地址、想要购买的商品等。

3. 公司告知用户关于商品、价格、送达日期等信息。

4. 用户下订单。

5. 公司创建订单、递交物品给用户

6. 公司递送发货单给用户。

7. 用户支付货单。

----------------------

扩展：

3a. 公司没有部分所购物品的存货：

3a1. 订单重新谈判

4a. 用户信用卡直接支付：

4a1. 接受信用卡支付(用例44)

7a. 用户退货：

7a. 处理退货 (用例105)

--------------------

子变体

1. 用户购买方式：

电话,

传真,

互联网订单,

电子数据交换

7. 用户支付手段：

现金或者汇票

支票

信用卡

----------------------

相关信息：

优先级: 最高

性能目标: 5分钟内响应订购，45天内支付。

发生频率: 200次/天

上级用例: 用户关系管理 (用例2)

下级用例:

创建订单 (用例15)

接收信用卡支付 (用例 44)

处理退货 (用例105)

主要角色的相关信息: 可能是电话、文件或者交互

次要角色: 信用卡公司、银行、快递公司

次要角色的相关信息:

----------------------------

现存问题：

只有部分订单的情况怎么办？

信用卡被盗怎么办？

---------------------------

日程：

到期时间: 版本 release 1.0

裁减、分期使用模板

我（译者注：原作者，其实也包括译者本身）和其他人的经验表明，在项目的早期，这个模板太过复杂，难以一次完成。所以项目的开始阶段最好使用较少的信息，因此，有了下面的剪裁：

1. 在不同的需求获取期间填充模板。下面是一个填充顺序的例子。首先，填充对于所有用例你都首先需要考虑的内容：

用例: 《number》 《the name should be the goal as a short active verb phrase》

目标: 《a longer statement of the goal, if needed》

范围: 《what system is being considered black-box under design》

层级: 《one of: Summary, Primary task, Subfunction》

主要角色: 《a role name for the primary actor, or description》

优先级: 《how critical to your system / organization》

使用频率: 《how often it is expected to happen》

2. 回顾完成的情况。思考、检验。是否能够合并、删除一些？ 是否能够分离出一些应该同时考虑的或者放在以后？对于目前将要实施的东西，继续下面的工作:

触发器: 《the action upon the system that starts the use case, may be time event》

主要的成功场景

3. 到此为止，就有了足够的信息来评估整个项目的范围、查找意外事件了。在描述系统的功能之前，还需要完成：

扩展

子变体

上级用例: 《optional, name of use case that includes this one》

下级用例: 《optional, depending on tools, links to sub.use cases》

4. 到此为止，系统的功能基本了解了。最后估算之前，完成下面这些：

性能目标: 《the amount of time this use case should take》

现存问题

日程

5. 如果实在项目评估的最后阶段，需要明确所有需要设计界面的部分。

主要角色信息: 《e.g. interactive, static files, database》

次要角色: 《list of other systems needed to accomplish use case》

次要角色信息: 《e.g. interactive, static, file, database, timeout》