为什么要进行软件需求分析

一、自身需求不清晰

需求分析是对用户的业务活动进行分析，明确在用户的业务环境中软件系统应该“做什么”。有些用户在决定引进某一软件项目后，对需求只有朦胧的感觉，说不清楚具体的需求是什么；另外还有一些用户，虽然心里清楚自己单位要做的软件项目需求，但却不能准确描述出来。

二、业务部门不配合

对于软件建设单位，软件项目往往是由信息中心等信息化主管部门负责，业务部门需要配合进行业务需求调研、可行性研究等工作。但有的业务部门由于自身业务工作繁忙，不想承担相关责任，从而拒绝投入太多的时间和精力在软件项目需求调研工作中，往往形成业务部门与信息化主管部门工作不配合的局面，软件项目需求得不到充分了解。

三、沟通存在障碍

用户在与开发方沟通时，由于开发方不是用户领域的专家，不熟悉用户的业务活动和业务环境，双方在沟通上存在一定的隔阂，导致用户所表达的需求并不能被开发方完全理解。

四、需求变动频繁

对于一个大型而复杂的软件系统，很难在开始就精确完整地提出它的功能和性能要求。一开始只能提出一个大概、模糊的功能，只有经过长时间的反复认识才逐步明确；有时进入到设计、编程阶段甚至开发后期，还会有新的需求出现。

1、访谈

系统分析员或者设计人员针对该项目提出一些事先已经准备好的具体问题，鼓励被访问人员说出自己的想法。同时，也可以通过调查表的形式对相关问题进行一个初步的统计。或在某种程度上通过快速建立的原型演示系统的主要功能，然后让大家都参与进来去体验，针对体验的结果请大家做出自己的分析和理解，这种方法充分提高了大家在需求分析过程中积极主动的作用，这种方法我们通常称之为“情景分析技术”。

2、面向数据流的自顶向下求精

基本思想是--“自顶向下，逐步求精，抽象和细分”。主要是利用数据流图，先建立一个初步的系统功能模型，然后按照基本思想，自顶向下，逐步对顶层数据流图进行细分，在细分的过程中，根据数据流图判断是否分解正确或者哪些地方有问题，然后再进行修正完善。

3、 简易的应用规格说明技术

1）进行初步访谈，初步确定待解决的问题的范围和解决方案；2）开发者和用户分别写出“产品需求”；3）选定会议的时间和地点，选举协调人；4）邀请开发者和用户双方组织的代表出席会议；5）列出系统环境组成部分的对象、系统将产生的对象、系统为完成自己的功能将使用的对象，列出操作这些对象或与这些对象交互的服务，列出约束条件和性能标准；6）共同创建一张组合列表起草完整的软件需求规格说明书。

4.、快速原型分析技术

首先通过初步需求，快速建立一个系统原型；然后运行给用户看，用户根据原型提出自己的修改意见；最后程序开发者根据用户的建议，对原型进行修改和完善。如此反复的迭代进行，直到最终建立一个满足全面需求的软件系统为止。

5、合理使用需求跟踪矩阵

需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵，可以把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。最后，需求跟踪矩阵还为管理产品范围变更提供了框架。