摘要：

说教性质的需求分析理论，各位看了也白看，所以咱们来一个真实个案??“订餐系统”体验一下。“订餐系统”貌似简单，但陷阱重重，各种需求分析的经典场景将会一一重现，各位做好准备接受这个挑战没有？本文文字超过1万1千字，而且有n多图片和思考题，请准备好盒饭边吃边看吧……

大纲：

1.某IT公司员工的吃饭问题

2.需求分析的大道理

3.背景-需要-需求规格

4.没完没了的“新需求”

5.领导“突发奇想”

6.榨干人脑汁的需求分析

7.变被动为主动

视频课程：

如果觉得看文章麻烦，可看本文对应的视频课程：http://www.cnblogs.com/umlonline/archive/2011/07/20/2111430.html

正文：

1. 某IT公司员工的吃饭问题

咱们出来干活的，天天需要吃午饭，所谓“午饭吃不好，工作干不好”。某IT公司深知这个道理，为了让大家方便吃午饭，由公司统一订餐，并且费用全包。

这样的做法，大家当然开心了，不过行政部的同事要辛苦一点，每天要“服侍”大家吃饭，我们看看怎样个做法：

文员每天都要向餐厅索取新菜单，然后拿着菜单找每个人确认吃什么。

大家都确认后，文员以电话或者传真的方式，向餐厅订餐。

餐厅送来午饭，文员通知大家，然后大家来取餐。

这样的做法维持了一段时间，但是问题逐渐来了。

员工A抱怨：我明明点了酸菜鱼，干嘛给我送来红烧鱼。

员工B抱怨：我刚才去开会了，没有点餐，怎么这样把我的餐给漏了？

员工C抱怨：我对中午饭要求不高，每天吃麻辣牛肉可以了，不需要天天来问我吃啥，打断我的工作。

......

大家都开始来责怪文员了。

文员受了一肚子的委屈，她解释如下：

有些人写的字不太清楚，有时会搞错；

公司这么多人，有人上厕所有人去开会，我哪能保证每次都不漏人。

我按员工C说法做了，没有再问他了，但有取餐的时候，他说上火，不吃麻辣牛肉，要我换！都定了，怎么换啊？保险起见，我以后天天都问他了。

呜呜......

公司领导觉得问题责任不在于文员，而是这样的订餐方式太落后了，导致诸多问题！好歹是一个IT公司嘛，订餐也需要信息化！于是领导萌生了要做一个订餐系统的想法。

于是咱们的好戏开始了......

2. 需求分析的大道理

你非常光荣地接受了这个任务，领导任命你为订餐系统的项目经理，你会如何展开需求分析工作呢？

可能你会这样想：那还不容易，这么简单的系统，直接编码行了，还写什么需求！

伙计，不要冲动，看到这里请你先停止阅读，找张纸和笔，用你自以为合适的方式列出这个系统的需求。

请写完后才继续往下看噢！

不听话了？没写完往下看？

咱们先说说需求分析的一些大道理：

首先我们需要明确项目的背景，我们要回答这些问题：也是为什么会有这个项目？客户为什么想做这样的一个项目？如果没有这个项目会怎样？

了解背景的基础上，我们需要进一步了解以下内容：

1)本项目解决了客户的什么问题？

2)本项目涉及到什么人、什么单位？

3)本项目的目标是什么？

4)本项目的范围是怎样的？

5)本项目的成功标准是什么？

以上这些内容，我们称之为客户的“需要”。

接下来，可以定详细的需求规格说明书了，一般我们会对功能性需求和非功能性需求都列出详细的要求，我们这里把这些要求定义为“需求规格”。

图1 背景、需要、需求规格

对于功能性需求，我们往往会描述成用例图。

图2 用例图

对于非功能性需求，往往会对系统稳定性、性能、兼容性等提出要求。

什么是背景？

背景这东西比较笼统，简单地说是这个项目的来由，我们需要用说故事的方式讲清楚项目的背景。

什么是需要？

需要是客户真正想要的东东，是高层次的需求，我们可以把需要解决的问题、关键涉众、项目的目标、范围、项目成功标准等全部统称为需要。

什么是需求规格？

需求规格是很细级别的但又没有细到详细设计程度的需求了，描述出系统与用户是如何交互的，系统要满足怎样的一些非功能要求。

需求分析过程，无非是由背景到需要到需求规格的过程，这个过程是螺旋前进的。需求分析中难解决的问题往往是搞不清需求之根源，把握不清背景和需要，往往会被繁琐的需求规格所困住，被客户牵着鼻子走。理论是完美的，现实是残酷的，我们现实的需求分析工作，往往会出现这些问题：

背景啊背景，我该如何写你呢？