需求面面观
互联网上很流行这张图：
每次看到这张图，我都觉得十分形象，也十分贴切。
对于软件需求，不同角色会有不同的诠释和理解，上图的第一行非常经典地展示了各类角色的特点：
客户：他想要的东西并不能准确全面地表达出来。
项目经理：项目经理对需求的理解，往往是在客户表达出来的基础上，再打个折扣。
分析员：分析员往往喜欢追求技术上的标新立异，而不能需求驱动地做设计。
程序员：漂亮的设计到了程序员手上，往往变成了面条式代码。
商业顾问：Sales的特点就是“哄你无商量”！
上图第二行，展示了项目的普遍问题：
项目文档：无
安装程序：“简洁”
客户投资：巨大
技术支持：能按时交货就万事大吉了，做完最好拍屁股走人，管你什么技术支持！
解密：项目失败的大部分原因就是没有把握住真正的需求！
或许你会觉得此图有点夸张，下面我们看看一些具体例子吧。
手机订餐系统的故事
话说某公司中午统一为员工订餐，订餐办法如下：
1)每个人在网站上提交今天想吃什么。
2)前台汇总后传真给餐厅。
3)餐厅送餐。
但有这样的问题：
1)有人请假或者外出工作，无法在网站上提交。
2)导致一些辛勤工作的员工没有饭吃。
老板就产生了这样的想法：
要做一个手机短讯订餐系统，让外出工作的员工可以通过手机订餐。
于是成立了手机订餐项目组，购买了手机短讯收发的硬件，解决了选餐单、定餐、取消订餐等技术问题。
但，这个系统还时灵时不灵，问题是出在软件、硬件、还是中国移动都难以搞清楚。
老板大法雷霆，这样的小事情，怎么搞成这样？！
有人提出来：不在公司的员工，打电话回公司告诉前台吃什么，不就搞定了？
于是全世界都恍然大悟，天啊！！！
对于上面这个故事，不知道同学们有什么感想呢？
你引导客户还是客户在引导你？
我做的第一个大型分布式系统，是某房地产公司的成本管理系统。我的自我感觉还是相当不错的，不过其中一个客户认为他在本项目中发挥了很大的作用，基本上是他指导我们将软件做出来的。当时我觉得不是很爽，也没有仔细思考这是怎么回事。
我们公司为中国移动做的一个项目，整体来说客户还是满意的，不过客户提出了这样的一个建议：希望我们能为他们提供更多的创造性意见，将系统做得更好。而我们觉得必须非常熟悉客户的业务，这样才有可能提出好的建议，而要熟悉客户的业务，不到客户那工作一年半载，恐怕是熟悉不了。
我最开始做项目的基本思想是：客户“告诉”我们做什么，我们适当加以引导。这样的思想应该相当普遍，我们要做不同类型的项目，不太可能每个项目都能深入去研究业务，很多情况下只能“点到为止”。这样我们很容易会犯下“手机订餐系统”的错误，而最理想情况下也只能让客户基本满意，而没能超出客户的期望，给客户带来更大更高的价值。不能给客户带来更高的价值，项目也更难获得更高的利润，公司的竞争力也难以进一步提高。
需求分析说到底要解决的最根本问题就是：客户到底要什么！
客户通常只会有朦胧的大概的想法，他们提出来的需求，只是表面的，不全面的，甚至是互相矛盾的，我们需要透视它的本质。
如果我们能说出客户内心深处真正想要的，而客户又不能表达出来的东西，我们才能真正做到“为客户带来价值” ！
找到需求根源，解决的办法可能很简单，而不需要来个“手机订餐系统”来解决，劳师动众，又不能解决问题。
解决了客户的最基本需要基础上，我们还需要为客户提供更强的服务，发掘客户更高价值的需求！
UML能帮助我们实现以上目标。
UML与需求分析
UML能帮助我们分析问题，发掘问题之根源：