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