某IT公司规模不大，员工100来人。公司有一个简单的定餐系统，员工每天可以在公司内部网站上提交当天午餐定餐，前台汇总各人定餐后，将定餐汇总传真给餐厅，餐厅根据传真送餐。
可是有这样的问题：部分员工因为上午请假或者外出工作，无法再网站上提交订餐，以至于中午回到公司时没有饭吃。
于是老板想出了这样的办法：做一个手机短信定餐系统，不在公司的员工可通过手机短信定餐。
于是成立了手机短信定餐项目小组，购买了手机短信收发的硬件，解决了选餐单、定餐、取消定餐等技术问题。但这个系统一会灵一会不灵，问题是出在软件、硬件，还是中国移动都难以搞清楚！做项目做麻烦的事情之一就是遇到“幽灵问题”，时而出现时而正常，项目小组挥汗如雨地试图解决这些问题，可一直没有办法搞定。
老板大发雷霆了，怎么这样小的事情，竟搞成这个样子？
后来有人提出来：不在公司的员工，打电话回公司告诉前台吃什么，不就搞定了？
于是全世界恍然大悟，天啊！
需求分析核心的问题就是客户到底想要什么的问题！
客户往往只会有朦胧的大概的想法，他们提出来的需求，只是表面的，不全面的，甚至是互相矛盾的，我们需要透视它的本质。
我们做需求分析工作，往往会将需求分析和软件设计混在一起。需求分析核心目的就是解决软件有没有用的问题，而软件设计是解决软件用多大的成本做出来的问题。
需求分析首要任务是保证软件的价值，我们必须保证做出来的软件是符合客户的利益的。如果我们不能看清楚客户的真正需要而仓促上马，则很可能付出巨大成本仍然不能满足客户的利益。
手机短信定餐系统要解决的问题其实就是：让不在公司上班的员工也能方便地定餐，手机短信定餐系统本身并不是需求，只是一种解决方案而已。当然因为这个要求是老板提出来的，所以项目组可能就没有进一步思考这个系统的必要性了。我们的客户提出具体要求的时候，我们往往不能思考这些要求背后的需要是什么，而直接将这些客户要求当成客户需求来处理。
给客户带来切实的价值才是我们真正的任务，而不是盲目听从客户的要求而不加分析。