我们应当怎样做需求分析：功能角色分析与用例图

在我们进行一系列需求调研工作的同时，我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司，我们就应当对需求调研的成果进行一次需求分析。当下一次开始进行需求调研时，我们应当首先将上次需求分析的结果与客户进行确认，同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。

但是，当我们经过一番忙碌，将需求中的第一手资料从调研现场捕获回来以后，我们应当怎样进行分析呢？不少团队对此都比较迷茫，没有一个统一和有效的方法，往往采用想到哪里做到哪里的方式。一些问题想到了就做了，没有想到则忽略掉了。实际上，需求分析不应当是太公钓鱼，而应当是拉网排查。任何一个疏忽都可能对项目研发带来风险。因此，我们应当采用一套成熟而完整的分析方法，稳步而有序地完成这部分工作。不同类型的软件项目其分析方法可能存在差异，但一般来说，信息化管理类软件项目通常从这几个方面着手分析：功能角色分析、业务流程分析与业务领域分析。

需求分析不是一项一蹴而就就可以完成的工作，它需要一个长期的过程，而这个过程是一个由粗到细的过程，它体现了人类认识事物的客观规律。在需求分析的初期，我们对需求的认识往往是整体的、宏观的，随着分析工作的逐渐深入，一步步细化。按照这个思路，我们对需求的分析，首先应当从功能角色分析开始。所谓功能角色分析，就是从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底是提供给哪些角色使用。

对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。用例图是UML的4+1视图中的一种，准确地说就是那个“+1”。用例图是贯穿整个面向对象分析/设计（OOA/D）的核心视图，它描述的是系统到底为用户提供了哪些功能，以及到底是哪些用户在使用这些功能，是沟通用户与技术人员的桥梁。运用用例视图对业务需求进行分析、抽象、整理、提炼，进而形成抽象模型的过程称之为用例建模，而这个模型就是用例模型。

一般地，在一个用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary）。用例描述的是系统为用户提供的功能，也就是系统能为用户做什么，通常被绘制成一个椭圆；参与者，我认为称为角色更加合适，也就是系统为哪些类型的用户提供服务，他们都各自承担哪些不同的职责，通常被绘制成一个小人儿；最后是系统边界，也就是系统是对现实世界哪个范围的内容进行的模拟，它涉及到软件设计的工作范围与工作量，通常被绘制成一个方框。但是，通常情况下系统边界只是一个概念而不用真正绘制出来，因为被绘制成用例的必然是系统内部的功能，被绘制成参与者的必然是系统外部事物。从这个意义上讲，用例图中的参与者不仅包括人，还包括那些外部系统和自动触发器。根据这样一个思路，我以往常常将外部系统和自动触发器绘制成一个小人，这常常令客户感到困惑。随后我改变了思路，将外部系统和自动触发器绘制成另一种表达形式——类元符号表示法，并在构造型上标注为Actor。



上图是一个考核系统中一个子模块的用例图。图中的用例就是这个系统提供给用户的各项功能。注意，这里仅仅是在罗列功能而不表示它们之间诸如流程调用等相互关系，这是一些初学者常常犯的毛病。参与者与用例通过实线关联起来，代表的是一种使用关系。箭头代表的是一种导航，即动作施与的方向。在这个用例图中，普通用户执行查询操作，查询系统提供的“预警监控单项查询”、“预警监控汇总查询”等查询报表；每日自动触发器触发自动考核功能，自动考核功能从“税收征管系统”这样一个外部系统中采集数据。

图中考核管理员和执法人员代表的是两个完全不同的角色，但他们在这个图中体现的是一些共有的特性，即对这堆报表的查询，因此被绘制成继承自普通用户。继承是参与者间唯一的关系，代表继承者拥有被继承者所有的功能与权限。除了参与者以外，用例与用例直接也存在着一些类型的关系，这我们在后面详细讲述。

在绘制用例图时一个值得思考的细节是，用例是怎样通过分析获得的。这个问题，在一些客户对信息化管理比较有经验的项目中不存在问题，因为在客户提供给我们的需求文档中就清晰地划分出了一项一项的功能。这些功能可能会在日后的需求分析工作中有所调整，但它从整体上形成了一个雏形，成为我们进行用例分析进而形成用例的依据。

