什么是需求分析？
简单来说，对用户的意图不断揭示和验叛的过程，要对经过系统可行性分析，所确定的系统目标做更为详细的
描述。
不明白？来，看个例子——
假如你是个建筑工程师，有个客户找你建一个鸡窝，这个时候就需要与客户沟通，来确定客户到底想要一个什么
样子的鸡窝。这时应该注意三点：
1 . 准确的理解和描述客户需要的功能
客户说，我的鸡窝要三层的，带电梯，饮水池，厕所，而且饮水池要自动判断水位供水，电梯要可以同时乘坐10
只鸡....客户吧啦吧啦地讲了一大堆，你也都非常忠实的按照自己的理解再一一的向客户描述一遍，以便于确认客
户的需求是否正确。
2 . 帮助客户挖掘需求
等客户把自己的需求说完了，你发现客户没有说鸡的卧室，于是，你向客户提议说：“你看，这鸡的卧室要什么样
子的？”，于是客户拍着脑门说：“我差点给忘记了，鸡们啊喜欢晚上在一起聊天，所以呢，需要一个长而大的卧室，但一定要舒适。”
3 . 分析客户需求的可行性
客户临走时又说：“最近呢，黄鼠狼很多，我这个鸡窝啊，一楼就不用盖了，直接盖二楼和三楼吧！以免晚上遭遇黄鼠狼的攻击。”你一分析，发现客户这要求，按照目前的技术可没法建啊，于是，你向客户提议，一楼可以采用坚固架子来支撑二三楼的建筑。

来个人再更！！

哈哈，喜欢楼主举的栗子，期待下部分

来了个人，那就继续来说说吧！
需求分析困难在哪儿？
有几种原因使需求分析变得困难：（1）客户说不清楚需求；（2）需求自身经常变动；（3）分析人员或客户理
解有误。
1、 客户说不清楚需求
有些客户对需求只有朦胧的感觉，不清楚具体的需求。例如全国各地的很多官方机构在搞网络建设，这些单位的
领导和职员大多不清楚网络建设有什么用，反而要网络建设人员替他们设想需求。
有些客户心里非常清楚想要什么，但却说不明白。就举日常生活的事例吧，比如说买鞋子，我们非常了解自已的脚，但也只能拿鞋子去试，因为你说不清楚你看中的这个鞋子是否合适，是否符合你的形象。
如果客户本身就懂软件开发，能把需求说得清清楚楚，那么这样的需求分析将会非常轻松、愉快。如果客户全不
懂软件，但信任软件开发方，这事儿也好办。分析人员可以引导客户，先阐述常规的需求，再由客户否定不需要的，最终确定客户真正的需求。最怕的就是“不懂装懂”或者“半懂充内行”的客户，他们会提出不切实际的需求。
如果这些客户甚至觉得自己是上帝的爸爸，那么沟通和协商都会很困难。

2、需求自身经常变动
所谓，喜新厌旧乃人之常情，世界也因此变得多姿多彩。但，软件的需求会变化吗？答：据历史记载，没有一个软件的需求改动少于三次。
让我们先接受“需求会变动”这个事实吧，免得在需求变动时惊慌失措。明白“需求会变动”这个道理后，在进行需求分析时就要留点儿神：
（1）尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上。
（2）在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊，日后扯皮的事情就多。

3 、分析人员和顾客理解有误
假如有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是车。它们喝汽油，有四个轮子一样的脚，嗓门极大，在夜里双眼能射出强光。……有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。”
同样的一句话，不同的人有不同的理解。同样，客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致开发人员白干活，吃力不讨好。所以分析人员写好需求说明书后，要请客户方的各个代表验证。如果问题很复杂，双方都不太明白，就有必要请开发人员快速构造软件的原型，双方再次论证需求说明书是否正确。
由于客户大多不懂软件，他们可能觉得软件是万能的，会提出一些无法实现的需求。有时客户还会把软件系统分析人员的建议或答复给想歪了。
有个小笑话是这样的：有一个软件人员滔滔不绝地向客户讲解在“信息高速公路上做广告”的种种好处，客户听得津津有味。最后，心动的客户对软件人员说：“好得很，就让我们马上行动起来吧。请您决定广告牌的尺寸和放在哪条高速公路上，我立即派人去做。

顶一下！
在另外一个帖子里，老是被删，在这里试试发！！

需求分析的分类
需求分析一般可分为【功能需求】、【非功能需求】和【领域需求】
1 . 功能需求：
功能需求主要说明了系统实际应做到什么。这是用户最直观也是最主要的需求，如系统的输入输出、系统能完成的功能以及其它相关处理等；
2 . 非功能需求：
非功能需求又称“约束”，它主要从各个角度对系统起约束和限制作用。如响应时间、存储效率、报表的规格和界面的样式等
3 . 领域需求：
领域需求的来源不是用户，而是系统应用的领域，其主要反映了该领域的基本问题。例如勤工俭学管理系统，其领域需求就涉及到诸如应聘合同书、酬金发放及劳工考核等相关内容，如果这些需求得不到满足，系统就无法正常运行。值得一提的是，领域需求可能是功能需求，也可能是非功能需求。

需求分析的过程
（1）可行性研究
它指明现有的软件、硬件技术能否实现用户对系统的要求，从业务角度来决定系统开发是否可行以及在预算范围内能否开发出来。可行性研究的结果是清楚的回答：该系统是否值得开发
（2）需求导出和分析
这是一个通过对现有系统分析、与潜在客户讨论、进行任务分析等导出系统需求的过程，也可能需要开发一个或多个不同的系统原型，以帮助分析员了解所要描述的系统。
（3）需求描述
需求描述就是把在分析活动中收集的信息通过分析整理之后以文档的形式确定下来。该文档中有两类需求：用户需求是从客户和最终用户角度对系统需求的抽象描述；系统需求是对系统要提供的功能的详尽描述。
（4）需求有效性验证
主要是通过评审、验证等一系列活动来找出需求文档中的错漏并加以改正。
（5）需求管理
需求管理需求管理是一种系统化方法，可用于获取、组织和记录系统需求并使用户和开发方在系统变更需求上始终保持一致

需求分析的方法
1 . 功能分析方法
功能分析法功能分解法以系统提供的功能为中心来组织系统。首先定义各种功能, 然后把功能分解为子功能, 同时定义功能之间的接口。数据结构是根据功能/子功能的需要设计的。 其基本策略是以分析员的经验为依据, 确定新系统所期望的处理步骤或子步骤, 然后, 将问题空间映射到功能和子功能上。
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 . 形式化方法
形式化方法, 广义上讲, 是应用数学的手段来设计、 模拟和分析, 得到像数学公式那样精确的表示。从狭义上讲, 就是使用一种形式语言进行语言公式的形式推理, 用于检查语法的良构性并证明某些属性。
在需求分析阶段, 利用形式化方法得到需求规格说明书, 可以规范软件开发过程, 为获得更好的系统性能提供重要保证。