《大象：thinking in uml 》(第二版) 8章 准备工作

只供参考，喜欢请支持正版图书

8.1 案例说明

选取一个合适的案例是很困难的。作者曾经在博客中公开征集案例，其间也收到许多热心朋友推荐的案例，非常感谢朋友们的帮助，只可惜这些案例都不太合适。有的案例太小，比如一个论坛，无法串起更多的知识点；有的案例不够典型，比如库存管理，难以体现出UML的优势。作者在考虑的时候，更多的是在选择这样一个案例：它能够将尽量多的知识点串起来；它具备比较普遍的代表性；它很容易体现UML的优势；它的业务领域对大部分读者来说不会太陌生。衡量了很多，最终还是打算从服务行业选择一个案例

8.2 了解问题领域

8.2.1 了解业务概况

现在假设读者就是供电企业电力营销管理软件开发项目的负责人，在项目正式启动前你正在考察和评估供电企业的业务模式。这些工作包括项目背景调查、业务前景分析、业务可行性分析、技术可行性分析等。你将初步了解项目的产生原因、运行环境、系统规模、软硬件环境以及客户期望，这些内容将成为软件项目的最初输入也是十分重要的输入。

8.2.2 整理业务目标

业务目标又称为业务前景，是对要建设的系统的展望，业务目标非常重要，在9.1定义边界一节中会看到，边界正是基于业务目标来定义的。

在这个案例里，我们得到了以下一些业务目标：

■　为用电客户提供业务办理自动化服务，提高办事效率，方便客户，为客户提供更好的服务。
■　规范供电企业的内部管理，提高工作效率和管理效能。
■　管理好供电企业的资产，提高资产使用率和设备可靠性。
■　规范化财务管理，提高电费发行效率，减少人为差错。
■　做好用电检查工作，保障用电安全。
■　采集营销和管理数据，进行商业分析，提供决策支持。

在很多项目里业务目标仅在项目立项的过程中使用，它最多会在分析业务范围时起一点参考作用，很少有人用它来进行分析设计。在作者所介绍的方法里，业务目标是进行分析的第一步，从需求开始，所有的工作都由业务目标开始推导。在9.1定义边界一节里，读者将看到作者是如何根据业务目标来开始推导需求和建立业务模型的。

8.3 做好涉众分析

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

8.3.1 什么是涉众

涉众是与要建设的业务系统相关的一切人和事。首先要明确的一点是，涉众不等于用户，通常意义上的用户是指系统的使用者，而这仅是涉众中的一部分。如何理解与业务系统相关的一切人和事呢？凡是与这个项目有利益关系的人和事都是涉众，他们都可能对系统建设造成影响。

例如修建一条公路，它预期的使用者是广大的司机；监管方是交通管理局；出资方是国家财政；发展商是某某公司；建筑商是某某工程公司等。显然他们都与此项目有利益关系，都是涉众。这些都好理解。但是在某些情况下，看似与公路完全无关的一些人和事却会成为重要涉众。例如当公路修建需要搬迁居民时，被搬迁的居民就成为重要的涉众；当公路规划遇到历史建筑时，文物管理局就成为重要的涉众。

8.3.2 发现和定义涉众

对于软件项目来说，作者可以给大家分享的经验是通过以下大类去寻找软件项目的涉众，对大部分管理类软件来说，以下的涉众大类可以帮助你定义和发现项目中的涉众。

8.3.2.1 业主

业主是系统建设的出资方、投资者。虽然大多数情况下业主指的就是系统的需求提出者和使用者，即业务方，但并不是绝对的

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

8.3.2.2 业务提出者

业务提出者是业务范围、业务模式和业务规则的制定者，一般是指业务方的高层人物，比如CEO、高级经理等。他们制定业务规则，圈定业务范围，规划业务目标。他们的期望十分十分重要，实际上，系统建设正是业务提出者经营目标和管理意志的体现。虽然他们的期望一般都比较原则化和粗略化，但是却不能违反和误解，否则系统将有彻底失败的危险。换句话说，业务提出者的期望是系统建设的最高纲领。

业务提出者一般最关心系统建设能够带来的社会影响、效率提升、管理改进、成本节约等宏观效果。换句话说，他们只关心统计意义而不关心具体细节，但是，如果建设完成的系统不能给出他们满意的统计结果，这必定是一个失败的项目。在系统建设过程的沟通中，他们的意志一般是极少妥协的，系统分析员不必太费心去试图说服他们接受一个与他们意志相左的方案。实际上，由于他们的期望是非常原则化和粗略化的，因此留给了系统建设者很大的调整空间和规避风险的余地。

