来源： 转载 发布者：张传波
摘要：
说教性质的需求分析理论，各位看了也白看，所以咱们就来一个真实个案——“订餐系统”体验一下。
“订餐系统”貌似简单，但陷阱重重，各种需求分析的经典场景将会一一重现，各位做好准备接受这个挑战没有？
1.1某IT公司员工的吃饭问题
咱们出来干活的，天天需要吃午饭，所谓“午饭吃不好，工作干不好”。某IT公司深知这个道理，为了让大家方便吃午饭，由公司统一订餐，并且费用全包。
这样的做法，大家当然开心了，不过行政部的同事就要辛苦一点，每天要“服侍”大家吃饭，我们看看怎样个做法：
- 文员每天都要向餐厅索取最新菜单，然后拿着菜单找每个人确认今天吃什么。
- 大家都确认后，文员以电话或者传真的方式，向餐厅订餐。
- 餐厅送来午饭，文员通知大家，然后大家来取餐。
员工A抱怨：我明明点了酸菜鱼，干嘛给我送来红烧鱼。
员工B抱怨：我刚才去开会了，没有点餐，怎么就这样把我的餐给漏了？
员工C抱怨：我对中午饭要求不高，每天吃麻辣牛肉就可以了，不需要天天来问我吃啥，打断我的工作。
......
大家都开始来责怪文员了。
文员受了一肚子的委屈，她解释如下：
有些人写的字不太清楚，有时会搞错；
公司这么多人，有人上厕所有人去开会，我哪能保证每次都不漏人。
我按员工C说法做了，没有再问他了，但有一天取餐的时候，他说上火，不吃麻辣牛肉，要我换！都定了，怎么换啊？保险起见，我以后天天都问他了。
呜呜......
公司领导觉得问题责任不在于文员，而是这样的订餐方式太落后了，导致诸多问题！好歹是一个IT公司嘛，订餐也需要信息化！于是领导萌生了要做一个订餐系统的想法。
于是咱们的好戏就开始了......
1.2 需求分析的大道理
你非常光荣地接受了这个任务，领导任命你为订餐系统的项目经理，你会如何展开需求分析工作呢？
可能你会这样想：那还不容易，这么简单的系统，直接编码就行了，还写什么需求！
伙计，不要冲动，看到这里请你先停止阅读，找张纸和笔，用你自以为合适的方式列出这个系统的需求。
请写完后才继续往下看噢！
不听话了？没写完就往下看？
咱们先说说需求分析的一些大道理：
首先我们需要明确项目的背景，我们要回答这些问题：也就是为什么会有这个项目？客户为什么想做这样的一个项目？如果没有这个项目会怎样？
了解背景的基础上，我们需要进一步了解以下内容：
1)本项目解决了客户的什么问题？
2)本项目涉及到什么人、什么单位？
3)本项目的目标是什么？
4)本项目的范围是怎样的？
5)本项目的成功标准是什么？
以上这些内容，我们称之为客户的“需要”。
接下来，就可以定详细的需求规格说明书了，一般我们会对功能性需求和非功能性需求都列出详细的要求，我们这里把这些要求定义为“需求规格”。
图1 背景、需要、需求规格
对于功能性需求，我们往往会描述成用例图。
图2 用例图
对于非功能性需求，往往会对系统稳定性、性能、兼容性等提出要求。
什么是背景？
背景这东西比较笼统，简单地说就是这个项目的来由，我们需要用说故事的方式讲清楚项目的背景。
什么是需要？
需要就是客户真正想要的东东，是高层次的需求，我们可以把需要解决的问题、关键涉众、项目的目标、范围、项目成功标准等全部统称为需要。
什么是需求规格？
需求规格是很细级别的但又没有细到详细设计程度的需求了，描述出系统与用户是如何交互的，系统要满足怎样的一些非功能要求。
需求分析过程，无非就是由背景到需要到需求规格的 过程，这个过程是螺旋前进的。需求分析中最难解决的问题往往就是搞不清需求之根源，把握不清背景和需要，往往就会被繁琐的需求规格所困住，被客户牵着鼻子 走。理论是完美的，现实是残酷的，我们现实的需求分析工作，往往会出现这些问题：
- 背景啊背景，我该如何写你呢？
我们公司的需求规格说明书中，第一章节就是“背 景”，但往往大部分项目写出来的背景写了等于没写。有些写了诸如此类的内容：某年某月某日与某某公司签订了某某合同，成立了改项目组，项目人员有谁谁谁， 客户联络人是谁谁谁。有些项目更懒，直接复制前期需求文档的背景，以致项目已经做到第三期了，第三期的背景仍然是抄第一期的。不知道如何分析背景，背景不 知道写啥，这是项目的普遍现象。
- 目标在哪里？
对于“项目的目标”，项目组普遍的问题有：
1.根本不知道“目标”这回事。
2.目标写出来了，但被扣上“大而虚”的帽子。
3.没有用目标来指导下一步工作，后面遇到具体问题时，没有用目标来思考。
4.目标写出来就不变了，没有持续去思考是否需要调整。
- 需求规格优先
本小结开始的时候，要求你先写下本系统的需求，再继续往下看。不知道你写的需求中是否有背景、需要这些内容呢？你写的需求是不是几乎全部是“需求规格”呢？
下面，我们将来挑战“订餐系统”的背景、需求和需求规格。
图3 某需求规格说明书目录