但当我们面对的是一些对信息化管理没有经验的客户，情况就有些不妙了。在这种情况下，通常客户只能给我们一些管理目标、基本想法，其它的调研工作就需要我们自己去做了。这时，我给大家的建议是，首先从组织机构上划分清楚系统涉及哪些部门、哪些科室，然后在这个基础上划分出来这些部门这各个科室的人员都扮演哪些不同职能的角色，以及完成哪些业务操作。系统中的一个功能，在一般情况下是组织机构中某个（或多个）角色，为该机构某项业务流程完成的某个操作，并且这个操作应当有某个确定的结果（即产出物）。而这个功能就是我们需要提取出来的用例。虽然功能角色分析在整个需求分析过程中可能会随着认识的深入而不断调整，但分析过程大体是这样进行的。

有人说，我们绘制的用例图拿给客户看不懂。这样一个清晰明了的用例图，辅之以我们对图形的描述，客户怎么会看不懂呢？关键问题在于，我们没有将用例图的精髓弄明白，再加上出现一些常见问题，使得用例图画得不伦不类，客户当然就看不明白了。现在我们看看用例绘制都有些什么常见问题。

1. 没有正确理解用例图的视角。前面我反复强调了，用例图的视角是用户，也就是说，站在用户的角度来观察的我们需要设计的系统。从这个视角，用户看到的系统是什么呢？当然是一项一项的功能，这些功能是客户能够理解的、具体的、对客户存在价值的功能。从这个意义上说，那些技术性的功能不应当出现在这里，或者应当描述为用户可以理解的文字，比如“自动考核”。而那些应当绘制的用例，在取名时也应当站在用户角度去取名。举个简单的例子，一个员工档案信息系统，以往我们总爱将用例取名为“添加员工信息”、“更新员工信息”、“删除员工信息”，这就是典型的技术人员编写的用例。“添加员工信息”对于用户来讲应当是做什么呢——填写新员工资料；“更新员工信息”对于用户来讲又是做什么呢——更改员工资料；“删除员工信息”又是什么呢——员工注销。不论是“填写新员工资料”、“更改员工资料”，还是“员工注销”，对于客户都是日常工作中需要完成的操作，将用例命名为这些名字必然为用户所理解。同时，每一个用例对于用户来说应当是有价值的，也就是说，用户使用这个功能是要完成一项操作，或获得什么信息。比如上图的“自动考核”会产生一批考核结果，执行“预警监控单项查询”可以获得预警监控结果数据。

2. 图形绘制杂乱无章。一个系统，特别是一个大型系统，提供给用户的功能是繁杂的。如果你想将所有的功能，不管粗的细的，都试图绘制在一个用例图中，几乎没人看得懂。我们之所以将分析设计图形化，是因为图形能给人形象立体的感官，使人立即就明白了其中的意思，但前提是，这个图形是主题清晰的、形象生动的。因此，我们绘制用例图要学会拆分，由粗到细地一个一个绘制。先整体的绘制，再划分成各个模块一个一个详细绘制，再进一步细化。所以，描述一个系统应当有许许多多的用例图。

3. 用例是一个场景。在现实世界中，我们常常面对的是一个个长而复杂的操作流程，但在软件世界里，我们要将它们拆分成一个个的用例，怎样拆分？一个用例必须有一个场景，也就是时间相近、地点单一的一系列操作，并且这些操作最终应当有一个明确的结果。



如上所示这个用例图，“申辩申请”就是过错责任人填写了一张申辩申请单，最终的结果是将申辩申请单提交给考核管理员；“申辩受理”就是考核管理员接收了过错责任人的申辩申请单并予以受理，当然另一个结果是对其不予受理，该申请单被退回给过错责任人。每个用例都有确定的场景，明确的目的和结果。

功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。但仅仅进行功能角色分析是远远不够的，我们还需要在它的基础上做更加详尽的分析。

我们应当怎样做需求分析
我们应当怎样做需求调研：初识
我们应当怎样做需求调研：拜访
我们应当怎样做需求调研：研讨会
我们应当怎样做需求调研：需求研讨
我们应当怎样做需求调研：迭代
我们应当怎样做需求调研：需求捕获（上）
我们应当怎样做需求调研：需求捕获（下）
我们应当怎样做需求分析：功能角色分析与用例图
我们应当怎样做需求分析：业务流程分析（上）
我们应当怎样做需求分析：业务流程分析（下）
我们应当怎样做需求分析：用例说明
我们应当怎样做需求分析：查询报表分析
我们应当怎样做需求分析：子用例与扩展用例
我们应当怎样做需求分析：行动图和状态图
我们应当怎样做需求分析：业务领域分析
我们应当怎样做需求分析：原文分析法
我们应当怎样做需求分析：领域驱动设计
我们应当怎样做需求分析：非功能需求
我们应当怎样做需求确认：需求列表
我们应当怎样做需求确认：一个需求列表的实例
我们应当怎样做需求确认：快速原型法
我们应当怎样做需求确认：需求规格说明书
我们应当怎样做需求确认：评审与签字确认会

