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

大师，请恕愚笨还在唠叨：
1、愚笨所困惑的，是人儿图存在歧义，而非是否“详尽”。任何一张图都无所谓，关键的是存在歧义就会导致客户与内部人员之间在理解上出现误区，如果依此设计、编码，难免不张冠李戴；
2、据说，UML的五大类图中，负责与客户沟通的，仅仅只有人儿图。大师所谓“我们只是拿那些uml图来和他交流而已”的UML图，不知是仅指人儿图，还是指包括其他图？
3、大师所云“我们通过这些图来和客户交流需求详尽及正确与否，对客户领导来讲我们不要求他们懂这些，只要我们懂就可以了，我们拿这些沟通、记录、分析，为我们下一步设计做铺垫。”，是否可以理解为：人儿图并非用于与客户的沟通，而仅用于内部的“沟通、记录、分析，为我们下一步设计做铺垫。”？
4、大师所云“我们没要求客户懂这些，只要求我们做需求分析的懂这些就够了”，不知您的客户是凭什么来确认你的需求分析报告准确反映了他的需求的？
5、关于甘特图，再说一次，我们并不讨论它是如何来的，也不讨论它起什么作用，只是讨论它的可理解性而已，换成柱形图、点线图或饼图也都可以，这些图都具有很好的可理解性，读图不会产生歧义。而UML的人儿图却极易产生歧义，
6、歧义的存在，势必会导致后续过程信息失真。这绝非大师所言“是一个度的问题”。无论你放到什么度，该有歧义的他就是有歧义，利用一张人儿图来解释另一张人儿图的办法是不能消除歧义的，只会引起更多的歧义。某美国大师甚至在其著作中承认，“由于教育水平、文化背景的不同，对用例图的歧义理解是无法克服的”。愚笨在楼主的图中随便就能找出歧义来，正好印证了美国人的悲观论点。

zhuyx808提出的问题非常犀利，其实也是我们大家一直在探讨的问题，我来说说我的理解吧。

多年以来，我也存在这同样的困惑，怎么拿着用例图与客户沟通呢？他们看得懂吗？为此我也做了许多的尝试。随后我看了Eric Evans的《领域驱动设计》，逐渐领悟到其中的精髓。

在《领域驱动设计》中Eric Evans有一段精彩的描述，用情景对话真实反映了需求人员与客户的沟通过程，一个是正确的过程，一个是错误的过程。在错误的过程中，需求人员运用了大量的计算机术语，把客户侃晕了，沟通效果可想而知；而正确的过程，需求人员将计算机知识转化为客户可以理解的语言，同时学着用客户所在领域的语言，去与客户沟通，这就是该书提出来的统一的语言。

这个统一语言是一个混合语言，你在向客户学习，同时客户也在向你学习。就拿用例图来说，图中的小人儿，你可以告诉用户，这不是代表某个具体的人，而是扮演某种角色的人，以及透过这个角色所体现的在系统中的权限。毫无疑问，普通用户在系统中可以做的事，扮演具体角色的人都可以做。

同时，我们也应当向客户学习，用他们的语言去描述这个系统，这体现在我们对用例的命名，以及之后的描述中。

图是死的人是活的。诚然，我们在学习UML的时候得花费大量的时间，但真正到我们要运用它的时候，一切的规则都不再重要。用最清晰的方式绘制我们的图，用最简单的方式描述我们的图，甚至出现一些不符合用例图规则，但你与客户都能理解的。

过去我们把UML当成阳春白雪高高挂起来，总是在担心画对没画对；现在，别担心了，UML画对没画对，只要你与客户都能理解就可以了。过去我们总是用Rose这样的工具认真仔细地绘制，为画图而画图；现在，一张纸，一支笔，随心而画，需要的时候才画，画图是为了更好的表达。

最后，图形表达形象生动，这是它的优点，但表达不严谨，不能表达所有要表达的意思，所以图形之后的描述格外重要。做用例模型、做领域模型，30%在绘图，70%在编写文字说明。

“每日自动触发”，lz你忘记了时间是一个真实的角色。应该是一个小人

在我的文章里写得很清楚：

大师果然是大师，“过去……总是在担心画对没画对；”，“现在，别担心了，UML画对没画对，只要你与客户都能理解就可以了”，大道无形了，嘿嘿~~
可惜，大师只承认了“图形表达……不严谨，不能表达所有要表达的意思”，而始终不肯正视和承认这些图形在交流过程中存在的各人理解的歧义，而歧义的存在才是交流或沟通中的真正大敌。一句话，不详尽你可以补充，而理解不同则难以补充了，甚至往往不到最后关头你未必会发觉理解上的差异。
大师说“30%在绘图，70%在编写文字说明”，不知道是怎样统计出来的？据《软件需求管理(统一方法)》(http://ishare.iask.sina.com.cn/f/16963061.html)所说，“在大多数系统中，不超过10%的需求需要形式化方法”，那是比大师少多了。当然我也不知道外国人是怎样统计的。

大师倒谈不上，不过你这是在较真

较真倒谈不上，只是大师在本贴中教育我们“应当怎样做需求分析”，固然不应看到大师面对需求分析过程中出现的根本问题采取回避不谈的鸵鸟态度。
继续引用《软件需求管理(统一方法)》的一段话：
“尽管正确性对于任何需求显然都是最关键的，而歧义性也往往成为一个较大的问题。如果项目开发人员、用户以及其他风险承担人对一条需求有不同的解释，那么所构建的系统可能完全不是用户想要的。”

没错，歧义是需求分析中必须着重解决的关键问题，关键是怎样去解决。图形具有诸多的优点，但它最大的缺点就是无法避免歧义的出现。但图是死的，人是活的，我们可以有诸多办法解决图形中的歧义：

图形，往往代表的是一种符号，关键是交流者与被交流者怎样对图形中各个符号的意义达成一致。这就是我前面说的混合语言：通过沟通，你与客户对图形中的各个符号达成一种默契。

另一种方式就是文字说明。首先对图形中的名词（即实体），其内涵外延做明确的定义，然后是对图形中的各个关系的说明，最后对各个流程、各种操作进行说明。用例模型有用例模型的说明，领域模型有领域模型的说明。通过说明，把需求中各个方面的事物都清晰地表达出来，歧义自然会消除。

在编写说明的同时，我们与客户在认识上的歧义会逐渐展现出来。客户会发现，我们表达的并不是他们所想要的。他们会进一步地向我们说明，我们也会仔细地去理解。经过这一来二去，歧义就会消除。这是一个过程，一个反复沟通的过程。

需求中的用例图没有绝对的正确，也没有绝对的错误，关键看你的客户能否理解。如果通过沟通，客户理解并认可了你的表达，这就是正确的；如果客户依然表示不解，那么你可以选择其它客户能够理解的方式表达。毕竟，图形就是帮助我们沟通与理解的一系列符号。

用例图确实不太适合用来与客户沟通，至少在国内行不通~
我一直把用例图当做一种分析工具，而且尽量压缩其所占的比重。
（首先是业务流程分层分析，然后在末级流程下面扁平的做一层业务用例分析，识别出业务规则和领域模型后转入详细设计阶段。。。）

这里面其实有两个问题：
1.用例图这种形式到底适不适合与客户沟通，客户告诉我们不太适合~
2.带着系统思维的“业务/系统”用例分析是否合理有效，是否最佳实践？有待探讨。。。