OO系统分析员之路--用例分析系列（3）--业务建模之涉众

作者:coffeewoo 先生

在了解了系统目标以后，系统分析员最先要做的事情不是去了解业务的细节，而是去发现与这个目标相关的人和物。英文把这种人和物称为Stakeholder，在Rose中，这类模型的类型被定义为Business Actor 。有的资料翻译为干系人，笔者则更喜欢涉众这种翻译方法。这就谈到了业务建模的第一步：发现和定义涉众。

从这一篇开始，笔者将借助一个虚拟的实例来阐述获取用例的方法，以及如何判断用例获取是否完备，粒度选择是否合适。事实上，在做这些工作时，我们正在进行需求分析的第一个阶段，即业务建模阶段。借助这个例子，笔者同样会阐述业务建模到底应该做什么，做到什么地步才能说明业务需求已经完整，可以称为一份完整的需求规格说明书了。

一般来说，只有当以下工作都完成，才能说业务模型建立完成，它们是：

发现和定义涉众
画定业务边界
获取用例
绘制用例场景图
绘制业务实体模型（领域模型）
编制词汇表
下面笔者开始就一个事例来说明如何完成这些工作，这只是一个虚拟的事例，它的合理性和真实性请读者不必追究。

现在我们接到一个项目，是一个网上图书借阅系统，初步跟客户接触，网上图书馆的业务负责人这样告诉我：

我们原本是一个传统的图书馆，传统的借书方式要求读者亲自来到图书馆，这显得非常不方便，而且随着藏书的增加和读者群的增长，尤其而且大量的读者到图书馆，使得图书馆的场地不足，工作人员也不够了。所以想到借助网络，让读者通过网络借/还书，这样可以省掉大量的场地维护和工作人员成本支出，同时计算机可以方便的检索目录，让读者可以足不出户借到需要的书。为了把书送到借阅人手里，我们已经联系了A特快专递公司和B城市物流公司，初步达成协议，由他们往返借阅人和图书馆之间把图书送出和收回。读者在网上出示和验证借书卡，找到他们需要的书，提交申请，图书管理员确认后，就会通知物流公司来取书，当读者拿到书之后，物流公司需要把读者的签单拿回来以证明读者已经拿到了书。当然这个过程中，读者是需要付费的。还书也是基本同样的过程。

好了，通过这番谈话，我们已经基本上了解了系统目标。一些着急的系统分析员已经准备开始着手询问借书的流程，借阅人的资格认证问题了，甚至有的人已经凭借多年的开发经验在脑海中绘制出了一幅网页，考虑如何实现这个系统了。

笔者要说的是，请您千万不要着急往下走。因为我们得到的仅仅是一个由非计算机专业人员规划出的很粗略的构想，其可行性如何都尚未得到证实，在这样的基础下就开始细化，将来出现反复甚至失败的危险是很大的。

在了解了系统目标以后，系统分析员最先要做的事情不是去了解业务的细节，而是去发现与这个目标相关的人和物。英文把这种人和物称为Stakeholder，在Rose中，这类模型的类型被定义为Business Actor 。有的资料翻译为干系人，笔者则更喜欢涉众这种翻译方法。这就谈到了业务建模的第一步：发现和定义涉众。

什么是涉众？涉众是与要建设的业务系统相关的一切人和事。首先要明确的一点是，涉众不等于用户，通常意思的user是指系统的使用者，这仅是涉众中的一部分。如何理解与业务系统相关的一切人和事？笔者可以给大家分享的经验是通过以下大类去寻找：

业主
业主是系统建设的出资方，投资者，它不一定是业务方。比如可以假设这个图书馆的网络化建设是由一家国际风险投资机构投资的，它本身并不管理图书馆，它只是从资本上拥有这个系统并从借书收入中获得回报。
了解业主的期望是必须和重要的，业主的钱是这个项目存在的原因。若系统建设不符合业主的期望，撤回投资，那么再好的愿望也是空的。
一般来说，业主关心的是建设成本，建设周期以及建成后的效益。虽然这些看上去与系统需求没什么大的关系，但是，建设成本、建设周期将直接影响到你可以采用的技术，可以选用的软件架构，可以承受的系统范围。一个不能达到业主成本和周期要求的项目是一个失败的项目，同样，一个达到了业主成本和周期要求，但却没有赚到钱的项目仍然是一个失败的项目。

业务提出者
业务提出者是业务规则的制定者，一般是指业务方的高层人物，比如CEO，高级经理等。他们制定业务规则，圈定业务范围，规划业务目标。他们的期望十分十分的重要，实际上，系统建设正是业务提出者经营和管理意志的体现。他们的期望一般比较原则化和粗略化，但是却不能违反和误解，否则系统将有彻底失败的危险。业务提出者一般最关心系统建设能够带来的社会影响，效率改进和成本节约。换句话说，他们只关心统计意义而不关心具体细节，但是，如果建设完成的系统不能给出他们满意的统计结果，这必定是一个失败的项目。在系统建设过程的沟通中，他们的意志一般是极少妥协的，系统分析员不必太费心去试图说服他们接受一个与他们意志相左的方案。实际上，由于他们的期望是非常原则化和粗略的，因此留给了系统建设者很大的调整空间和规避风险的余地。