（续）

文章更新了一下。昨天跟中软一位主管聊天时谈到了这个问题，这位主管对用例分析这方面十分有经验，并且给我了很好的建议，然后我就加进去啦。再次对他表示感谢。

大师，就这个你认为很“清晰明了”的图，还是很不懂的，我们都很愚笨。好比说，“普通用户”、“考核管理员”、“执法人员”这三个小人儿所代表的意思，我们就很不明白：
1、“普通用户”仅由“考核管理员”和“执法人员”组成(全集关系)；
2、“普通用户”由“考核管理员”或“执法人员”组成(超集关系)；
3、“普通用户”可以由“考核管理员”和“执法人员”组成，也可以由其他人员组成(子集关系)；

但就图看来，很容易引起理解上的歧义。

如果你要求客户在头晕眼花地看完一大堆人儿图之后，再对应地看一大叠文字说明，你认为这些日理万机的领导们会有这耐心么？
领导当然绝不会承认他看不到这件漂亮的皇帝的新衣，但他一定会说，嗯，这些图画的很好，请你们回去再研究一下。
如此一句话，你什么时候能包胆把项目合同签下来？

其实单独这样一个图对客户或其他人来讲都不是很清晰，但是如果说这个图只是最终分析过程的一部分的话，那么接下来就会有更详细的视图去描述里面的内容。更详细的视图中有描述各种用户对系统的各种操作和交互，最终能一直细化到系统、组件、类、方法，那么当我们把所有步骤走一遍的时候，各种难题、难点、工作量最终都会有一个清晰的划分，如果你还是一个管理者的话，综合所有资源会得出一个比较详细的规划和项目的盈亏。

我所以蓄意选用这张图，是因为这是一张“用例图”。据说，根据内外有别、先外后内的原则，用例图是为了与客户沟通而设立的。又据说，UML是要经过一定培训与练习才能掌握的。我不知道缺乏“一定培训与练习”的客方领导在一大堆于他深奥莫名的用例图前如何跟你沟通，但至少我是感到图中存在歧义。我更不知道，组件、类、方法这些羞涩难懂的专业术语面前，领导是否还能保持他那嫣嫣笑容。他需要关心这些细节么？他有关心这些细节的能力么？
简单滴说，我感觉用例图在对外沟通方面，未必已达到其设计目标。不信你对比一下甘特图，领导很容易能看明白你要做什么。至于对内尚具多少沟通的便利，暂且按下不表了。对于领导来说，让他去“综合所有资源”以“得出一个比较详细的规划和项目的盈亏”，他会不会瞪大眼球怒嚎，我要你们这些手下干什么！他只要能够理解你这个方案合不合理、可不可行，然后决定拍不拍版。人儿图其实真的不见得好理解。
谈到“如果说这个图只是最终分析过程的一部分的话，那么接下来就会有更详细的视图去描述里面的内容。”，倒使我想起了当年的托米勒宇宙模型，为了证明地球是宇宙的中心，托米勒不惜在星球轨道上一再叠加圆轮。但最后是哥白尼证实了地球确确实实并非宇宙中心，加多少圆轮都无济于事。UML会不会正在重复托米勒的前車之覆呢？一张图不好沟通，一万张图就好沟通了？

fangang大师上面有说明：
辅之以我们对图形的描述

跟客户沟通不是简单的把图直接发过去了事的。

楼上您也提到了甘特图，那我想问下，这个甘特图是一拍脑门直接就出来的吗？为啥讲如果是领导者，一个项目经理也是一个领导者，你们团队多少人员，多少稳定人员，多少技术牛人，多少新人，有多少流动量，每人的大致成本是多少，时间成本是多少，工作量的多少，等等等等这些东西不都是根据后面的各种详细图出来的吗，如果没有这些依据，那请问您的成本估算怎么来的，盈利怎么来的？从一拍脑门，在到一拍胸脯，一直到最后的拍屁股走人，有多少项目就是因为这三拍造成失败的？看文章要看精髓，fangang大师把这些东西讲出来我觉得对我们大家来说都是一个吸取知识的过程。当然我本人也没看过多少fangang大师的文章，我只是觉得楼上您看文章有点片面了，当然我也只是对事不对人，如有哪些说的不对的地方您大可批驳，小子虚心接受

