用例分析
大部分面向对象软件设计方法学都采用了自己独有的任务分析形式。这些分析技术包括用例，场景和脚本。这些技术中的任何一个都可以用来确定和归档用户需求。因为用例分析技术是最流行的方法之一，所以本文详述这一部分。
用例定义了系统应该提供的功能。它通常用于开发者和用户之间的关于系统的约定，这样使得非开发人员也可以理解。用例模型从用户角度定义了系统。模型使用角色来代表用户担当的成分，使用用例来表示用户在系统中完成的事情。从用户的角度看，每个用例都是系统中事件的一个完整过程。
决定角色
角色用来模型化预期的用户。角色代表了一个用户类型或类别（如上图），当一个用户做某些事情，他或她就成了这个类型的一个存在案例。一个用户可以作为（担当）几个不同的角色。因此，角色定义了客户能够担当的成分。
角色用来对系统的信息交换进行模型化。它能够用来模型化客户或者被设计的系统交互的其他系统。参与者组成了被设计系统的外部环境。可以将角色当做一个类，即，行为的描述。用户可以承担多个成分，即，可作为多个角色。
直接使用系统的角色叫做初级角色，例如，在宾馆预订系统中的前台接待人员就是初级角色。因为有二级角色，所以只有初级角色才能使用系统。在宾馆预订系统里旅客不直接使用系统，所以是二级角色。
详细用例说明
在定义了系统的外部环境后，可以利用详细说明用例来定义系统内部的功能。一个用例是一个完整的事件集，说明发生在角色和系统之间的交互。被收集用例的整个集合说明了使用系统的所有已有的方法。
角色对于找出用例是有用的。每一个角色都会执行系统里的一些用例。通过遍历所有角色和定义他们能够使用系统所做的每一件事，可以定义系统的完整功能集。
用例的构建可以通过和用户会面，要求他们描述他们所执行的任务。用例是这些任务的文本描述。用例中的名词作为系统的潜在对象用下划线表示。最重要的对象用下划线表示并且粗体显示，如下文，用例场景应该描述当新系统运行时用户如何做他们的工作。
旅客需要预定宾馆房间。宾馆在有空房间的情况下，接受尽可能多的预定。当旅客到达时，接待人员接待他们。接待人员按照预定记录核实旅客提供的细节。有时，在旅客到达前没有进行预定。有些旅客希望住进无烟房间。
Weinschenk等人推荐生成高效用例场景的指导如下。可以增量生成用例。可以集中在特定的任务范围，为每一个范围生成各自的用例，然后把它们联合起来生成一个完整的需求模型。增量式开发可以帮助把工作分成可管理的片断并且可以支持多个分析人员并行工作。
- 从用户的观点来制定，而不是系统的观点。
- 保证从用户的关键任务开始
- 包括频率信息
- 对重要任务做注释
【用例名称】
一般情况下，用例的名称即需求的名称。
【场景】
场景即用例发生的环境，正好对应5W中的3个W：Who、Where、When
【用例描述】
描述详细的用例内容，对应5W中的What和How，即用户应该怎样做，以及每个步骤中的输出。但并不要求每个步骤都一定有输出，可以有也可以没有，也可以有多个。
【用例价值】
描述用例对应的客户价值，对应5W中的Why。
【约束和限制】
即整个需求流程中相关的约束和限制条件，对应518方法中的8C。
我们来看一个简单的样例：POS机。
【第一步：正常处理】
| 【用例名称】 买单 【场景】 Who：顾客、收银员 Where：商店的收银台 When：营业时间 【用例描述】 1. 顾客携带选择好的商品到收银台； 2. 收银员逐一扫描商品条形码，系统根据条形码查询商品信息； 3. 扫描完毕，系统显示商品总额，收银员告诉顾客商品总额； 4. 顾客将钱交给收银员； 5. 收银员清点钱数，输入收到的款额，系统给出找零的数目； 6. 收银员将找零的钱还给顾客，并打印小票； 7. 买单完成，顾客携带商品和小票离开； 【用例价值】 顾客买完单以后，就可以携带商品离开，而超市也将得到收入； 【约束和限制】 1. POS机必须符合国标XXX； 2. 键盘使用中文，因为收银员都是中国人； 3. 一次买单数额不能超过99999RMB； 4. POS机要非常稳定，至少一天内不要出现故障； |
【第二步：异常处理】
在第一步的基础上，我们增加相关步骤的异常情况说明和处理，例如如下的黑体字：
| 【用例名称】 买单 【场景】 Who：顾客、收银员 Where：商店的收银台 When：营业时间 【用例描述】 1. 顾客携带选择好的商品到收银台； （这一步没有异常） 2. 收银员逐一扫描商品条形码，系统根据条形码查询商品信息； 2.1 扫描仪坏了，必须支持手工输入条形码； 2.2 商品的条形码无法扫描，必须支持手工输入条形码； 2.3 条形码能够扫描，但查询不到信息，需要收银员和顾客沟通，放弃购买此产品 3. 扫描完毕，系统显示商品总额，收银员告诉顾客商品总额； （这一步没有异常） 4. 顾客将钱交给收银员； 4.1 顾客的钱不够，顾客和收银员沟通，删除某商品； 4.2 顾客的钱不够，顾客和收银员沟通，删除某类商品中的一个或几个（例如买了5包烟，去掉两包） 4.3 顾客觉得某个商品价格太高，要求删除某商品； 5. 收银员清点钱数，输入收到的款额，系统给出找零的数目； （这一步没有异常） 6. 收银员将找零的钱还给顾客，并打印小票； 7. 买单完成，顾客携带商品和小票离开； 【用例价值】 顾客买完单以后，就可以携带商品离开，而超市也将得到收入； 【约束和限制】 1. POS机必须符合国标XXX； 2. 键盘使用中文，因为收银员都是中国人； 3. 一次买单数额不能超过99999RMB； 4. POS机要非常稳定，至少一天内不要出现故障； |
有的人可能会认为第3、第5、第6步都应该有异常，例如系统坏了应该怎么处理。
但实际上我们没有必要这么写，因为用例分析的目的是为了详细分析为了实现客户价值，系统应该怎么做，如果系统本身都坏了，这个就不是用例关注的内容了。
需要注意的是：用例分析中的“异常”是指流程的异常情况，而不包含系统本身的的异常。
【第三步：替代处理】
在第二步的基础上，我们增加替代处理。即：有的步骤可以换一种方式来实现。例如如下用例中的付款方式，可以有信用卡支付、会员卡支付、购物卡支付等。
| 【用例名称】 买单 【场景】 Who：顾客、收银员 Where：商店的收银台 When：营业时间 【用例描述】 1. 顾客携带选择好的商品到收银台； （这一步没有异常） 2. 收银员逐一扫描商品条形码，系统根据条形码查询商品信息； 2.1 扫描仪坏了，必须支持手工输入条形码； 2.2 商品的条形码无法扫描，必须支持手工输入条形码； 2.3 条形码能够扫描，但查询不到信息，需要收银员和顾客沟通，放弃购买此产品 3. 扫描完毕，系统显示商品总额，收银员告诉顾客商品总额； （这一步没有异常） 4. 顾客将钱交给收银员； 4.1 顾客的钱不够，顾客和收银员沟通，删除某商品； 4.2 顾客的钱不够，顾客和收银员沟通，删除某类商品中的一个或几个（例如买了5包烟，去掉两包） 4.3 顾客觉得某个商品价格太高，要求删除某商品； 4-A：顾客使用信用卡支付 4-A.1 信用卡支付流程（请读者自行思考完善，可以写在这里，如果太多，也可以另外写一个子用例） 4-B：顾客使用购物卡支付 4-B.1 购物卡支付流程 4-C：顾客使用会员卡积分支付 4-C.1 会员卡积分支付流程 5. 收银员清点钱数，输入收到的款额，系统给出找零的数目； （这一步没有异常） 6. 收银员将找零的钱还给顾客，并打印小票； 7. 买单完成，顾客携带商品和小票离开； 【用例价值】 顾客买完单以后，就可以携带商品离开，而超市也将得到收入； 【约束和限制】 1. POS机必须符合国标XXX； 2. 键盘使用中文，因为收银员都是中国人； 3. 一次买单数额不能超过99999RMB； 4. POS机要非常稳定，至少一天内不要出现故障； |
- 点赞
- 收藏
- 关注作者
评论（0）