业务管理者
业务管理者是指实际管理和监督业务执行的人员，一般是指中层干部，起到将业务提出者的意志付诸实施，并监督底层员工工作的作用。他们的期望也很重要，一般也是系统的主要用户之一。他们关心系统将如何实现他们的管理职能，如何能方便的得知业务执行的结果，他们如何将指令下达，以及如何得到反馈。业务管理者的期望相对比较细节，是需求调研过程中最重要的信息来源。系统建设的好坏与业务管理者的关系最多，也是系统分析员最需要下功夫的。系统分析员必须要把业务管理者的思路，想法弄清楚，业务建模的结果也必须与业务管理者达成一致。在系统建设过程中，业务管理者的期望可以有所妥协，一个经验丰富的系统分析员可以给他们灌输合理的管理方式，提供可替代的管理方法，以规避导致高技术风险或高成本风险的不合理要求。

业务执行者
业务执行者是指底层的操作人员，是与将来的计算机直接交互最多的人员。他们最关心的内容是系统会给他们带来什么样的方便，会怎样的改变他们的工作模式。他们的需求最细节，系统的可用性，友好性，运行效率与他们关系最多。系统界面风格，操作方式，数据展现方式，录入方式，业务细节都需要从他们这里了解。他们将成为系统是否成功的试金石。Look and Feel ，表单细节等是系统分析员与他们调研时需要多下功夫的地方。这类人员的期望灵活性最大，也最容易说服和妥协。同时，他们的期望又往往是不统一的，各种古怪的要求都有。他们的期望必须服从业务管理者的期望，因此，系统分析员需要从他们的各种期望中找出普遍意义，解决大部分人的问题，必要时可以依靠业务管理者来影响和消除不合理的期望。

第三方
第三方是指与这项业务而关联的，但并非业务方的其他人或事。比如在这个事例中，借阅人借书时需要交费，若交费是通过网上银行支付的，则网上银行就成为了网上借书系统的一个涉众。
第三方的期望对系统来说不起决定性意义，但会起到限制作用。最终在系统中，这种期望将体现为标准、协议和接口。
另一种典型的第三方是项目监理，系统分析员也必须弄清楚监理的期望。

承建方
承建方，也就是你的老板。老板的期望也是非常重要的。老板关心的是通过这个项目，能否赚到钱，是否能积累核心竞争力，是否能树立品牌，是否能开拓市场。老板的期望将很大的影响一个项目的运作模式，技术选择，架构建立和范围确定。比如，老板试图通过这个项目打开一个市场，树立起品牌，不惜成本，那么，系统分析员需要尽可能的深入挖掘潜在业务，建立扩展能力很强，但成本较高的业务架构，选择那些较新，但风险较高的技术。反之，如果老板只想通过这个项目赚更多的钱，系统分析员就需要引导业务方压缩业务范围，选择风险小的成熟技术，甚至不用考虑业务架构，考虑系统的可维护性，而较少考虑系统扩展能力。
一个业主满意但老板不满意的项目，恐怕也不是一个成功的项目吧？

相关的法律法规
相关的法律法规是一个很重要的，但也最容易被忽视的涉众。这里的法律法规，既指国家和地方法律法规，也指行业规范和标准。例如，这个借阅系统中要建立借阅人档案，就必须保障借阅人的隐私权；要与网上银行交易，必须遵守信息安全法等。若遇到业务方提出违反了法律法规的要求时，系统分析员要能给他们指出来，说服无果的情况下要在合同里留下免责条款。否则一不小心惹上官司可是件郁闷的事。
另外，有时必须得遵守一些行业规范。例如本事例是网上借阅，网络需求决定了需要遵守HTML规范，才能保证借阅者能正常浏览网页。

用户
用户是一个抽象的概念，是指预期的系统使用者。用户可能包括上述的任何一种涉众。用户涉众模型建立的意义是，每一个用户将来都可能是系统中的一个角色，是实实在在参与系统的，需要编程实现。而上述的其它涉众，则有可能只是在需求阶段有用，最终并不与系统发生交互。在建模过程中，概念模型的建立和系统模型的建立都只从用户开始分析，而不再理会其它的涉众。在Rose中建模的时候，也只需要建立用户的模型，其它涉众则只需要体现在文档中即可。

这篇文章只能到此为止了，否则太长的话，读者该不耐烦了。只好在此分节。下一节笔者将一步步将涉众的期望导出，并得到需求范围的大致轮廓。