什么是需求分析？

  通俗的讲，对用户的意图不断揭示和验叛的过程，要对经过系统可行性分析所确定的系统目标做更为详细的描述。

 假如你是个建筑工程师，有个客户找你建一个鸡窝，这个时候要需要与客户沟通，来确定客户到底想要一个什么样子的鸡窝。我们应该注意三点：

 1 .  准确的理解和描述客户需要的功能。

    客户说，我的鸡窝要三层的，带电梯，饮水池，厕所，饮水池要自动判断水位供水，电梯要可以同时乘坐10只鸡....客户滔滔不绝的讲了一大堆，你也都非常忠实的按照自己的理解再一一的向客户描述一遍，以便于确认客户的需求是否正确。

 2 .  帮助客户挖掘需求。

   等客户把自己的需求说完了，你发现客户没有说鸡的卧室，于是，你向客户提议说：“你看，这鸡的卧室要什么样子的？”，客户连连的拍着脑门说，我差点给忘记了，鸡们啊喜欢晚上在一起聊天，所以呢，需要一个长而大的卧室，但一定要舒适。

 3 . 分析客户需求的可行性

  客户临走时又说，最近了，黄鼠狼很多，我这个鸡窝啊，一楼就不用盖了，直接盖二楼和三楼吧！以免晚上遭遇黄鼠狼的攻击。你这么一分析，客户这要求，按照目前的技术可没法建啊，于是，你向客户提议，一楼采用坚固架子来支撑二三楼的建筑。

需求分析困难在哪儿？

  有几种原因使需求分析变得困难：（1）客户说不清楚需求；（2）需求自身经常变动；（3）分析人员或客户理解有误。

1 . 客户说不清楚需求

    有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如全国各地的很多政府机构在搞网络建设，这些单位的领导和办公人员大多不清楚计算机网络有什么用，反而要软件系统分析人员替他们设想需求。这类工程的需求是如此的主观，以致产生很多贪污腐败现象。

 有些客户心里非常清楚想要什么，但却说不明白。你可能很不以为然。就举日常生活的事例吧，比如说买鞋子。我们非常了解自已的脚，但没法说清楚脚的大小和形状。只能拿鞋子去试，试穿时感觉到舒服才会买鞋（居然也有神通广大的售货员，看一眼客户的手，就知道应该穿什么样的鞋）。

 如果客户本身就懂软件开发，能把需求说得清清楚楚，这样的需求分析将会非常轻松、愉快。如果客户全不懂软件，但信任软件开发方，这事也好办。分析人员可以引导客户，先阐述常规的需求，再由客户否定不需要的，最终确定客户真正的需求。最怕的就是“不懂装懂”或者“半懂充内行”的客户，他们会提出不切实际的需求。如果这些客户甚至觉得自己是上帝的爸爸，那么沟通和协商都会很困难。

2 . 需求自身经常变动  

   唐僧曾说：“妖要是有了仁慈之心，就不再是妖，是人妖。”（《大话西游之大圣娶亲》）

 连妖都会变心，别说人了。所以喜新厌旧乃人之常情，世界也因此变得多姿多彩。

 软件的需求会变化吗？

 答：据历史记载，没有一个软件的需求改动少于三次。唯一只改动需求两次的客户是个死人。这个可怜的家伙还是在运送第三次需求的路上被车子撞死的。[Cline 1995]

 让我们先接受“需求会变动”这个事实吧，免得在需求变动时惊慌失措。明白“需求会变动”这个道理后，在进行需求分析时就要留点神：

     （1）尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上，否则将会吃尽苦头。

     （2）在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊，日后扯皮的事情就多。要防止象韩复渠那样，在别人请他喝酒吃饭时他什么都点头（人家就更加献殷勤），吃完了他就宣布刚才答应的事都不算数，便扬长而去。

