OO系统分析员之路--用例分析系列（5）--用户、业务用例和业务场景

用户、业务用例以及业务场景。这三项工作成果已经形成了基本的需求框架，并圈定了业务范围。就笔者的工作习惯而言，在得到这三个成果后，就会暂停调研，而通过评审会，研讨会等形式充分论证这些成果的正确性和完备性。求得业务专家，用户代表，开发方，项目经理等各方的一致认可，将其作为第一份基线。

很久没有动笔了，这期间承蒙许多朋友的喜欢和鼓励，再不写点东西就对不住这些朋友了。

写点什么呢？按照原先的设想，应该开始动手写如何从业务用例转化到概念用例和系统用例，不过老实说这一步需要的是经验居多，而很难找出一个普适的步骤来。先暂时放一放吧，以后一定会写到的。上一篇讲到用例分析的一般步骤和方法，也给出了一个实例，不过没有做更进一步的说明，所以这一篇，笔者决定先罗嗦罗嗦之前的内容，说说业务建模中各种图的用法，以及它们对需求的贡献。

在说明实例之前，再重复一下的需求，并提醒读者下载实例，本文下面只会从实例中挑选很少一部分来说明，对照实例读者将能更好的理解。好了，让我们先回头看看需求吧，图书馆主任是这么说的：

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

还记得上一篇是怎么说的吗？第一步骤是从涉众中找出用户。并定义这些用户之间的关系。 这里的用户是指将与要建设的系统发生关系的那些涉众。通过下图表示。这张图里要绘出所有用户，以及它们之间的关系。需要说明的是，这里的用户指的是业务用户，并非将来系统中的“角色”，虽然将来它们可能就是。这张图的意义在于，清楚的表明将来的系统是为谁在服务，他们都是干什么的，有什么特点，有什么关系。对用例方法来说，这是最基本的出发点。用例，是以人为本的。

第二步，找出每个用户要做的事，即业务用例。业务用例来自于系统分析员对上一步中所有用户的访谈，总结和归纳（笔者正在考虑写一写系统分析员调研技巧方面的文章，会对访谈技巧，归纳方法有所描述）。笔者建议从每个用户的角度以及从每项业务的角度来绘制业务用例图，就象下面这样：

用户视角：

从用户视角查看每个用户在系统中将参与什么业务。这个视图的意义在于，调研对象一眼就能看出来，这个模型是否已经涵盖了他所有需要做的事。

业务视角：

从业务的视角查看每项业务是由哪些用例和哪些角色参与完成的。这个视图的意义在于，需求研讨会上业务专家可以一眼看出这个模型是否已经能够完整的表达业务。

第三步，针对每项业务视图，应该绘制业务场景图，用活动图详细描述这些用户、用例是如何交互来完成这项业务的。就象下面这样:

借阅图书业务过程:

业务场景图可能不止一个。同样一项业务，会有很多种不同的业务实现方式，例如借阅图书业务，就有可能第一次借书，又还书又借书，VIP客户借书，借书时借证已经到期....等等许多种场景。对于这些场景来说，每一个都不能漏掉或省略，至少必须在文档中体现出来，除非已经很明确这个业务场景不包括在系统范围之内。这些业务场景图的意义在于，它已经绘制出了一份系统蓝图，将来的系统建设很大程度将依据这些场景图进行。

经过上面的三个步骤，我们得到了用户、业务用例以及业务场景。这三项工作成果已经形成了基本的需求框架，并圈定了业务范围。就笔者的工作习惯而言，在得到这三个成果后，就会暂停调研，而通过评审会，研讨会等形式充分论证这些成果的正确性和完备性。求得业务专家，用户代表，开发方，项目经理等各方的一致认可，将其作为第一份基线。笔者很少在这个基线形成之前深入细化需求，因为需求过程，或说用例过程是一个自顶向向下的过程，RUP中的每一个迭代实际上仍然是一个瀑布模型，大家都知道，如果上一步没有形成基线就进行下一步，对瀑布模型来说是无法控制的。

好了，这一篇就到此为止，下一篇继续讨论用例场景，用例文档等建模过程。

