业务角色演化实例-软件需求工程成果

2023-11-17 理论教育版权反馈

【摘要】：综合管理部和综合管理部主管为代理（泛化）关系。虽然业务角色不能够逾越或改变涉众期望，但是能够自行决定实现涉众期望的过程。反之，综合管理部主管参与薪资表的审批等系统操作，故综合管理部主管可以转化为系统用户。

对于薪酬管理业务，边界之外的涉众包括财务部主管、财务部出纳、综合管理部主管等即为业务主角。边界内的银行角色辅助业务主角们共同完成薪酬管理业务，因为银行是被动参与的，所以银行是业务工人。具体情况如图5-5所示。

pagenumber_ebook=86,pagenumber_book=75

图5-5　业务角色视图

讨论一：

业务角色与涉众的区别在于：第一，涉众是与业务相关的利益人员而业务角色是指在现实世界中参与整个业务活动的人员；第二，来源范围不同：涉众包含业务提出者、业务管理者、业务执行者、第三方、承建方等（涉众并不一定是人，也可能是相关机构和相关法律法规），而业务角色则是与业务领域问题直接相关的人。第三，业务角色也是涉众的一部分。

案例&知识：

例如，薪酬管理中的涉众有综合管理部，但是在业务角色中不包含综合管理部，而将其演化为综合管理部主管。综合管理部和综合管理部主管为代理（泛化）关系。

从对象关系上来说，综合管理部包含综合管理部主管。(www.chuimin.cn)

从业务上理解，代理在现实生活中可以找到很多例子。例如律师代理委托人处理法律事务，主张和利益一定是来自委托人自己的，律师并不能擅自做主，但是具体的操作过程则由律师来决定，委托人可能完全不参与业务本身。而在我们的业务中关于综合管理部的相关业务均为综合管理部主管在执行，所以综合管理部并不是业务角色。

在寻找业务角色过程中，涉众分析报告是很重要的分析来源，一般来说业务角色通常可以从涉众分析当中获得。业务角色一旦决定代理哪个涉众，就一定要受到涉众期望的制约。虽然业务角色不能够逾越或改变涉众期望，但是能够自行决定实现涉众期望的过程。

讨论二：

业务角色，之所以加上业务二字，是因为业务角色确实区别于系统用户。系统用户是系统的实际操作者，它可以是一个逻辑的名称，也可以是某种系统角色。在系统中，系统用户通常都有ID，系统会为其建立会话（Session），系统用户有存在范围（Scope），也有生命周期（Duration）。系统用户在系统中是需要编程实现的。

但业务角色是用来分析业务的，它可能会也可能不会转化成一个系统用户。本案例中的银行和综合管理部主管就是一个明显的例子。银行不参与实际的薪酬管理系统的操作，所以不能转化为系统用户。反之，综合管理部主管参与薪资表的审批等系统操作，故综合管理部主管可以转化为系统用户。

另一方面，业务角色用于分析业务，而业务分析的结果是要与客户交流并达成共识的，因此业务角色不应当被过分抽象化和虚拟化，即便有增强系统扩展性的理由，业务角色也应当能够映射到现实业务中的工作岗位设置、工作职责说明等，并且使用客户习惯的业务术语来命名。这将使你与客户有着共同的语言，便于客户理解而获得正确的业务需求。如果客户不能理解一个业务角色在他的实际业务中对应的是什么工作岗位，那么得到的业务需求很可能就是不符合实际情况的。

业务角色演化实例-软件需求工程成果

相关推荐