8.3.2.3 业务管理者

业务管理者是指实际管理和监督业务执行的人员，一般是指中层干部，他们起到将业务提出者的意志付诸实施，并监督底层员工工作的作用。他们的期望也很重要，一般也是系统的主要用户之一

业务管理者关心系统将如何实现他们的管理职能，如何能方便地得知业务执行情况，如何下达指令、如何得到反馈、如何评估结果等。业务管理者的期望相对比较细节，是需求调研过程中最重要的信息来源。系统建设的好坏与业务管理者的关系最多，也是系统分析员最需要下功夫的。业务流程、业务规则、业务模式等绝大部分来自业务管理者。系统分析员必须要把业务管理者的思路想法弄清楚，业务建模的结果也必须与业务管理者达成一致。业务管理者应当成为需求评审小组的成员，如果可能，他们甚至应当成为需求分析小组的成员与系统分析员一同工作。

8.3.2.4 业务执行者

业务执行者是指底层的业务操作人员，是与将来的计算机直接交互最多的人员。他们最关心的内容是系统会给他们带来什么样的方便，会怎样改变他们的工作模式。

业务执行者的需求最为细节，系统的可用性、友好性、运行效率等与他们关系最多。系统界面风格、操作方式、数据展现方式、录入方式、业务细节都需要从他们这里了解。他们将成为系统是否成功的试金石。系统的界面风格、操作方式、表单细节等是系统分析员向他们调研时需要多下功夫的地方。

这类人员的期望灵活性最大，也最容易说服和妥协。同时，他们的期望又往往是最不统一的，各种各样的古怪要求都有。但是，不管他们的期望有多古怪，都必须服从业务管理者的期望。系统分析员需要做的事情是从他们的各种期望中找出普遍意义，解决大部分人的问题，对于特殊的问题尽量予以说服，必要时可以依靠说服业务管理者来影响和消除那些不合理的期望。

8.3.2.5 第三方

第三方是指与这项业务有关系的，但并非业务方的其他人或事。比如购物网站系统，如果交易双方是通过网上银行完成支付交易的，则网上银行就成为了购物网站系统的一个涉众；如果货物是通过邮政系统交付的，那么邮政系统就成为购物网站系统的一个涉众。

一般来说，第三方的期望对系统来说不会产生什么决定性影响，但大多会起到限制作用，成为系统的一个约束。通常，在最终系统中，这些期望将体现为标准、协议和接口。

另一种典型的第三方是项目监理，项目监理的期望也会对系统建设起到约束作用

8.3.2.6 承建方

承建方，也就是你的老板。实际上老板的期望也是不容忽视的。通常老板关心的是通过这个项目是否能赚到钱、是否能积累核心竞争力、是否能树立品牌、是否能开拓市场等。老板的期望将很大程度上影响一个项目的运作模式、技术选择、架构建立和范围确定。

比如，如果老板试图通过这个项目打开和培育一个新兴市场，树立起公司品牌，并不惜成本，那么系统分析员就要尽可能地深入挖掘潜在业务，建立扩展能力很强，但成本较高的业务架构；选择那些比较新、具有一定领先优势但风险较高的技术。反之，如果老板只想通过这个项目赚更多的钱，关心的是投入产出比，那么系统分析员就需要引导业务方压缩业务范围，选择风险小的成熟技术。甚至可能放弃成本较高的架构化开发模式，仅仅考虑系统的可维护性是否能够接受，而较少考虑系统扩展能力。

一个业主满意但老板不满意的项目，恐怕也不是一个成功的项目吧？

8.3.2.7 相关的法律法规

8.3.2.8 用户

用户是一个抽象的概念，指预期的系统使用者。用户一般是上述涉众的代表。

用户与涉众不同的是，每一个用户将来都可能是系统中的一个角色，是实实在在参与系统的，需要编程实现。而上述的其他涉众，则有可能只是在需求阶段用来分析系统，最终并不与系统发生交互。在建模过程中，概念模型的建立和系统模型的建立都只从用户开始分析，而不再理会其他的涉众。

当通过以上的大类发现和定义了涉众之后，就可以着手进行涉众分析报告的编写了。

8.3.3 涉众分析报告

一份完整的涉众分析报告包括涉众概要、涉众简档、用户概要、用户简档和消费者统计五个部分，下面分别进行说明

8.3.3.1 涉众概要