*********************************************************

作者coffeewoo 欢迎您访问文章原始出处 : http://coffeewoo.itpub.net ，阅读中有任何问题可以在BLOG上留言或发邮件到 coffeewoo@263.net，我将尽力为您解答。具有代表性的问题我会以 Q &A的形式收录到对应的文章之后。希望本系列文章对您有帮助。欢迎转载，敬请注明，谢谢 ^_^

up~
先顶再看~：）

我看了您写的这5篇文章，1字不漏，写的很好，非常的适合入门学习，希望下文..

等待。。。

我会尽快更新的，谢谢朋友们支持。如果有什么要求或者想了解哪方面的内容，如果我知道的，会在接下来的文章里讲述。

请教一下在实际的项目中是如何真正做到迭代的?

例如,任何的需求变更,都从重新分析业务模型开始?

谢谢

感谢TAC朋友提出这个问题。我把这个问题和它的解答移到"以武会友"栏目的“系统分析，业务建模，UML，RUP相关”一帖下了，请你移步到那里去看。

版主，我在学习您的举例过程中，有一个使用过程的疑问：就是在用rose建立活动图时候，Activity都需要手工重新建立吗？我的意思是想通过拖拽“bu_借阅图书”到泳道里来形成Activity，但总不成功。

当然不会成功的。BU和Activity是完全两个不同的东西，从UML语义上说完全没有相关性，更不可能相等，所以不可能直接从BU变成Activity.
你可能误解了我文章的意思，我说Activity名字要用BU的名字，是因为这样是一种很好的办法来检验和完善用例获取。你也可以用完全不同的名字，也可以完全不对应。只是这样做对需求过程没有好处。

有的系统的用户很少，比如一个游戏项目，也就玩家一个用户。

另外比如要做一个 mp3 解码库，那么用户就是 这个库的使用人。

这些项目，需求分析跟您讲的这些系统分析有很大区别，不知道能不能用RUP的方法，如何使用呢？

肯定是可以使用的，但是视角要有所改变。在UML定义中，actor并非是指人，而是指某个边界之外的，要与这个边界以内的事物进行交互的事物。因此关键是找到边界与actor。
我觉得游戏的用户并不是玩家，而是游戏控制器！一个动作就是一个独立的acotr，因为一个动作就是要从游戏引擎这个边界中获得一个结果。所以我认为所谓的用户是a,w,s,d,alt,space...等等，每按下一个键等于一个actor发出它的要求。我没做过游戏，只能瞎分析一下了：）比如按下w,表示一个前进actor在发出动作，它要做的事是分别向动作引擎，声音引擎，图形引擎发出请求，由这些边界内的事物作出反应。如果按下鼠左键，则向图形引擎，枪械引擎，弹道引擎等发出要求。

这个我纯属瞎说了，懂游戏的别砸我，呵呵

而解码器则纯属于计算密集型程序了，这种程序面向过程的方法更适合，面向对象方法相反不适合了

太谢谢了。茅塞顿开！

关于游戏actor的提示，不管游戏是不是这么做的，一下子突然打开了我的视界。原来 actor还可以这么样。

mp3解码库的东西，用面向过程方法更好。也解开了我长时间的困惑。

谢谢了。

不知怎么就进到这儿来了，觉得非常不错，就把你的文章都下载打印出来，认真的看了几遍，非常谢谢。最近也在想用这种模式来分析设计，但对于用户涉众的关系这块儿有个问题想问问，图书管理员与借阅管理员和书架管理员是一个什么关系，包含还是派生，包含的话是不是说把图书管理员的业务划分成借阅管理员和书架管理员的业务，如果是派生的话是不是在图书管理员那儿要定义些基本的业务，而借阅管理员和书架管理员在继承这些业务的基础上，还有自己的业务。

你的理解基本上是正确的。关于派生和包含的关系，也做include和extend，或者就是OO关系中的泛化(继承)和聚合关系。这几种说法语义上是等价的。

派生是自顶向下的来看的，由小到大，由简单到复杂，由普遍到特例
聚合是从底向上来看的，是由小到大，由简单到复杂，由基本到全面。

