查找业务参与者
业务参与者可以是与业务交互的任何个人、小组、组织、公司或机器,例如:
如果您打算建模的业务是大型公司的一部分,这些类别还可以包含诸如以下的业务参与者:
要考虑业务建模的范围和您定义为“目标组织”的业务的边界,这很重要。如果您只选择了业务的一部分作为目标组织,那么同一家公司的其他部分也将是业务参与者。 命名每个业务参与者,采用的命名方式是其名称代表它在业务中的角色。通过编写简要描述定义每个业务参与者,该简要描述考虑到参与者的职责及其与业务交互的原因,包括业务参与者想从业务中获得的附加价值的类型。 |
要查找主要业务用例,请考虑每个业务参与者从业务接收到的价值。问您自己:业务参与者期望从业务中接收到什么服务。它可能有助于以核心业务用例开始 - 核心业务用例即那些服务于客户(在不存在贸易交互的情况下则服务于客户的等同对象)的用例。 研究业务参与者的生命周期是有帮助的,它可以确定以下问题的答案:
从支持业务的角度,流程也可以表示为业务用例。问您自己:为了向客户交付产品和服务,什么是必需的。当然,业务建模的范围以及定义的业务建模目标将确定支持业务用例的详细程度(如果您打算考虑它们的话)。寻找以下种类的流程:
从管理业务的角度出发,流程可以表示为业务用例,尽管从信息系统方面来讲很少会对它们感兴趣。要确定管理流程,请寻找与将业务作为一个整体管理相关联的任务,以及通常与所有者参与者交互的任务。考虑所有者参与者从业务中接收到的内容。搜索可实现以下目标的任务:
此类流程的生命周期常常跨越一个财政年度。 确定业务用例的另一个方法是让领域专家描述现有业务中的每项任务。 然后将这些任务分组为已命名并进行了简要描述的业务用例。
|
复审所有已描述的业务目标,并考虑业务用例是否会支持这些目标。如果您发现业务用例支持两个完全不同的目标,您可以考虑将该用例分成两部分。如果业务用例支持差别很大的业务目标,您将发现很难度量或改善其性能。不支持任何已确定的业务目标的业务用例可能是不必要的。另一方面,这些业务用例的进一步调查可能揭示未发现的业务目标。 还必须与业务参与者相比较来考虑业务目标。确定的业务目标是否将业务朝这些目标计划要包含的业务参与者的方向推进? 是否存在业务目标未针对的任何业务参与者? 在此分析期间还可能发现新的业务目标。
|
一旦您确定了业务参与者和业务用例,您必须划分那些能引起高度兴趣从而必须详细描述的业务用例的优先级。要确定高优先级的业务用例:
|
为理解业务用例的目的,您常常需要工作流程的分步概述。将在随后指定业务用例的人员也将需要此分步描述。 例如,业务用例“个人检入”的分步工作流程描述的第一稿可能看起来如下:
请注意,这是第一稿,因此它可能缺少一些任务,这些任务将在以后发现。您还可以将备用流程包含在这组初始步骤中。 第一稿使人们可以清晰地了解:业务用例将做什么,何时开始,何时结束,它提供什么价值。通常,您为业务用例定义粗略的分步概述的时间不会超过一个小时。(但支持业务用例和管理业务用例的概述除外 - 它们通常并不泾渭分明。) 重点关注最重要的业务用例 - 也就是,代表最高改进可能的用例。是否可以增加业务用例的范围,以便最初由客户执行的工作或者无人执行的工作现在由目标组织执行? 是否可以缩小范围,以便客户现在将执行先前由目标组织执行的任务? 如果一个业务用例能更好地为客户提供服务,则该用例得到了改进,这暗示它变得更简单,能生产更好的产品,提供更短的前导时间,等等。“客户应该能够直接接触业务的核心部分”。 对于每个业务用例,设置可度量的目标,这些目标可以用来验证您是否已成功。随后这些业务目标可以进行优化,并转换成其他业务目标,以及转换成业务策略。当建立新的目标组织时,业务目标可用来持续地度量业务用例如何运行,如何改进。
|
确定那些与业务用例交互的业务参与者,方法是定义它们之间的通信关联。如果显示谁启动通信是很重要的,则您可以向关联添加可导航性。如果它改进了模型的可读性,您还可以命名该关联。
|
如果您有许多业务用例,您可以将它们分成各个包,以使文档易于理解。例如,可以根据类型(例如市场、法规实体和合作伙伴)封装业务参与者。业务用例可以根据目的分组,例如销售和市场、产品开发以及管理。另外,它们也可以根据业务参与者分组,例如股东和投资者或直接消费者。 |
用例图说明业务参与者、业务用例及其关系的组合。图可以包含任何以下内容:
请注意最重要业务用例的图可以充当完整业务用例模型的摘要,从而证明对其进行复审是有帮助的。 |
业务用例模型的调查描述需要表述以下信息:
|
在此状态下,请确保检查业务用例模型,以验证您的工作是否处在正轨。但是,不要详细地复审模型。您还必须在对业务用例模型进行操作时考虑业务用例模型的核对表。相关各方必须确定:
|