如何查找业务用例和业务执行者

简介:

查找业务参与者  

业务参与者可以是与业务交互的任何个人、小组、组织、公司或机器,例如:

  • 客户
  • 合作伙伴
  • 供应商
  • 权威机构(法律、法规等等)
  • 子公司
  • 所有者和投资者(决定董事会是应为业务的一部分,还是应建模为参与者。)
  • 业务以外的信息系统

如果您打算建模的业务是大型公司的一部分,这些类别还可以包含诸如以下的业务参与者:

  • 公司的其他部分
  • 其他部门内的个别角色

要考虑业务建模的范围和您定义为“目标组织”的业务的边界,这很重要。如果您只选择了业务的一部分作为目标组织,那么同一家公司的其他部分也将是业务参与者。

命名每个业务参与者,采用的命名方式是其名称代表它在业务中的角色。通过编写简要描述定义每个业务参与者,该简要描述考虑到参与者的职责及其与业务交互的原因,包括业务参与者想从业务中获得的附加价值的类型。

查找业务用例  
 

要查找主要业务用例,请考虑每个业务参与者从业务接收到的价值。问您自己:业务参与者期望从业务中接收到什么服务。它可能有助于以核心业务用例开始 - 核心业务用例即那些服务于客户(在不存在贸易交互的情况下则服务于客户的等同对象)的用例。

研究业务参与者的生命周期是有帮助的,它可以确定以下问题的答案:

  • 业务参与者与业务的第一次接触是什么?  
  • 业务参与者经历了哪些与业务相关的阶段或状态?
  • 业务参与者将什么当作与业务之间有意义的交互?
  • 何时业务参与者感到满意?
  • 业务参与者期望得到什么事件的通知?

从支持业务的角度,流程也可以表示为业务用例。问您自己:为了向客户交付产品和服务,什么是必需的。当然,业务建模的范围以及定义的业务建模目标将确定支持业务用例的详细程度(如果您打算考虑它们的话)。寻找以下种类的流程:

  • 人员的开发和维护
  • 业务内 IT 的开发和维护
  • 办公室和设施的开发和维护
  • 安全性
  • 法律建议
  • 合作伙伴和合同管理
  • 会计
  • 后勤
  • 采购
  • 销售分析和研究
  • 产品开发

从管理业务的角度出发,流程可以表示为业务用例,尽管从信息系统方面来讲很少会对它们感兴趣。要确定管理流程,请寻找与将业务作为一个整体管理相关联的任务,以及通常与所有者参与者交互的任务。考虑所有者参与者从业务中接收到的内容。搜索可实现以下目标的任务:

  • 形成关于业务的信息,并提供给所有者和投资者。
  • 设置长期目标。
  • 在业务中的其他业务用例之间进行协调,并划分其优先级。
  • 在业务中创建新的流程。
  • 计划和执行改进。
  • 监视业务中的流程。

此类流程的生命周期常常跨越一个财政年度。

确定业务用例的另一个方法是让领域专家描述现有业务中的每项任务。 然后将这些任务分组为已命名并进行了简要描述的业务用例。

 

考虑业务目标  

复审所有已描述的业务目标,并考虑业务用例是否会支持这些目标。如果您发现业务用例支持两个完全不同的目标,您可以考虑将该用例分成两部分。如果业务用例支持差别很大的业务目标,您将发现很难度量或改善其性能。不支持任何已确定的业务目标的业务用例可能是不必要的。另一方面,这些业务用例的进一步调查可能揭示未发现的业务目标。

还必须与业务参与者相比较来考虑业务目标。确定的业务目标是否将业务朝这些目标计划要包含的业务参与者的方向推进? 是否存在业务目标未针对的任何业务参与者? 在此分析期间还可能发现新的业务目标。

 

划分业务用例的优先级  

一旦您确定了业务参与者和业务用例,您必须划分那些能引起高度兴趣从而必须详细描述的业务用例的优先级。要确定高优先级的业务用例:

  • 确定在您执行业务设计以查找信息系统需求的情况下,计划的系统将对其感兴趣的业务用例。
  • 在决定是否包含任何从信息系统角度而言不是清晰地相关的业务用例之前,形成一个分步描述。
  • 寻找支持最重要业务目标的业务用例。

 

生成业务用例工作流程的概述  

为理解业务用例的目的,您常常需要工作流程的分步概述。将在随后指定业务用例的人员也将需要此分步描述。

例如,业务用例“个人检入”的分步工作流程描述的第一稿可能看起来如下:

  • 乘客进入检入柜台的队列。
  • 乘客将票递给检入代理。
  • 检入代理验票。
  • 检入代理登记行李。
  • 检入代理为乘客保留座位。
  • 打印登机牌。
  • 检入代理将登机牌交给乘客。
  • 乘客离开检入柜台。

请注意,这是第一稿,因此它可能缺少一些任务,这些任务将在以后发现。您还可以将备用流程包含在这组初始步骤中。