恩，谢谢，加深了我的理解了，顺便问问，你那设计篇的第三章什么时候出来，期待ing

-_-|| 拖很久了...不好意思了都...尽快吧。一周之内，应该

那可好！

“而解码器则纯属于计算密集型程序了，这种程序面向过程的方法更适合，面向对象方法相反不适合了”——相比解和N多人的困惑，这是学院派书里绝口不提的，景仰楼主1300下

想咖老大请教啊:
在第三篇中你说过业务场景图要把所有business actor和business usecase都用上，这章进一步说道“业务场景图可能不止一个”。是不是可以这么断定：可以画出N张业务场景图，每张场景图都包含了所有的business actor和business usecase？
感激涕零！

No,no, 不是一个场景要把所有用例都用上。而是说当完整的把表达用户需求的场景都画完以后，每个用例应该都能够至少一次的被用到。这样才能证明这个用例是有意义的，它是如何参与到业务场景中的。

明白！

顶

顶

Q：关于借阅图书和交纳借阅费为什么是两个用例呢？我怎么觉得是借阅图书一个用例呢。初学请多关照！

如果借一次交一次费，也就是交费是借书的一个步骤，那你说的是对的。如果交费可以独立于借书，比如一次交一年的，以后再借书就不用交了，那交费就是一个独立的用例了。

感谢楼主这么快的给与答复。努力学习中。出本书吧，保证第一个买（正版的），支持！

开发一个针对蓝牙耳机的声学测试仪器上的软件，是否适合用面向对象的方法去分析？

我认为完全适合。你有具体问题吗？

这类软件没有像图书馆那样的业务流程，只有测试方案及相应的技术要求，我分析的用户分为作业员和工程技术人员。那用例该如何写呢？作业员测试一只耳机是不是算一个用例？

面向对象分析技术不仅仅是指用例分析技术。用例是OOA方法之一，OOD，OOP都是面向对象方法。要明白，用例图中的Actor并非是指人。用例的概念是划出一个边界，边界以内是系统。凡是对边界内有要求的事物都是actor，凡是边界内完成要求的都是用例。从这个角度说，象这类非人机交互密集型的应用程序，一定有非人的事物存在。比如一个自动测试，actor就是系统定时器，或测试进程，测试表格等等。总之，什么东西向边界内发出要求并得到结果，什么东西就是actor。
再举个例子，CS游戏，你觉得actor是什么？是玩家吗？是玩家的手指吗？不是，游戏是靠什么驱动的？controller，controller是什么？是键盘，是鼠标。严格来说，是前进,后退，跳，开火...等等这些controller，每一个controller就是一个actor，它们对游戏引擎发出要求。

那像这类软件，各个硬件模块是不是也可以看作actor。当然这些模块也是需要软件去控制的。

当然可以。就看你的边界在何处

我对边界有点糊涂了，这些硬件模块感觉可以放到边界里也可以放到边界外，这类软件应该如何确定边界呢？是不是要根据系统的范围来定，如果是整个系统就放到边界里，如果是单指控制软件就放到边界外。

边界是帮助你分析的，边界也是可以调整和变化的。在分析的不同阶段，你可以采用不同的边界来帮助分析。这也就是为什么用例的粒度会有大小的原因。
比如一开始，边界是整个硬件系统，那么用例就只与几个开关或按键相关，再深入，边界定到某一个具体硬件模块了，用例就是由它的SPI或API代表的。再细下去，到了一个芯片，那用例就是由指令集代表的了。明白么？

明白了，系统分析不一定只指软件，不过对于设备开发的行业来讲没有人会这样去分析一个设备系统。我恐怕要成为第一个吃螃蟹的了。呵呵
还有一些关于用例细节的问题，如果按照游戏的例子，我分析的设备软件上的一些用例就是一些简单的动作，比如蓝牙耳机测试要用到的屏蔽箱，那就只有开箱和关箱了，对控制软件来说过程就一句，这样也算用例吗？

这样写出的用例，事件流就一句，我感觉有点不合适，这时是不是要写一些通讯细节。可这样的话就不像是分析了而是设计了。