我们采用表格形式来编写涉众概要，示例如表8-1所示。
从表8-1中，我们能够看出涉众期望与需求是不同的。实际上涉众期望并不是需求，它们只是涉众对将来系统的一些“期望”，这些期望有的需要通过一系列的系统功能来实现，有的需要特殊的设计，有的不需要实际的编码。但是无论如何，一个系统成功与否，最重要的根本原因不在于其技术的先进性；不在于其设计的优良性；不在于其性能的高效性；也不在于其界面的华美性。这些的确都很重要，但是最重要的还是满足涉众的期望。只有满足了涉众的期望，才能赢得客户满意度。

8.3.3.2 涉众简档

作为示例，我们从涉众概要中抽取出几个涉众并为其编写涉众简档，每个涉众编写一份简档，我们采用表格形式来说明，示例如表8-2所示。

8.3.3.3 用户概要

用户概要描述一般应当包括用户概况、特点和用户使用系统的方式。用户概要可以通过表8-3说明

8.3.3.4 用户简档

用户简档可以用下面的表格来编制，这里仅挑选一个用户作为示例，如表8-4所示

8.3.3.5 消费者统计

8.4 规划业务范围

8.4.1 规划业务目标

对业务目标来说，规划手段可以是：
■　取消一个业务目标
取消一个业务目标意味着与该业务目标相关的所有涉众和涉众期望都从业务范围中取消。以后的工作无须再考虑他们

■　调整一个业务目标
如果某业务目标有些内容由于种种原因不适合在项目中开发，或项目周期和成本无法承受，可以在征得客户同意的前提条件下调整业务目标

8.4.2 规划涉众期望

对涉众期望来说，规划手段可以是：
■　取消一个涉众
取消一个涉众意味着该涉众所有的期望都被从业务范围中取消。将来无论是业务建模还是需求分析都无须再考虑该涉众的期望

■　减少一个涉众期望
出于成本约束，或者某个期望难以实现，可以单独减少一个涉众期望。例如由于当地的网络环境不允许，可以通过与涉众协商取消SH0010银行涉众的实时联网收费期望，而保留离线收费，每日结算的收费方式。

■　调整一个涉众期望
出于成本约束，或者某个期望难以实现，可以与涉众协商调整涉众期望。例如由于远程抄表系统的不够完善，经常出现断路现象，则可与SH005电表抄表部门协商，调整其期望为不支持远程抄表方式

8.5 整理好你的思路

8.5.1 划分优先级

如何划分优先级？可以为涉众和涉众期望分别用数字划分出优先级，再用它们相乘的结果来排序。作者采用1、2、3来标识优先级，数字越大则优先级越高。以下是一个优先级排序的例子。

8.5.1.1 涉众优先级标准

■　最高优先级，数值3
此类涉众是业务核心成员，他们担任的岗位和所做的工作构成最核心的业务流程。如果某一类涉众虽然不是核心业务，但他们的意见对系统成败很重要，则应当赋予最高优先级。例如某位领导虽然不参与核心业务，但他是核心业务的制定者和监管者，他的意见将决定业务模式，因此应当设为最高优先级

■　普通优先级，数值2
此类涉众是主要业务模块的参与者，他们担任的岗位和所做的工作是核心业务流程的重要辅助。

■　最低优先级，数值1
此类涉众是边缘业务模块的参与者，他们担任的岗位和所做的工作对核心业务流程不产生重要影响。

8.5.1.2 期望优先级标准

■　最高优先级，数值3
该期望是核心业务的组成部分，如果缺少该期望，业务流程将不能运转。

■　普通优先级，数值2
该期望是核心业务的重要辅助部分，如果缺少该期望，业务流程将不能完成某些特定的目标，或者不能顺畅运转。

■　最低优先级，数值1
该期望是一些边缘业务。即使缺少该期望，业务流程也能顺利运转。

8.5.1.3 优先级矩阵

在如表8-6所示的矩阵中，每一行表示一个期望，括号后面的数字表示其优先级；每一列表示一个涉众，括号后面的数字表示其优先级。矩阵中的每个单元格代表涉众优先级数值与期望优先级数值的乘积。相乘结果等于9和6的为第一优先级，用红色表示；相乘结果等于4和3的为第二优先级，用黄色表示；相乘结果等于2和1的为第三优先级，用绿色表示。如果多个涉众对应同一个期望，则取涉众中优先级最高数值的作为因子。

8.5.2 规划需求层次

