摘要：
说教性质的需求分析理论，各位看了也白看，所以咱们就来一个真实个案——“订餐系统”体验一下。“订餐系统”貌似简单，但陷阱重重，各种需求分析的经典场景将会一一重现，各位做好准备接受这个挑战没有？我将分8篇为大家分享，全部内容超过1万1千字，而且有n多图片和思考题，请准备好盒饭边吃边看吧……
大纲：
1.某IT公司员工的吃饭问题
2.需求分析的大道理
3.背景-需要-需求规格
4.没完没了的“新需求”
5.领导“突发奇想”
6.榨干人脑汁的需求分析
7.变被动为主动
8.最后的疯狂
4.没完没了的“新需求”
由于你的彻底而深入的需求分析工作，订餐系统进展非常顺利，很快就上线运行了！但问题也就来了，客户陆陆续续提出了以下问题：
1)要经过好几个页面才能进入订餐页面，不太方便，希望能在首页直接进入订餐页面。
2)一次只能定一天的餐，不太方便，希望一次能定多天的。
3)我有时选了一个菜，前台却说这个菜没有了！
4)能不能提供多家餐馆选择？
5)订餐标准才8元，现在物价都涨了，能不能提高一下标准？
6)能不能直接连到餐馆的网页上去看菜式？
7)能不能做口味分析和营养分析？
系统能用起来，问题肯定多多，没问题反而说明没有人用这个系统，所以有问题是好事，但问题多了又会让人很烦躁，改来改去没完没了啊，项目的成本也会持续上升。
你准备如何招架呢？在继续阅读之前，请你逐一分析上述问题并提出解决方案，要写下来奥！
下面我们来逐一分析上述问题。
1)要经过好几个页面才能进入订餐页面，不太方便，希望能在首页直接进入订餐页面。
2)一次只能定一天的餐，不太方便，希望一次能定多天的。
我们首先要思考，这两个要求背后的需要是什么呢？这两个问题都是在实际使用订餐系统中产生的，用户提出这样的要求无非是希望系统更加好用更加方便，订餐系统无非是要方便大家订餐、减少订餐时间，故这两个要求应该予以满足。
系统上线后，用户往往会提出很具体的修改要求，这些要求往往是易用性方面的问题，如：界面布局、操作方式、文字表达、排序条件等细节问题，这些问题不解决的话会降低用户体验，此类问题一般应尽量解决。
前期对项目的需要把握得比较好的话，软件基本上是能符合用户的需要的，哪怕用户提出了一些易用性方面的要求，一般也是很容易修改的。不过谁也不能保证对需要的理解没有偏差，有可能系统上线后才发现理解错了客户的真正需要，这时修改系统的话一般来说工作量会比较大，但原则上应该给予修改，双赢是项目的目标，客户关键需要没有满足，项目不能算成功。
3)我有时选了一个菜，前台却说这个菜没有了！
5)订餐标准才8元，现在物价都涨了，能不能提高一下标准？
会什么会有选了菜但没有这个菜的问题呢？是软件的bug吗？
原来餐厅的菜单会定期更换，前台会及时更新订餐系统的菜单，但问题是餐厅修改菜单并不是很准时，而且修改后又不一定能及时通知前台，导致有时会出现员工按照老菜单订餐，但实际上餐厅已经修改了菜单的情况。
第二个问题是午餐标准的问题，明显不是系统的问题，但用户还是提出来了，他们难道不知道不是系统的问题吗？为什么还要对我们提出来？是不是希望我们向公司领导反应问题？
软件有些问题，并不是软件本身的问题，而是管理的问题。要用好一套系统，必须配套相应的管理办法，很多管理的问题软件是不能解决的。第一个问题，要改善的话则需要加强对餐厅的管理，让他们及时送上更新后的菜单；而对于第二个问题，则需要公司检讨订餐标准是否合适了。
项目组遇到客户提出这类问题时，不要因为不是软件问题就事不关己，应主动分析问题并提供适当的解决方案，很多问题只需要在管理上稍微改善一下，问题就可以立马解决。
4)能不能提供多家餐馆选择？
为什么用户希望选择多家餐厅呢？有人喜欢吃辣菜，有人喜欢吃粤菜，有人想吃粥粉面，就算是同一个人也会今天喜欢这个明天喜欢那个，如果能有多家餐厅可供选择，则更能满足大家的口味了。大家能吃到自己喜欢的午餐，更有利于大家做好工作，从这点看似乎这个要求是满足需要的，我们应该予以满足。
要实现这点，软件自然要费点周折去修改，但问题远远没有这样简单，管理上会变得麻烦很多：前台需要从多家餐馆获取菜单，要管理多家餐馆；财务要对多家餐馆进行结帐；更麻烦的是，有些餐馆要订餐数量多才会送餐，如果哪天某餐馆点的餐不够多，还需要选择了这个餐馆的员工重新订餐。这样复杂的管理，软件应该如何来适应呢？
看来如果寄望通过修改软件来满足这个要求，就会陷入一个“无底洞”，似乎无论怎样做都难以满足要求。实际项目中，经常会遇到这类问题，这时一定要认真地分析：
- 深入思考修改要求背后的需要是什么。
- 如果要满足该要求，在软件和管理办法上需要做什么改变，代价有多大。
- 如果不满足这个要求，影响会很大吗？
中午饭是工作餐，主要目标是方便快捷，员工哪怕吃不到最想吃的，也可以选择吃第二、第三想吃的，中午餐的预算也不可能很大，没有必要将午餐搞得很复杂很丰富，故这个要求可以不满足。
如果我们再动动脑筋，还是有简单易行的办法来解决这个问题的：员工可选择在公司统一订餐，也可以选择自己解决，无论哪种方式都享受公司的午餐补贴，如果在公司统一订餐，则只能选择一家餐厅。这样员工如果图方便，又觉得统一订餐的那个餐厅合适，就可以选择使用订餐系统来订餐；如果觉得想吃点别的，甚至是自己带饭，那就自己解决呗，反正午餐补贴是照样享受的。
6)能不能直接连到餐馆的网页上去看菜式？
为什么有这样新奇的要求呢？订餐标准才8元，这样的餐厅会有网页吗？
有时候用户会突发奇想，提出一些新奇怪异的要求，这时候要思考他的动机是啥了。由于客观条件限制，或者技术上做不到的，要予以拒绝。
为什么会有人想去看餐馆的网页呢？有可能是某些员工想了解一下餐馆的信息，好方便他和家人平时去撮一顿，如果是这样的原因，那只需要告诉他一些餐厅的网址就可以了。
7)能不能做口味分析和营养分析？
口味分析的意思就是希望系统能根据平时你的订餐情况，自动推荐你下次点什么菜。营养分析则是根据你订餐偏好，分析你的餐饮是否合理。这两个功能实在是太高级了，如果真的要做，那么系统需要增加数据挖掘的功能，这可是高技术含量的噢！
那到底要不要满足这个要求？这个要求其实已经超出了本系统的需要了，可以认为是对之前需要的升华，目前就算不满足也不会影响客户当前的使用，但如果要实现的话会导致项目成本上涨，对于这样的情况，可建议客户考虑项目的“二期”。
系统上线了，客户给你的挑战就会陆续而来，上述几个问题是实际工作中常见的几类问题：
- 对于符合需要的易用性方面的要求，应尽量满足。
- 有些问题可通过改善管理办法来解决。
- 有些问题需要同时在软件和管理办法上做工作来改善。
- 客户一时冲动的要求，可另辟蹊径解决。
- 客观条件做不到的、技术上做不到的，应予以拒绝。
- 超出范围的要求，可引导客户做第二期。
请看下一篇……
作者：张传波
创新工场创业课堂讲师
华为某团队高级顾问
《火球——UML大战需求分析》作者