那个不算是用例了。用例是一个完整目标。屏蔽箱只是测试过程中的一个步骤。要不这样，你把需求整个描述一下，我看看怎么分析合适。

蓝牙耳机测试软件主要控制屏蔽箱，Dongle（用来连接蓝牙耳机的模块），声学测试仪器来实现自动化测试。主要可以让作业员经过简单的培训就能在车间进行测试。
测试流程是屏蔽箱在关闭时会向软件发关闭的消息，软件收到这个消息后去控制Dongle去连接耳机，连接成功后，发消息通知声学测试仪器去测试，测试完成后断开连接，开箱，报告测试结果。

哦，呵呵，这么一说的话我原来还理解错误了，跟游戏情况不同了。
考虑这几个问题。什么东西是原始驱动力？产生的最终结果是什么？谁要这个结果？
如果，这个系统必须由作业人员驱动，不管是按个扭还是点下鼠标，产生测试结果是由作业人员来分析的，那么作业人员一定是actor!
如果，这个系统是由预先设定好的一个程序自动来执行，不需人工启动，测试结果也是由这个自动程序来读取的，那么actor就一定是这个自动程序。

你不需要关心什么控制屏蔽箱，Dongle....这些不是商业目标，因此不是业务用例。你将在业务用例场景里用到它们。

按你这个需求，作业人员 --> 测试蓝牙耳机 ，就这一个业务用例。别觉得少，的确就这一个。你还能找出别的商业目标么？

关于两种视图：
1、“从用户视角查看每个用户在系统中将参与什么业务”。
2、“从业务的视角查看每项业务是由哪些用例和哪些角色参与完成的”。

我困惑的是：
一个用例代表一个业务，针对一个业务又有一个业务视图。那是不是说每个用例都应该有一张单独的业务视图呢？但这样理解又不对了，针对“每项业务”的视图又包含了多个用例，那不是此业务包含彼业务了吗？这个“每项业务”是应该理解为现有用例中的一个，还是应该理解为比现有用例粒度更大一些的业务？如果这样理解的话，那为什么这个例子中即有“借阅图书用例”，又有“借阅图书业务视图”？

或者换种方式说：像“借阅图书业务视图”这种角度的视图是在站现有用例的角度上看它还涉及哪些其它用例，还是站在粒度更大一些的用例角度上看它包含哪些粒度更小一些的用例？如果是后者，那这些粒度更大一些的用例又是什么时候产生的呢？

十分困惑，望能详释。

你的困惑在于理解错了业务=用例。
业务并不等于用例。业务是实实在在的一个过程，用例是某个参与者的一件事。
举例来说，你去买药，药店的业务是把药卖给你。参与这项业务的有药剂师和收银员。对药剂师来说，他的用例是给你拿药，对收银员来说他的业务是收你的钱。这是从用户视角来查看的。
从业务视角来查看，就是有一个卖药业务，这项业务是由药剂师，收银员参与，由拿药和收费两个用构成的。
不知解释明白了否。

哦，这样说我就明白了。一个用例就是在一项完整的业务活动中参与者所要做的一件事。

这样进一步而言，我们去检查用例图是否完整可以有两个途径：
1、借助以用户为中心的视图，去发现还有哪些参与者做的事情没有被展现出来？
2、借助以业务为中心的视图，去发现还缺少了哪些人？以及这些人应该做的事？

现在的问题是，调研时在和参与者确认他所做的事时，可能会有所遗漏或描述不清楚，这时我们可以借助“业务活动视图”来加以验证用例是否完整。但我们又如何分辨出哪些是“业务”呢？

另外，“业务”的定义是什么呢？是不是可以理解为是一项“服务”呢？按我的理解：
就组织外部而言，“业务”就可以理解为它对外提供哪些服务。如图书馆对外提供“借阅图书业务”，“归还图书业务”，“办理图书证业务”。我觉得应该可以这样理解吧。
那么就组织内部而言，“业务”是否可以理解为一个部门为其它部门提供的服务呢？如果这样理解正确的话，那在图书馆内部又存在哪些“业务”呢？可否以一个部门为例加以说明？