3 .  分析人员和顾客理解有误

   有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是车。它们喝汽油，靠四个轮子滚动前进。嗓门极大，在夜里双眼能射出强光。……有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。”

 软件系统分析人员不可能都是全才。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致开发人员白干活，吃力不讨好。我读中学时候最怕写作文逃题，如果逃题了，不管作文写得多长，总是零分。所以分析人员写好需求说明书后，要请客户方的各个代表验证。如果问题很复杂，双方都不太明白，就有必要请开发人员快速构造软件的原型，双方再次论证需求说明书是否正确。

 由于客户大多不懂软件，他们可能觉得软件是万能的，会提出一些无法实现的需求。有时客户还会把软件系统分析人员的建议或答复给想歪了。

 有一个软件人员滔滔不绝地向客户讲解在“信息高速公路上做广告”的种种好处，客户听得津津有味。最后，心动的客户对软件人员说：“好得很，就让我们马上行动起来吧。请您决定广告牌的尺寸和放在哪条高速公路上，我立即派人去做。”

需求分析的分类

  需求分析一般可分为功能需求、非功能需求和领域需求

1 . 功能需求：

        功能需求主要说明了系统实际应做到什么。这是用户最直观也是最主要的需求，如系统的输入输出、系统能完成的功能以及其它相关处理等；

2 . 非功能需求：

        非功能需求又称“约束”，它主要从各个角度对系统起约束和限制作用。如响应时间、存储效率、报表的规格和界面的样式等

3 . 领域需求：

       领域需求的来源不是用户，而是系统应用的领域，其主要反映了该领域的基本问题。例如勤工俭学管理系统，其领域需求就涉及到诸如应聘合同书、酬金发放及劳工考核等相关内容，如果这些需求得不到满足，系统就无法正常运行。值得一提的是，领域需求可能是功能需求，也可能是非功能需求。

如何进行需求分析

进行需求分析不象情人之间的浪漫做法——“让我摸摸你的头发，感觉它是什么颜色。”我们需要了解需求分析的渠道和过程。

需求分析的过程

（1）可行性研究

    它指明现有的软件、硬件技术能否实现用户对系统的要求，从业务角度来决定系统开发是否可行以及在预算范围内能否开发出来。可行性研究的结果是清楚的回答：该系统是否值得开发

（2）需求导出和分析

     这是一个通过对现有系统分析、与潜在客户讨论、进行任务分析等导出系统需求的过程，也可能需要开发一个或多个不同的系统原型，以帮助分析员了解所要描述的系统。

（3）需求描述

       需求描述就是把在分析活动中收集的信息通过分析整理之后以文档的形式确定下来。该文档中有两类需求：用户需求是从客户和最终用户角度对系统需求的抽象描述；系统需求是对系统要提供的功能的详尽描述。

（4）需求有效性验证

      主要是通过评审、验证等一系列活动来找出需求文档中的错漏并加以改正。

（5）需求管理

    需求管理需求管理是一种系统化方法，可用于获取、组织和记录系统需求并使用户和开发方在系统变更需求上始终保持一致

需求分析的方法

1 .  功能分析方法

     那怕是天下最无能的市长或书记，都知道在作报告时要先从宏观上讲一、二、三、四、五，再从细节上讲 A、B、C、D、E；需求分析不象侦探推理那样从蛛丝马迹着手。应该先了解宏观的问题，再了解细节的问题。

     功能分析法功能分解法以系统提供的功能为中心来组织系统。首先定义各种功能, 然后把功能分解为子功能, 同时定义功能之间的接口。数据结构是根据功能/子功能的需要设计的。 其基本策略是以分析员的经验为依据, 确定新系统所期望的处理步骤或子步骤, 然后, 将问题空间映射到功能和子功能上。

2 . 数据流方法

    周末，小明一觉醒来突然想吃红烧肉，那想得口水直流，于起床，穿好衣服，打开钱包一看空的，好吧，先去银行取钱，然后去菜那买了一肉、各种配料，然后回家，开火，各种材料往锅里一放，开始小火慢炖，半个小时后，小明终于吃上了美味可口的红烧肉。这是一个典型的流程，如果把它看成一个系统功能的话，那么小明吃到红烧肉是这个功能的目的，那么中间要经历许多环节，起床穿衣---取钱---习材料----制作完成。而且各个功能（步骤）之间是相互联系的，小明总不能不穿衣服直接去取钱吧。

    数据流法也叫结构化分析, 其基本策略是研究问题域中数据如何流动以及在各个环节上进行何种处理, 从而发现数据流和加工。 问题域被映射为由数据流、加工以及文件、端点等成份构成的数据流图(DFD) , 并用数据字典对数据流和加工进行详细说明。这种方法的关键是动态跟踪数据流动。

