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

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

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

发现和定义涉众

画定业务边界

获取用例

绘制用例场景图

绘制业务实体模型（领域模型）

编制词汇表

下面笔者开始就一个事例来说明如何完成这些工作，这只是一个虚拟的事例，它的合理性和真实性请读者不必追究。

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

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

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

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

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

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

业主

业主是系统建设的出资方，投资者，它不一定是业务方。比如可以假设这个图书馆的网络化建设是由一家国际风险投资机构投资的，它本身并不管理图书馆，它只是从资本上拥有这个系统并从借书收入中获得回报。

了解业主的期望是必须和重要的，业主的钱是这个项目存在的原因。若系统建设不符合业主的期望，撤回投资，那么再好的愿望也是空的。

一般来说，业主关心的是建设成本，建设周期以及建成后的效益。虽然这些看上去与系统需求没什么大的关系，但是，建设成本、建设周期将直接影响到你可以采用的技术，可以选用的软件架构，可以承受的系统范围。一个不能达到业主成本和周期要求的项目是一个失败的项目，同样，一个达到了业主成本和周期要求，但却没有赚到钱的项目仍然是一个失败的项目。

业务提出者

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