接上面：

从网上找来的某图书馆机构设置：
图书馆设有采访部、编目部、流通阅览部、情报咨询部、系统与媒体资源中心（包括自动化部、媒体资源服务部）、古籍特藏部、数字化部、公共文献检索教研室、文献研究与编撰中心、办公室 。

我在第2篇文章当中提到，不论你采用多大的用例粒度，一个原则是用例的粒度必须是一样的。
“借阅图书业务”，“归还图书业务”，“办理图书证业务”这些更大的粒度是站在整个组织外部来分析的，而在图书馆内部又存在哪些“业务”呢？这时你又站在比如说采访部的外部去分析，这时的粒度相比前者就会小。如果在同一个分析阶段把这两个东西合在一起，不混乱才怪。
这个疑问是因为你的边界不清。用例只有从参与者的角度去讲才有意义。所以一旦你划定了边界，不论是整个组织还是只是采访部，那么这两个边界的参与者是不一样的，因此得出的用例也是不一样的。

再补充一点，事实上如果业务很庞大，采取逐步缩小边界的分析方法是很好的。例如一个涉及银行，保险，商店，个人，网站....一个很庞大的业务时，一开始的粒度一定是很大的，边界包含了所有这些内容。这些很大粒度的用例由于太粗几乎对编程没有任何指导意义，例如有一个银行的管理资金帐户用例。但是这些用例从高层次上分开了职责，从这个高度上看业务是完整的。
再接下来，我们就可以把边界缩小到银行的范围，看其它的参与者例如保险，商店，个人...是怎么要求银行的。这时就会得出料度较小的用例，例如开设商业帐户，开具支票等，这些较小的用例应当完整的表达并且完全实现管理资金帐户这个更大的用例。
如果感觉到这时业务还是太粗，可以更进一步缩小边界，比如只包括网上银行这个范围，又能得出更小粒度的用例....

希望你明白分析的前提条件一定是划定一个边界，并保持同一阶段的所有用例是相同的粒度。但为了分析得更清楚，边界是可以调整的。

嗯，清晰了许多。不过还需要在实践中检验我是否真的都弄明白了，目前正在努力中。有问题再找你哦，我肯定会是这个Blog的常客哦。
受益颇多却无法回报，只有小赞coofeewoo兄一句：“听君一席话，胜读十年书”啊。

问一个Rose使用问题（2003版）：
为什么在多个活动图中swinlane名称不可以同名，我看你的例子就可以嘛，“借阅人”就出在了好几个活动图中。
另外swinlane的字体也太小了，复制到Word中根本看清了，不知道字体可不可以调整？

哈哈，不好意思，是我理解错误，swinlane就像use case一样，可以创建一个swinlane，再在多处使用。但不能创建多个同一名称的swinlane。
不过字体的问题还是没解决

字体的问题是解决不了的了。我是为了让大家看得清楚把图片拷下来后再加工的

请教您一个问题,您说概念就是用例分析,形成关键业务的架构和解决方案,而且您也说过,概念化就是对业务用例进行抽象和归纳,总结,是站在逻辑角度去分析用例的.而且概念化其实主要是针对主要业务用例才会去逻辑分解的.那是否可以说,概念化的过程就是获取独立的逻辑业务,其实这些业务就是构成业务的架构的主要元素,也是构成解决方案的主要因素呢?

因为,对关键业务用例分解之后,这些业务逻辑的组合过程,就构成了关键的业务架构或解决方案了呢?

还有一个问题想请教您，我发觉业务建模阶段,是需要从企业内部组织结构的角度来观察有哪些业务部门,从每个部门找出一个业务代表,业务代表就是business actor(业务主角),从业务代表的角度去看有那些哪些事情要完成,这些事情就是业务用例.而每件事情中会有很多辅助参与者,但这些参与者参与的事情,是需要在概念阶段去分解出来的,这个过程经过逻辑分解,抽象等等分析过程,在系统阶段明确具体用户与计算机的交互内容,就可以明确系统建设范围内的事情.不知,上述过程对吗?希望多多指点,多谢啊!

