摘要：
说教性质的需求分析理论，各位看了也白看，所以咱们就来一个真实个案——“订餐系统”体验一下。“订餐系统”貌似简单，但陷阱重重，各种需求分析的经典场景将会一一重现，各位做好准备接受这个挑战没有？我将分8篇为大家分享，全部内容超过1万1千字，而且有n多图片和思考题，请准备好盒饭边吃边看吧……
大纲：
1.某IT公司员工的吃饭问题
2.需求分析的大道理
3.背景-需要-需求规格
4.没完没了的“新需求”
5.领导“突发奇想”
6.榨干人脑汁的需求分析
7.变被动为主动
8.最后的疯狂
2. 需求分析的大道理
你非常光荣地接受了这个任务，领导任命你为订餐系统的项目经理，你会如何展开需求分析工作呢？
可能你会这样想：那还不容易，这么简单的系统，直接编码就行了，还写什么需求！
伙计，不要冲动，看到这里请你先停止阅读，找张纸和笔，用你自以为合适的方式列出这个系统的需求。
请写完后才继续往下看噢！
不听话了？没写完就往下看？
咱们先说说需求分析的一些大道理：
首先我们需要明确项目的背景，我们要回答这些问题：也就是为什么会有这个项目？客户为什么想做这样的一个项目？如果没有这个项目会怎样？
了解背景的基础上，我们需要进一步了解以下内容：
1)本项目解决了客户的什么问题？
2)本项目涉及到什么人、什么单位？
3)本项目的目标是什么？
4)本项目的范围是怎样的？
5)本项目的成功标准是什么？
以上这些内容，我们称之为客户的“需要”。
接下来，就可以定详细的需求规格说明书了，一般我们会对功能性需求和非功能性需求都列出详细的要求，我们这里把这些要求定义为“需求规格”。
图1 背景、需要、需求规格
对于功能性需求，我们往往会描述成用例图。
图2 用例图
对于非功能性需求，往往会对系统稳定性、性能、兼容性等提出要求。
什么是背景？
背景这东西比较笼统，简单地说就是这个项目的来由，我们需要用说故事的方式讲清楚项目的背景。
什么是需要？
需要就是客户真正想要的东东，是高层次的需求，我们可以把需要解决的问题、关键涉众、项目的目标、范围、项目成功标准等全部统称为需要。
什么是需求规格？
需求规格是很细级别的但又没有细到详细设计程度的需求了，描述出系统与用户是如何交互的，系统要满足怎样的一些非功能要求。
需求分析过程，无非就是由背景到需要到需求规格的过程，这个过程是螺旋前进的。需求分析中最难解决的问题往往就是搞不清需求之根源，把握不清背景和需要，往往就会被繁琐的需求规格所困住，被客户牵着鼻子走。理论是完美的，现实是残酷的，我们现实的需求分析工作，往往会出现这些问题：
背景啊背景，我该如何写你呢？
我们公司的需求规格说明书中，第一章节就是“背景”，但往往大部分项目写出来的背景写了等于没写。有些写了诸如此类的内容：某年某月某日与某某公司签订了某某合同，成立了改项目组，项目人员有谁谁谁，客户联络人是谁谁谁。有些项目更懒，直接复制前期需求文档的背景，以致项目已经做到第三期了，第三期的背景仍然是抄第一期的。不知道如何分析背景，背景不知道写啥，这是项目的普遍现象。
目标在哪里？
对于“项目的目标”，项目组普遍的问题有：
1.根本不知道“目标”这回事。
2.目标写出来了，但被扣上“大而虚”的帽子。
3.没有用目标来指导下一步工作，后面遇到具体问题时，没有用目标来思考。
4.目标写出来就不变了，没有持续去思考是否需要调整。
需求规格优先
很多需求分析人员喜欢将系统要做的事情，以用例或者功能点的方式记录下来，但往往没有记录为什么需要这样一个用例或者是功能点，没有去思考这个用例或者功能点背后隐藏的客户需要是什么。更甚者进入具体的界面设计，在需求文档中写清楚界面上放什么按钮什么菜单等，一开始就将需求“僵化”，这样会让后面的工作陷入“万劫不复”之地。
本小结开始的时候，要求你先写下本系统的需求，再继续往下看。不知道你写的需求中是否有背景、需要这些内容呢？你写的需求是不是几乎全部是“需求规格”呢？
下面，我们将来挑战“订餐系统”的背景、需求和需求规格。
图3 某需求规格说明书目录
请看下一篇……
作者：张传波
创新工场创业课堂讲师
华为某团队高级顾问
《火球——UML大战需求分析》作者