3 . 信息建模方法

   一个贵妇去报案，我丢了一个辆车，小明是警察，然后问贵妇，你丢的什么样的车子？贵妇噼里啪啦的给小明描述车子样子：我的车子有四个轮子，前面两个小，后面两个大，车身是流线型的，后面带尾翼，里面只一排坐位的那种，车坐上都用的真皮做套子，后面…..你听着听头大了，然后对贵妇说：等等，我给你画下来。于是，贵妇边说，你边画，然后贵妇指出画的不对的地方由你来修改。当然了这只是实体的样子。我们还需要知道汽车各个部件的功能以及各部件之间的关系。

   信息建模法的核心概念是实体和关系, 主要工具是语义数据模型(实体关系图) , 其基本策略是找出现实世界的对象, 然后用属性来描述对象, 增添对象与对象之间的关系, 定义父类与子类, 用父类型/子类型提炼属性的共性, 用关联对象关系作细化的描述, 最后进行规范化处理。 其实质是将问题空间直接映射成模型中的对象。

4 .   面向对象方法

    我想你如果学习过面向对象编程的话，会很容易理解。

    面向对象分析 OOA(Object- Oriented Analysis) 的基本策略是通过信息隐藏将比较容易变化的元素隐藏起来, 分析员基于比较稳定的元素建立其思想和规格说明的总体结构。

    面向对象分析的主要特性是加强了对问题域( Problem Domain) 和系统责任( System Responsibili-ties)的理解; 改进与分析有关的各类人员之间的交流; 对需求的变化具有较强的适应性; 支持软件复用

5 . 面向本体方法

   面向本体的需求分析 OORA (Ontology- Oriented Require-ments Analysis) , 是 OOA方法的有效补充和提升。 面向本体方法强调相关领域的本质概念以及这些概念之间的关联。其实质是在面向对象方法中引入对象关联, 并给出各种关联的语义语用。

    OORA方法由 4 个阶段来完成。第一阶段: 用一种自然语言BIDL( Bisiness Information Description Language) 描述事务; 第二阶段: 确认隐含在 BIDL文本中的本体和对象; 第三阶段: 将这些本体和对象转换成另一种语言 Ononet (Ontology and Object- Ori-ented Network) , 得到用 Ononet 书写的需求预定义; 第四阶段: 在采用 Ononet 作为知识表示形式的领域本体知识库中搜索相关的知识, 并和前面的需求预定义合并, 得到软件完整的需求定义。

6 . 形式化方法

   形式化方法, 广义上讲, 是应用数学的手段来设计、 模拟和分析, 得到像数学公式那样精确的表示。从狭义上讲, 就是使用一种形式语言进行语言公式的形式推理, 用于检查语法的良构

性并证明某些属性。在需求分析阶段, 利用形式化方法得到需求规格说明书, 可以规范软件开发过程, 为获得更好的系统性能提供重要保证。

可能你对上面的方法看不懂，起码后三种我是看不懂的，怪我知识太少的缘故。

我们来看下面了解需求的方式：

（1）直接与客户交谈。如果分析人员生有足球评论员的那张“大嘴”，就非常容易侃出需求。

（2）有些需求客户讲不清楚，分析人员又猜不透，这时就要请教行家。有些高手真的很厉害，你还没有开始问，他就能讲出前因后果。让你感到“听君一席言，胜读十年书。”

（3）有很多需求可能客户与分析人员想都没有想过，或者想得太幼稚。要经常分析优秀的和蹩脚的同类软件，看到了优点就尽量吸取，看到了缺点就引以为戒。前人既然付了学费，后人就不要拒绝坐享其成。