第一个问题，答案是肯定。比方说一辆自行车的建造，参与者的目标是要能够骑行。 通过对这个用例的分析，能够抽象出踏板，传动装置，刹车等关键概念，再对这几个关键概念相互之间的关系进行定义，以及它们如何交互而实现骑行的目标，我们就可以说得到了解决这个问题的一个业务架构，也是针对这个问题的一个解决方案。当然不用踏板也是可以的，另一种解决方案可能是采用手摇的方式。那就会得出另一个架构。至于合适不合适，在演进过程中可以逐步验证和改进。
第二个问题，首先纠正一点，严格来说每件事情中会有很多辅助参与者的正式名称是业务工人（business worker），而不是参与者。在进行获得用例的时候，系统边界是整个业务，所以你的参与者是业务代表。但到了分析业务用例的时候，边界就缩小到了业务用例内部，边界改变意味着参与者的改变，这时原来的业务工人就变成了参与者，这时再来获得这些业务工人的目标。这些目标有的是需要计算机的，有的是不用的，有的是很难实现的，哪些目标需要用计算机来实现，就形成了系统范围。

coffee老兄,我今天很矛盾,本来,我做的很好,但老板觉得我做的不够好,辞退了我.我好矛盾,我做事很认真的,但他却觉得我太有个性了.是不是我做的不够好,做事不够认真啊!!!!!!难道追求完美也是过错吗???给我点指点,好吗???

coffee老兄,我今天很矛盾,本来,我做的很好,但老板觉得我做的不够好,辞退了我.我好矛盾,我做事很认真的,但他却觉得我太有个性了.是不是我做的不够好,做事不够认真啊!!!!!!难道追求完美也是过错吗???给我点指点,好吗???

不必烦恼，做IT这行的，哪里不是容身之处？老板要辞退一个人有N多的理由，不过他对你说的理由只会是因为你的错。所以你不用觉得是自己不好。
怎么说呢，我不了解事情的来龙去脉，但从职业角度来说，做事情要认真，但不能较真。追求完美有没有错？因时因地而宜。有时候完美和商业利益是有冲突的，在老板看来商业利益永远比完美重要，毕竟是做生意，不是做艺术。有时候有所取舍也是应该的。不论是MS，IBM还是Oracle，都没有完美的产品。只能说，抱着追求完美的态度做事，平衡与商业利益的关系。

Coffeewoo兄，前段时间看了你的文章后，感觉明白了许多，于是这段时间一直在想法付诸于实践，但感觉做起来好困难啊，

想想还是和你说说我现在的工作情况吧，希望可以藉由你对这些实际工作的指点，让我走出混沌的世界。

我现在是在对一个已完成的软件模块（反贪污贿赂局办案子系统）做二期开发的需求调研，我的想法是分成这么三步来做：

1、还原初步的业务模型：先弄清现有的程序实现功能，再参照相关的业务手册及咨询同事，还原出现有模块已实现的用户业

务（需求），形成一份初步的需求文档，就像你例子中的那份文档一样，希望这份文档可以达到两个目的，一是现有程序实

现了哪些用户业务？这些业务在没有计算机的情况下是什么人做的，怎么做的？对应的是你文档中的用户需求（业务用例）

。二是针对每个业务有多少工作已由人工完成转为了计算机来完成。对应的是你文档中的系统需求（业务用例实现）。经过

这一阶段的工作后我应该清楚现有系统的实现范围了。

2、比照、修改模型：拿着这份已经清楚说明了现有系统实现范围的文档以及现有程序，去和客户沟通业务用例，看看我们对

已实现业务的理解是否正确？哪些业务需要变更？或者还需要增加哪些业务？如果是要变更，那么相应是要更改业务人员与

系统的交互内容还是交互范围？如果是新增加的业务，那这个业务现在是如何实现的？有哪些部分需要交由计算机来处理？

然后把这些改变纳入到最初的那份需求文档中，并能表现出变化了的和新增的部分。经过这一阶段的工作后，我应该能知道

本次开发的范围了。

3、分析模型：然后在这份需求文档的基础上做进一步分析，结合现有软件功能，画出所有要修改的和新增加的系统用例，程