人们对事物的理解总是由粗到细，由表及里的。复杂的需求犹如茂密的森林，一不小心就会迷失在浩如烟海的业务细节中。尽管你很聪明并富有经验，也请面对现实，花费了几年甚至几十年建立起来的业务流程和规范，不是短短一两星期就能消化得了的。面对这样一片茂密的迷失森林，你最好的做法是循序渐进，从最粗略的业务目标开始了解，之后是业务流程，再后来是工作人员的工作内容，最后才是数据细节。这个由粗到细、由宏观而微观的过程，正如先坐飞机鸟瞰整个森林的全貌，再选择几条大路穿越森林，最后才是逐片树木逐棵树木地研究。

8.5.2.1 第一层次：业务架构

第一层次围绕业务背景、业务目标、业务目标人员、业务参与人员、组织结构、岗位设置等展开，由此搭建起对业务领域的第一了解。虽然第一层次并不足以让人了解具体业务是如何运作的，但是业务架构描绘出了一幅业务全景，这对于进一步了解需求帮助巨大，这样就将不会再迷失在茫茫的需求海洋中了。当这一层次完成后，业务需求的骨架就显现出来了

在需求过程的第一层次中，业务用例模型的业务用例视图、领域模型视图被建立起来

8.5.2.2 第二层次：业务流程

第二层次针对每个业务目标，将参与这个业务目标的业务目标人员、业务参与人员、组织结构和岗位设置组织起来，描述业务流程的运转过程以及每一个参与元素在运转过程中的贡献和期望。在这一层次中，着重让业务流程完整地运转起来，忽略具体的工作细节。当这一层次工作完成后，业务需求的骨架上添加了血肉，业务需求已经基本成型了。

在需求过程的第二层次中，包括业务用例实现、用例场景、分析场景在内的完整的业务用例模型和概念模型被建立起来

8.5.2.3 第三层次：工作细节

第三层次针对每一个参与上述业务流程的参与者展开，描述他的工作细节，做什么、怎么做、有哪些规则、结果是什么。在这一层次，基于前面的工作，已经不用再考虑整个业务是什么，而只需要专心细致地一点点挖掘参与者的工作细节。当这一层次的工作完成后，神经网络被加入到业务需求的骨架和血肉中，一个完整的需求模型可以运转了。

在需求过程的第三层次中，系统用例模型、初步的分析模型和初步的软件架构被建立起来。

8.5.3 需求调研计划

项目情况千变万化，需求调研计划也应当因地制宜。这里作者给出一个示例，在这个示例中，需求工作分三个迭代完成。

■　第一个迭代周期完成第一优先级期望的第一、第二需求层次的工作。
■　第二个迭代周期完成第一优先级期望的第三需求层次，第二优先级期望的第一、第二需求层次和第三优先级期望的第一需求层次的工作。
■　第三个迭代周期则完成第二优先级期望的第三需求层次，第三优先级期望的第二、第三需求层次的工作

表8-7　需求调研迭代计划示例

8.6 客户访谈技巧

8.6.1 沟通的困难

这一点也不奇怪，因为系统分析员习惯于从计算机角度来看待问题，而客户往往并不懂得。最麻烦的是，客户有时候会认为系统分析员是计算机专家而特别容易轻信系统分析员的判断，所以当系统分析员阐述计算机将如何做的时候，客户经常会轻易地点头。反过来，由于客户一直从事他所熟悉的业务领域，他身边的人也同样熟悉这个业务领域，自然地，客户与客户之间的交流显得很容易，并不需要详细地阐述，经常只言片语就能达到共识。由于这种惯性的存在，客户自然而然会认为他所说的所谓的内容重点也一定会被系统分析员理解，而不用过多的细节解释。由此沟通的问题就产生了。

显然，如果沟通的双方都站在各自的立场，出现误解是十分自然的事。为了达到好的沟通效果，必须有一方站到对方的立场上去思考问题。寄希望于客户站到计算机立场上来吗？既不合道理也不现实，唯一的办法只有系统分析员改变自己的立场。当你与客户交流需求内容时，应当将自己当成业务一方而不是计算机专家，尽力完全了解客户的业务目标和业务内涵。不仅要了解业务是什么，还要弄清楚业务为什么，而尽量避免给客户讲解计算机是什么。一个好的系统分析员在完成一个项目的需求调研后，他应当已经成为一个业务专家

8.6.2 沟通技巧

8.6.2.1 建立平等的对话平台

8.6.2.2 做足准备工作

8.6.2.3 以我为主

一个好的系统分析员应当每次谈话都有明确的目标

8.6.2.4 改变沟通策略

8.6.2.5 把握需求节奏

8.6.2.6 记录与反馈

8.7 提给读者的问题

只供参考，喜欢请支持正版图书