第一稿使人们可以清晰地了解:业务用例将做什么,何时开始,何时结束,它提供什么价值。通常,您为业务用例定义粗略的分步概述的时间不会超过一个小时。(但支持业务用例和管理业务用例的概述除外 - 它们通常并不泾渭分明。)

重点关注最重要的业务用例 - 也就是,代表最高改进可能的用例。是否可以增加业务用例的范围,以便最初由客户执行的工作或者无人执行的工作现在由目标组织执行? 是否可以缩小范围,以便客户现在将执行先前由目标组织执行的任务? 如果一个业务用例能更好地为客户提供服务,则该用例得到了改进,这暗示它变得更简单,能生产更好的产品,提供更短的前导时间,等等。“客户应该能够直接接触业务的核心部分”。

对于每个业务用例,设置可度量的目标,这些目标可以用来验证您是否已成功。随后这些业务目标可以进行优化,并转换成其他业务目标,以及转换成业务策略。当建立新的目标组织时,业务目标可用来持续地度量业务用例如何运行,如何改进。 

 

描述业务参与者和用例如何交互  

确定那些与业务用例交互的业务参与者,方法是定义它们之间的通信关联。如果显示谁启动通信是很重要的,则您可以向关联添加可导航性。如果它改进了模型的可读性,您还可以命名该关联。

 

 

封装业务用例和参与者  

如果您有许多业务用例,您可以将它们分成各个包,以使文档易于理解。例如,可以根据类型(例如市场、法规实体和合作伙伴)封装业务参与者。业务用例可以根据目的分组,例如销售和市场、产品开发以及管理。另外,它们也可以根据业务参与者分组,例如股东和投资者或直接消费者。

在用例图中显示业务用例模型  

用例图说明业务参与者、业务用例及其关系的组合。图可以包含任何以下内容:

  • 包内的所有业务参与者
  • 一个业务参与者和所有专门针对第一个参与者的其他业务参与者
  • 一个业务参与者和与它交互的所有业务用例
  • 与相同的业务参与者交互的业务用例
  • 通常按顺序执行的业务用例
  • 属于同一个用例包的业务用例
  • 最重要的业务用例

请注意最重要业务用例的图可以充当完整业务用例模型的摘要,从而证明对其进行复审是有帮助的。

撰写业务用例模型调查  
 

业务用例模型的调查描述需要表述以下信息:

  • 正在描述的业务的目的
  • 使用业务用例的典型顺序
  • 业务未包含在业务用例模型中的部分
评估结果  

在此状态下,请确保检查业务用例模型,以验证您的工作是否处在正轨。但是,不要详细地复审模型。您还必须在对业务用例模型进行操作时考虑业务用例模型的核对表。相关各方必须确定:

  • 是否确定了所有必要的业务用例。
  • 是否确定了所有不必要的业务用例。
  • 每个业务用例的行为是否按照正确的顺序描述。
  • 在此阶段,每个业务用例的工作流程是否尽可能地完整。
  • 业务用例模型的调查描述是否使其可以理解。

 


 

本文转自肖勇 51CTO博客,原文链接:http://blog.51cto.com/xiaoyong/740694 ,如需转载请自行联系原作者

相关文章
|
10月前
|
存储 监控 供应链
某企业存货验收入库内部控制流程设计
某企业存货验收入库内部控制流程设计
184 0
|
9月前
|
SQL 安全 关系型数据库
案例07-在线人员列表逻辑混乱
在线人员列表逻辑混乱
|
10月前
|
架构师 测试技术 uml
这才是业务用例,别再搞错了!
这才是业务用例,别再搞错了!
301 0
|
11月前
|
数据采集
ORK父子任务制定的常见误区
ORK父子任务制定的常见误区
34 0
|
运维 JavaScript 安全
产品相关 细说软件产品和业务 & 业务过程(流程) & 业务逻辑
产品相关 细说软件产品和业务 & 业务过程(流程) & 业务逻辑
94 0
|
前端开发 Java 程序员
业务代码与技术代码
当程序员大多都有一个共同的经历:当你在改一段复杂的代码时,你一边吐槽是哪个小可爱写的这段像一坨*一样的代码时,一边打开了提交记录,赫然发现竟然是自己3个月前写的!
2996 0
|
前端开发 测试技术 数据安全/隐私保护
|
JSON Java 关系型数据库
|
机器人
业务代码如何才能不再写出大串的if/else?(上)
业务代码如何才能不再写出大串的if/else?
493 0
业务代码如何才能不再写出大串的if/else?(上)
|
数据采集 存储 机器学习/深度学习
数据太多、太乱、太杂?你需要这样一套数据治理流程
数据作为机器学习的基础,从 GB、TB 到 PB 已经增长了无数倍,现在大一点的业务场景,没有 TB 级数据都提供不了高效的体验。那么数据怎么治理才好,怎样与模型、算力结合才算妙?在本文中,我们将看看什么是 HAO 数据治理模型,看看公安数据到底是如何规范处理的。
245 0
数据太多、太乱、太杂?你需要这样一套数据治理流程