一、什么是需求分析呢？

　　软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化，分析各种可能的解法，并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。

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

下面举个栗子：

假如你是个软件工程师，夏天到了，有位客户跟你说要给他们的家禽养殖场开发一个温感控制系统，这个时候要需要与客户沟通，来确定客户到底想要一个什么样子的温感控制系统。我们应该注意三点：

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

客户说，我的温感系统系统可以感知当前天气温度，当温度过高时，采取洒水模式给环境降温，当天气太潮湿，可以开启除湿模式....客户滔滔不绝的讲了一大堆，你也都非常忠实的按照自己的理解再一一的向客户描述一遍，以便于确认客户的需求是否正确。

2 .  帮助客户挖掘需求。

等客户把自己的需求说完了，你发现客户没有跟你说该养殖场的规模是多大的，是在露天的环境下还是在室内的，于是，你向客户提议说：“你看，咱们这个养殖场的规模是多大的，是在室内呢还是在室外，我们应该怎么样设计监控范围呢？”，客户连连的拍着脑门说，我差点给忘记了，我们这个养殖场是室内的，有两层，一层有500平左右。

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

客户临走时又说，对了，一楼二楼的情况不太一样，二楼比较热，家禽很多会中暑，能不能二楼的跟一楼的监控是分开的。你这么一分析，客户这要求，按照目前的技术可没法做啊，于是，你向客户提议，一层使用一个温感控制器，单独监控。

二、软件需求分析难点又在哪里呢？

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

1 . 客户说不清楚需求

有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如谈恋爱的时候，女生总希望男朋友能有读心术猜出自己的心事。每次生气总会扯出很多事情，然后始终不说清楚为什么生气，想要的是什么。

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

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

2 . 需求自身经常变动  

　都说女人是善变的，但是其实生活中善变的不止止是女人，你的上司，你的客户变脸比变天还快 ~

需求分析时要注意的问题：

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

（2）在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊，就要跟客户确认清楚。

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

　　俗话说，一千个读者有一千个哈姆雷特，每个人的思维模式和理解方法都是不一样的，你不是客户肚子里面的蛔虫，客户也不是你的大脑反射弧，沟通是解决这些问题的最好方式。

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

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

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

三、需求分析的分类

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

1 . 功能需求：

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

2 . 非功能需求：

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

3 . 领域需求：

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

四、需求分析的不同层次

软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。

1．业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们

在项目视图与范围文档中予以说明。

2．用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（use

case）文档或方案脚本说明中予以说明。

3．功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的

任务，从而满足了业务需求。

五、如何进行需求分析 

1、需求分析的渠道和过程

2、需求分析的过程

软件需求分析的过程主要有四个阶段：

1、确定软件需求目标

2、进行分析并整合

3、规格的相关说明规定

4、最终评审。

确定软件需求目标在涵义上是指系统分析师和程序开发工程师在进行工作中，找出目标软件工程所需的要求，从而讲述出能够达到要求所需要的条件。一般来说，这些要求主要体现在功能、性能、环境、可靠性、安全性以及用户界面、资源使用、软件成本消耗与开发进度等。

（1）功能是指将软件的功能开发；

（2）性能则在于软件技术性能标准；

（3）环境是指如硬件和软件方面在软件系统运行时的要求，另外还包括对使用此软件的工作人员的技术要求；

（4）可靠性是通过软件在开发过程中对实际环境的要求，并满足在进行需求分析时显露出所有存在的问题，估计运行后会产生的后果，提出更高的可靠性；

（5）安全性是指安全保密，在进行开发时特别针对安全性能严格要求，保证在日后的使用过程中能够拥有强大的安全性能；

（6）用户界面要根据客户的要求进行需求分析；

（7）资源使用是要保证用户能够接受在软件的使用中的资源需求；

（8）大致提出软件开发所需要的时间和各个阶段的费用，合理控制成本消耗和进度。另外，分析系统的功能，检测在开发之后的性能，有利于及时对系统做出改正。在这些问题得出相应的分析结果之后，要将结果与软件开发工程师进行核对，并且得到认可。

六、需求分析的方法

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 . 形式化方法

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

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

七、需求工程

以上例子可能描述不够严谨，有些描述是网上摘录的，如有讲述不对的，欢迎指出，感谢 ！！！