首先完成参与者的概述后,下一步就是查找系统的用例了。一开始的用例是非常简单的,毫无疑问您必须数次更改用例直到它们变得稳定为止。如果系统的远景或需求不充分,或者如果系统分析不明确,那么系统的功能也将不清晰。因此,您必须经常问自己是否已经找到了恰当的用例。而且,您必须准备好添加、删除、合并以及分开用例,直到获得最终版本。当详细描述用例后,您就会更好地了解用例了。
查找用例的最好的方法是考虑每个参与者对系统要求什么。请记住,系统只为用户而存在,因此它必须以用户的需求为基础。通过对系统作出的功能需求,您将可以辨认出参与者的许多需求。对于每个参与者(不管是人还是物),请向自己提出以下问题:
-
参与者希望系统执行的主要任务是什么?
-
参与者会在系统中创建、存储、更改、删除或读取数据吗?
-
参与者需要向系统通知突发的外部变更吗?
-
需要通知参与者系统中发生的某些情况吗?
-
参与者将执行系统启动还是关闭?
这些问题的答案代表能识别候选用例的事件流。不是所有问题都能构成单独的用例;有些可能是同一用例的变体。并不是总是很容易区分哪个是变体,哪个是独立的、不同的用例。但是,当详细描述事件流程时,两者的区别就明显了。
除了需求,您的组织的企业模型(也称为业务模型)是确定用例的有价值的输入来源。企业模型描述信息系统如何合并到现有的运作中,从而使您更好地了解系统的环境。您还将发现需要在企业模型中定义的概念,因为它包含了企业的“业务对象”。如果遵循了 业务建模 工作流程,您就会有 业务用例模型 和 业务分析模型 用作输入。
系统可能有数个可能的用例模型。找到“最佳”模型的最好的方法是开发两个或三个模型,选择较喜欢的一个,然后进一步开发。 开发数个备用的模型还可以帮助您更好地了解系统。
概述第一个用例模型后,您应该验证用例模型是否针对了所有功能需求。仔细核对需求,确保所有的用例满足所有的需求。
关于用例是什么以及如何查找用例的更多信息,请参阅指南:用例模型和指南:用例。
指定并简单描述您找到的用例
每个用例都应该有名称,表明它与参与者的交互实现了什么。名称可能必须由几个字组成才能理解。任何两个用例的名称都不能相同。另请参阅指南:用例中的“名称”一节。
写一段用例的简单描述来定义每个用例。在写描述时,请参阅词汇表,如果需要的话请定义新的概念。另请参阅指南:用例中的“简述”一节。
概述事件流程
在此时,您还应该撰写用例的事件流程的第一稿。简单描述每个用例的事件流执行时的瞬间,但不要详细描写。后来指定用例的人(即使是您自己)会需要这个逐步描述的。先从概述事件的基本流程开始,只要您同意添加备用流程。
示例:
“回收机器系统”的“回收项”用例的事件流程的初始的逐步描述看起来可能是这样的:
-
客户按“启动”按钮。
-
客户插入寄存项。
-
系统检查插入的寄存项的类型。
-
系统增加当日收到的项的类型总量。
-
客户按“收据”按钮。
-
系统打印收据。
收集其他需求
系统的某些需求无法分配给具体的用例;请将它们集中在“补充规范”(请参阅工作产品:补充规范)。
|