序员再藉此做进一步的开发。

在我开始提出一些具体的问题之前，我还是先简单介绍一下反贪污贿赂局的业务角色和业务目标吧，反贪大概可以分为三个

业务角色，内勤、承办人、领导。内勤负责举报线索（案件）的受理及登记工作，承办人负责对线索（案件）进行查办，领

导负责分派任务及督导查办过程。反贪局的目标接受举报线索，先对这些线索进行初查，如果举报属实的就立案侦查，构成

犯罪的移送公诉部门去起诉相关嫌疑人。
上面讲得比较简单，如果有什么不明白的地方我可以再说详细些。

下面说说具体的问题，我现在还处在计划中的第一步，还原初步的业务模型。
这一段我感觉找出用户需求（业务用例）很困难，主要是很难划清业务用例，这可能正如你说的那样，我对用例的粒度和边

界的认识还不够，以受理线索业务为例，这一业务的大致过程是内勤收到控申部门转来的举报线索，登记后，填写受理审批表，将它交给领导审批，领导则在审批表签字审批，可能的审批结果是受理、不受理、留存缓查。内勤拿到已批示的审批表后就根据审批意见做继续处理，如果审批意见为受理，就在已受理登记表中做一下登记，然后把举报材料交由领导指定的承办人去办理。如果是不受理，就把线索材料交还给控申部门。如果是留存缓查，就在缓查登记表中做一下登记，并把材料存放起来，待以后条件成熟时再查办。

针对这个业务我有两种划分方法：
方法一
内勤：登记报批、退回线索、缓查线索、转交承办人。
领导：审批受理。
方法二
内勤：受理线索

这两种方法我都感觉不太合适，第一种方法太细了，按这种方法划分的话，用例就很多，而且审批也会很多种。第二种方法又感觉太简单了，而且这样划分的话，那么领导这个角色就不会有任何用例了，因为他参与业务的方式就是审批。而且这样划分的话，“受理线索”这个业务用例的实现用例又是什么呢？还是只有一个“受理线索”吗？或者是再划分成退回、缓查等。

想听听Coffeewoo兄的看法，也欢迎大家一起发方讨论。（我后续还会有一系列的问题）

你的步骤没什么问题，按照执行应当可以得出比较满意的结果。
你的结果里我赞同第二种方法，这是正确的业务。领导没有用例很正常，如果他不是主动去启动一个任务的话，他作为参与者身份都是可疑的。在你描述的受理线索这个场景里，领导只是作为一个business worker存在，所以他没有用例是正确的。
另，描述的那些业务过程，全部都是受理线索业务用例的场景。至于第一种划分方法中列出的那些，是这个用例场景中的关键业务，在概念阶段把它们提取出来比较合适。

问题二：业务用例可否包含子用例？。
这个阶段的业务用例是否可以包含有子用例？例如线索受理后就是去初查线索，按阶段可以分为三个业务用例：

分析评估线索、实施初查、终结初查。

而这三个用例都比较大，太粗不好分析，个人感觉需要再划出这三个业务用例都包含哪些子业务用例才觉得清楚一些，如“实施初查”可以分为：

走访举报人、走访被举报人单位等子用例。

不知道这样做可不可以？

问题三：在业务场景图中如何表现子业务用例？
如果问题二的答案是肯定的话，那么画业务场景图就困惑了，因为“实施初查”和“走访举报人”不是一个级别的用例，画在一个业务场景图中肯定是不合适的，那如果只画“实施初查”这一级用例的话，初查业务场景中只有四个用例：受理线索、分析评估线索、实施初查、终结初查。如果是这样的话就无法通过业务场景图去达到“搞清楚哪些业务没有分析到”的目的。
针对这种情况该怎么办呢？是只需要做到这一步就可以了？还是可以通过别的办法来表现这些子用例呢？

问题四：针对有分支的业务该如何划分用例？
初查的最后一个阶段是终结初查，这个时候可能有三种情况出现，(1)被举报的人都有犯罪事实，那么承办人做立案处理。（2）被举报的人都没有犯罪事实，承办人做不立案处理。（3）部分有犯罪事实，部分没有，那么一部分做立案处理，一部分做不立案处理。

