9年前，我们开发一个商业连锁公司的业务管理系统，开发组兴致勃勃地第一次使用了UML建模语言进行系统的分析和设计。开发组花了大概2个月的时间完成了对业务系统的分析，并使用Use Cases描述用户需求和软件功能------尽管对这两个元素的区分那时还经常混为一谈，最后形成了一个几十页的需求文档。装订成册后，一天下午由项目经理和一个博士分析师两人去甲方哪里沟通，并期望对需求达成一致，并获得甲方的签字。大家认为，使用这样清晰和结构化的表达方式，需求真的已经比较清楚了。可是，意想不到的事情发生了。
甲方看了文档后，说“我看不懂！……我不能签字！”后来，无论我们的项目经理和博士怎么一一就需求讲给他听，他都无法，或者不愿意把听到的和需求文档里的那些陌生的符号（小人和椭圆）关联起来------他不相信他看不懂的东西，他无法对他看不懂的东西承担责任、签字画押。生气的自然是我们的项目经理，可是甲方错了吗？
其实，这是一个典型的甲乙方沟通问题。而问题的关键是，双方没有约定彼此认可的、相同的沟通语言。就好像你说中文，他说西文；就好像RAS非对称密钥，你用一种密钥加密，而要求他用另一种密钥解密。这在人与人的沟通世界里，简直就是痛苦----双方的痛苦！那时候，有人笑侃，“这是加密了的需求，要用UML这把钥匙才能把它打开，才能翻译成自然语言文本。” 人类在语言上不断地进步，最终出现了非常好用、沟通自由、表达准备的“自然语言”。可是，在计算机世界里，自然语言却失去了它的价值。我们似乎需要反达尔文进化，把自然语言再符号化、结构化。另外，当我们对复杂现实世界（如：专业业务系统等）进行描述的时候，由于我们自然语言的过于灵活，使得我们沟通的双方出现了理解偏差，而且随着复杂性的增大，偏差越大。直到现在，关于复杂业务系统的沟通，在软件工程师和客户之间，还依然存在着理解的偏差。这是需求工程中的一个全球性疑难问题。
那么，既然如此，UML可以作为一个面向专业业务系统的描述语言，来表达实际业务吗？我想，UML之父Ivar Jacobson 、Booch 和 James Rumbaugh 已经帮助我们回答了这个问题。但是，接下来，你能强迫你的客户去懂得UML吗？有人说，在过去20年来，软件工程师是最辛苦的职业，因为他们不仅要懂计算机，还要懂甲方的业务，更重要的是，还要让甲方相信你懂他的业务。而甲方，也许什么不懂都没有什么大不了的。这种交易中的不对等，沟通中的不对等严重地束缚了软件产业的发展，返工、重开发等等几乎在每个软件企业里发生过；也因此造成了甲方许多投资失败。想想吧，所有的产业链中，没有那个产业象软件业一样，把它和它的客户如此紧密的联系在一起。所以，在一个共同的“生存链条里”，我们需要一起成长，一起进步。当需求的问题日日夜夜纠缠着我们彼此的大脑的时候，我们需要共同的努力，需求结构化我们的需求，需要在沟通上创造新的方式，那就是：共同使用UML来确认需求。当然，除过UML之外，还有IDEF0、Workflow等辅助技术。
因此，甲方的项目人，如果你还停留在初级的需求表达上，请进入UML的世界吧，请试用用例的利器吧。它帮助你分解需求，关联需求，结构化需求，和快速理解需求。
【编辑推荐】