这位大师见笑了。
1、听说人儿图是用来与客户交流、描述客户需求的，不是给项目经理核算内部成本的。我们确然愚笨，不明白大师怎么从“与客户交流、描述客户需求”扯到内部核算上来了，“精髓”在哪里？楼主的标题，也是“主题：我们应当怎样做需求分析”吧，并没有去谈论成本核算或系统设计、系统实现吧？
2、愚下前面所谈论的，确然“片面”滴仅谈需求描述，而且我的困惑也在于人儿图如何让未受过任何UML训练的客户领导“很好理解”其需求而不产生歧义，烦劳大师不惜笔墨再点一二；
3、似乎愚下并无谈论人儿图是亲手送达客户还是“直接发过去”，这些沟通的技巧不知与“需求的准确描述”及“描述的正确理解”是否相关？
4、愚下以甘特图为例，是说明甘特图“很好理解”，不需要什么训练，而人儿图在未经受UML训练的客户面前并非“很好理解”。我的困惑是，为什么UML要选择一个必须经过严格训练才能“很好理解”的人儿图来描述需求，到底是为了更便利于与客户的沟通还是为沟通设置障碍？至于大师问及这些图是怎样“出来”的，我似乎尚未关心到底是“直接”的还是“曲接”的，是不是？
5、以上论题，简结为两点：
一、人儿图胜任准确描述需求否？(存在歧义)
二、人儿图胜任便于沟通否？(需要培训)

需求分析也是一个渐进的过程，我们不可能通过上面您引用的那张图就把所有的需求分析详尽，您上面引用的那张图本身就是一个大纲图，在和客户沟通需求的过程中我们按照大纲里面的各个功能模块分析就能做到详尽不遗漏。对于让客户理解完全不是通过这个图来完成。对客户来讲：我们只是拿那些uml图来和他交流而已，对他们来讲意义不大。对我们来讲意义很大，我们是通过这些图来描述客户需求的。

1、您说的确实没错，但是您上面引用的这张图本身就是一个大纲图，点进每个图形里面会有更详尽的需求分析。当然限于不同的公司采用的方法不一样每个公司的流程都不尽相同，至少我现在的公司就是采用的这种方法，公司有机密要求我也不可能发上大纲图和点进去之后的各个详细需求分析图，这个还请见谅。
2、对客户来讲：我们只是拿那些uml图来和他交流而已，对他们来讲意义不大。我们通过这些图来和客户交流需求详尽及正确与否，对客户领导来讲我们不要求他们懂这些，只要我们懂就可以了，我们拿这些沟通、记录、分析，为我们下一步设计做铺垫。
3、您说客户不懂这些UML图，我们没要求客户懂这些，只要求我们做需求分析的懂这些就够了。
4、甘特图的出现只是后期出现的，而这个后期从何而来，就是从前面的需求分析，及至后面的全局分析全局设计局部分析局部设计……这些过程后出现的。


如果您要看实际项目中的这些图，可以发邮件，我可以截几张图给您看看。

那么，对于您的论题一，我觉得是要看怎么理解这个问题了，有的说可以，有的说不可以，这其中无非就是一个度的问题。对于您的论题二，也要看怎么去使用这些图了，您觉得那？

"一般地，在一个用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary）。"

基本上所有相关资料都是这么写的，但是有没有人想过这种定义会导致一个严重的后果，那就是业务与设计耦合，其实用例是分为两种形态的，一种是业务用例另一种是系统用例，我们能看到的资料可以说99.9%都是围绕着系统用例展开的，但同时大家又都很清楚业务需求的重要地位，要客观的、独立的对业务需求进行分析，就应该抛开一切系统思维，还原业务原貌，这就涉及业务用例怎么来的问题。。。

也许有人会说这种只是很轻度耦合，影响不大，但要意识到这是一种分析方法的开端，它决定了后续分析工作的指导思路，意义还是很重大的。。。

严重赞同。
我的感觉是，正由于人儿图分不清业务用例与系统用例，现有能看到的图很多都把本该向客户隐蔽的系统信息全部暴露了出来，严重影响与客户的交流。