那么对这种情况划分业务用例时，我是划一个“终结初查”用例，再在它下面划“立案”、“不立案”做为子用例好，还是只划“立案”、“不立案”这两个用例而不把“终结初查”做为一个用例好呢？
碰到这种情况的划分的原则是什么呢？

问题二：当然可以包含。对用例来说，你可以使用的手段有includeextendrefinegeneralization，“实施初查”和走访举报人、走访被举报人单位就是一种精化关系
问题三：在业务场景中不需要画出子用例的场景。我不明白为什么你会觉得受理线索、分析评估线索、实施初查、终结初查没有说清楚，在这个级别上，关键业务已经齐全，很清楚了啊。接下来，再针对受理线索、分析评估线索、实施初查、终结初查一个个去画它们的场景。
问题四：针对有分支的业务该如何划分用例
凡是目标相同的，都只能是一个用例。象你说的情况是不同的用例场景。如果分支不明显，保持一个用例实现就行，只不过加点判断而已。如果分支明显，那么可能就需要提取概念用例，采用inludeextendsgeneralization等手段从中抽取出关键概念。然后通过多个用例实现去实现基本的业务用例。

路过，看过，收益过！！ 不顶不行！！！

不仅仅对楼主的知识佩服，更对楼主的精神和人品赞扬。
楼主给我们做了榜样，向楼主学习！！

－－－－－－－－－－－－－－－－－－－－－－－－－－
附带：现在很多人都恃才自傲，不可否认他们的知识令人折服，但他们的人品却大打折扣。

看了，收益很深。但对其中的一些概念的划分还不是很清晰，比如文中说业务流程必须包含所有的用例，那么业务流程和用例的流程怎么区别？请指教？

业务流程是整个业务领域的过程描述，而用例的流程则仅仅局限在用例内部。
例如，你到银行开设帐户。对于整个业务领域的业务流程来说，除了跟你有关系的，比如在柜台上填单，设定密码等，还有后台银行内部处理的一系列工作。
但是对你来说，开设帐户这个业务用例并不需要包括那些后台的工作，后台的工作是属于银行内部的用例，与你无关。也就是说，你的业务流程只需要拿到存折就结束了。而整个业务领域的业务流程，则还需要后台的一些用例。
从整个业务角度来说， 你的用例是整个业务流程的一部分。但对于你的用例，则有自己的流程。

我们从用户的角度来发现业务用例，但是有的系统除了与Actor交互的部分外，还有比较复杂的内部逻辑，或者象计费系统一样支持很复杂的费率，这样的内容在需求说明规范中能够用用例来描述吗？

对于象MSN这样的软件，Actor有哪些呢？Contact,network,audio device, video device是否是Actor？还有其它的吗？

类似费率计算这类计算密集形的需求是不适合用用例描述的。用例只能描述谁做什么以获得功能性需求。不管你计算多复杂，从功能性需求来说，都一堆输入进去然后得到一个结果，输入不同不决定功能性需求不同。
这些内部逻辑要用单独的算法设计和文档化。

讨论Actor必须先确定边界，边界外的是actor。如果边界是整个MSN，那么actor就是MSN用户，你说的那些都是边界内部的或用例或业务实体。

很实用,非常感谢!

大哥的文章太好了， 正好在做业务模型，没有经验无从下手的时候，现在思路清晰多了，多谢，多谢！

疑问：业务场景图存在多个的疑问，VIP客户借书和普通客户借书，在界定系统边界，确认业务用例，然后定义借书这一个业务场景图[借阅图书交纳借阅费借出图书退还图书]来说，是应该没有区别的，如要让它们之间有区别，必须得重新确认业务用例，要不然区别怎么样能在业务场景中体现出来呢？

您说业务用例在定好系统边界后确认，系统内的不属于同一层次的业务用例，我觉得VIP和普通客户的分类，不是在您本文定义的借书业务场景图中的用例，它应该是系统内去确认的事情，哪我们在做需求分析时，怎么把这些问题描述清楚呢？