需求管理：需求调研计划

一、什么是需求调研？

需求调研对于一个应用软件开发来说，是一个系统开发的开始阶段，它的输出“软件需求分析报告”是设计阶段的输入，需求调研的质量对于一个应用软件来说，是一个极其重要的阶段，它的质量在一定程度上来说决定了一个软件的交付结果。怎样从客户中听取用户需求、分析用户需求就成为调研人员最重要的任务。

需求调研是为需求说明书撰写做前期工作，需求说明书是从需求调研表中得到或抽取而出；是了解实际工作中真正需要什么样的程序的过程，再把这些需求细节整理由设计部开发，给用户使用。

需求调研，特别是合同额已经确定的项目的需求调研，就像外交一样，实际上是一种策略艺术，它是在和客户相互尊重、平等互利的基础上，不卑不亢的去交流沟通，守住我方底线，尽可能的争取有利于我方条件，在完成任务的同时，还能赢得客户的理解和尊重。

需求调研，简而言之就是和客户进行谈话沟通，把客户的想法和要求记录下来，最后整理成为《用户需求说明》，以便进行下一步的需求分析、系统设计等，正因为后面的需求分析、系统设计，乃至开发等等都以需求调研的内容为依据，那么需求调研质量的好坏直接就决定了软件系统的好坏，也即项目的成败。

通常我们一提到某个系统，感觉上应该始终就是一个东西，但其实在不同人眼里，可能是不一样的，比如按照一般软件开发过程来说，就有如下几种：

1客户实际需要的软件

2客户头脑中想要的软件

3调研人员调研后的软件

4设计人员设计出来的软件

5开发人员开发完成的软件

（这里特别注意客户实际要的软件和客户头脑中想要的软件可能并不是一个东西）

如果上述中间各个过程都有理解偏差，那么很可能就出现最终开发完成的软件和客户实际需要的软件差异较大，一个失败的或者做的不好的项目，往往原因就在这里。

而且还有一点，上述过程中，越往后，修改这些偏差要付出的代价就越大，直到你无法承受。那么，保证你调研出来的需求和客户实际的需求以及客户头脑中想要的三者保持一致，并且这个需求在开发上是能够实现并且容易实现，就是每一个需求调研人员努力要做到的。

二、项目类需求调研的特点

1《需求规格说明书》的出具比较仓促，质量低

(1)不切实际的工期（需求调研成了走过场）

(2)用户方怕担责任的心态（模棱两可的说法）

(3)认知程度的限制（项目达到的预期是什么？调研人员错误的理解，怕引出额外诉求）

(4)迫于工期压力，各方妥协签字了（没有争取广泛的支持）

2大部分需求是《需求规格说明书》出来以后出来的

(1)程序被迫使用，与切身利益相关，被迫重视（流程、易用性、工作量全来了）

(2)用户认知程度逐渐被引导，使用积极性提高，提出更多的功能诉求

注意把握这些问题要点，在实际 *** 作中注意规避相关错误要点，正确很好的引导客户，把需求调研向良性的方向发展。

三、需求调研的前期准备

1确定调研工具

选取需求调研过程中的一些辅助工具，选取要求是自己（本组）熟悉的工具， 工具最好也是要求是普通流行的，因为要考虑交流的问题。

如：原型、草绘图、WORD、EXCEL、PPT、POWERDESIGNER、STARTUML等。

这里只强调原型化方法，原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。

原型主要有三种类型：探索型、实验型、进化型。

探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性；

实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。

进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。

在使用原型化方法时有两种不同的策略：废弃策略、追加策略。

废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模型系统就被废弃不用。探索型和实验型属于这种策略。

追加策略：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，发展成为最终系统。进化型属于这种策略。

2调研项目前期情况

对象：售前人员、商务人员、项目经理；

内容：招标书、答标书、合同、以及其他与用户交流的口头或书面材料（包括宣传、承诺等）

甲方行业情况的了解、最好看一些行业方面的书籍，学习业务领域知识。

了解客户、项目的背景，如果事先客户给过类似的《软件初步思路》之类原始需求文档，那么首先弄懂这个文档，了解客户的目的，为什么要做这个软件，主要想解决什么问题，涉及的业务有哪些等等，这些调研准备的基础。

根据了解的初步用户需求，分析可能的难点在什么地方，列出这些难点。做到心中有数，并且记录前面了解需求的过程中不明白的地方，便于到现场后及时和客户沟通。

3建立需求调研规范

一定建立一个专门的设计环境（文档目录）来为本项目服务，进行一定的资源分配，进行必要的文件管理。

(1)统一项目所用工具

(2)统一项目文件模版

(3)其它资源列表（资料，相关网站，资询电话）

4明确客户方组织结构

用户单位的组织机构是什么，哪些部门和人员岗位参与本系统的使用？上下级关系如何？为项目组建立起外部联系通讯录。

了解客户的组织机构，涉及软件使用的部门，参与调研的部门和人员，客户关键人是谁等等，尽可能获得客户上层的支持，自上而下的开展需求调研会使调研工作更容易推动。客户需求小组成员要尽可能多的代表客户不同的用户层次。

5制定项目的调研计划

调研计划制定目的：对调研活动序列进行划分、评估、资源分配。

在制定计划时考虑到分析时间。计划在公司内部评审通过后，及时提交给客户，让客户对调研计划有充分的了解。

调研计划包含的内容：

(1)调查什么？通过什么方式调查？何人何时调查？

(2)明确项目组人员分工（培养我们的专家）

(3)调研中大家遵循的约定（如：需不需要签字？何时召开例会等）

(4)针对需求中的功能模块，客户方有明确的唯一配合联系人

注意事项：

项目任务书下达给后，项目经理及调研人员应该对合同中软件范围认真审阅，虽然只大概写了需求范围，但这些信息及为重要，它是调研计划制定的一个依据。

计划制定后最好召开项目启动会议，相关领导和业务部门参与，确定双方项目组成员，确定客户方的配合人（唯一联系人）、领导（唯一协调人），介绍项目组的人员安排、总计划、需求调研计划将行程和计划通知客户

四、需求调研内容

1需求调研要收集的内容

需求分析报告的读者有客户、设计人员、开发人员，在编写时一定要考虑到文档的可读性。需求调研形成的成果具体如下：

(1)收集用户需要产生的单据和报表 ；表单及报表的适用对象；

(2)画出业务流程图，并认真检查和核对每条路径中是否完备，异常情况怎样处理（系统的动态特性）；

(3)依据流程图收集每个步骤需要的使用和 *** 作的数据，确定数据的类型和范围（系统的静态特性）；

(4)画出业务实体及其关系，并估计业务实体的产生频率和数据量；

(5)评估业务流程和实体中需求变化的可能性；

(6)用户权限；

(7)信息系统建设现状；

(8)收集用户对系统界面风格、版式、颜色的偏好和需求；

(9)对系统将来使用的硬件、 *** 作系统、网络情况进行了解；

(10)收集系统初始化数据，或者要求客户进行收集和整理，明确期限时间；

(11)编制简单界面原型（该步骤也可放在需求分析之后完成，再次和用户进行沟通）;

2需求调研成果

(1)《需求规格说明书》

(2)系统详细原型

五、如何做好需求调研

1要做什么就要先了解什么

如果对客户业务不熟悉，在调研前要先做好充分的准备。

如果做的项目是你所不了解的行业（专业），最好要有专家——最终用户做专家是最好的，调研要了解这个专业，不是要你成为专家，但最少要了解一定的专业知识（最少专来词汇你要知道），否则就不知道去问什么或如何去问他们，甚至于人家在说什么你也不知道。

相应的专业资料是必须的，最少要有专业入门书籍和对应的资料，也需要更深入的一些资料。当然有专家的参与就另当别论。

如果行业的难度不是很大，可以通过分析人员的自我学习在短时间内了解行业，也许可以不用专家，否则专家是必须的。

2采用多种手段挖掘需求

重视调研资料的准备：调研资料（Rose图、Ppt、原型准备）一般客户图形化界面感兴趣，最好是采用图的方式把东西展示给用户，可以意思转换为用例图、用户界面、流程协作图、状态图等。

需求调研过程有选择的确定调查方式，例如：

1)与客户交谈，向用户提问题;

2)参观用户工作流程，观察用户 *** 作;

3)向用户发调查问卷;

用户通常没有耐心回答论述题，所以应当以选择题和是非题为主。

4)与同行、专家交谈，听取他们的意见;

5)分析已经存在的软件产品，提取需求;

6)从行业标准、规划中提取需求;

7)上网搜索相关资料

3站在用户的立场上考虑系统功能

1)设身处地的成为用户，考虑适用型和用户体验；

2)用户的语言与用户交流;

3)总结以往的实施经验，提出建议;

4)总结以往的实施经验，引导需求;

以上各条也是尽量减少需求变更的手段之一；

45W + 1H方法

5W：why、what 、who、when、where

1H：How to accomplish(实现) the system

WHY定律：WHY就是为什么用户要引入系统，引入新的信息系统对用户有什么帮助，在总体工作效能上如何实现一个最终的结果？WHY定律是要求在需求开始时，项经理就应该明确的，这个项目是为了改进用户工作效率；提高部门间的协作机制；加快对客户反应的体系服务；提升企业的竞争力等等。有了这么一个WHY引入思想，项目经理就可以理清用户最终要的是可以提供给他们什么样的系统，在系统的定位和建立上，就有一个明确目标。

WHAT定律：有了一个总体的目标性，从各业务流程的要求入手，引入第二个W定律__-WHAT定律，WHAT则是这个系统要做什么？实现什么？提出各业务流程问题、流程局限性问题、系统要解决的问题等，在这个WHAT的基础上，把系统划分成各功能模块，逐步弄清模块流程需求、功能需求、结构需求。引入WHAT定律可以让我们了解到系统的初步需求。

WHO、WHEN、WHERE定律：这个阶段是需求细化阶段，在WHAT定律的基础上，细分系统的用户需求：分析什么人，在什么时间，什么阶段可以或必须 *** 作这个功能，结合前面的WHAT定律，理清系统的流程阶段划分，记录并分析系统功能实现的细节，在这个阶段就可以产生系统需求的用例图（Use Case），作为下阶段设计的依据。

HOW定律：就是怎样实现系统了，在前面的WHY、WHAT、WHO、WHEN、WHERE基础上，已经搭建了一个非常好的系统需求基础框架，如何在这些用户需求的基础上，分析系统的需求，如何进行需求规格的分析与下阶段的设计、实现工作，就是How to accomplish(实现) the system

引入这5W+1H的定律，在一定程度上保证了系统需求的准确性，使得项目经理或需求分析人员可以有序、有条理地开展需求挖掘和调研活动，这样的安排用户在配合上也非常清晰，知道如何与项目人员配合。

5需求调研注意事项

(1)按照计划有步骤的调研

提前约定调研活动的计划，达到的目标，时间安排，参与的人员，并根据用户安排，适当调整计划。最忌参加会议时目标不明确、汇报人员不明确。

按照事先和客户商量好的调研计划稳步进行，如果现场临时出现变化，比如参与调研的客户临时有事，或者调研的内容出现变化，那么及时和客户确定新的调研安排，列出总的调研顺序。切忌想到哪说到哪，调研内容杂乱无序，很有可能就会出现遗漏而不能及时发现。

(2)掌控调研进程，推动调研工作顺利进行

因为调研工作实际就是和客户聊天谈话，很可能就会经常跑题，越扯越远，另外客户的精力一般也容易不集中，跑神，这时候，调研人员要能够掌控整个进程，什么时候及时把客户的思路拉回到正题上，什么时候适当的聊聊其他的话题调节气氛，都需要调研人员灵活掌握，总之一个目的，尽快的推动调研工作朝前进行。

(3) 认真仔细的倾听，及时的记录

仔细的倾听就是要明白客户的完整的表达，不要觉得有些你已经懂了，经常打断客户来急切表达自己的看法，每次在客户完整的把话说完再表达自己的想法。及时记录涉及客户业务、实际工作、客户想法的内容，不能以为当时听明白了就不去记录。一定要有记录的习惯，谈上几个小时，很多细节是记不住的。

(4)先了解宏观需求，再了解细节需求

遵从由总到分、由粗到细、由简单到复杂的调研过程，无论是让客户介绍他们的业务还是谈他们的想法，都要先从总的大的方面说起，然后再是细节。如果直接进入细节，往往并不能很好的抓住他的要点，不能把握总体的要求。

(5)挖掘客户最原始的需求，而不是仅仅只是记录

客户跟你说的内容只是他的一个理解，他的理解可能也有偏差，而且现在有的客户因为对软件比较了解，往往告诉你的不是需求，而是他的设计思路，比如直接跟你说“你做个这样的功能，我一点就能出来什么什么”，对我们来说，就需要多问几个问什么，“你为什么会这样做呢？”“你想看的结果是什么呢？目的是什么呢”等等，一定要想办法了解到客户没有经过转化的最原始的需求，因为往往很多时候客户告诉你的他的想法并不能实现他原本的目的，而他以为能实现，所以就直接告诉你想法。需求调研人员如果没有了解到最原始的需求而只是把客户的想法记录下来，那么就会出现做出来的东西解决不了客户实际的问题。

这个过程往往同时也能够帮助我们缩小需求范围，比如客户开始想的好好的一些功能，但是在我们深入分析思考后发现因为存在某些问题这些功能无法实现，或者即使实现也会大幅增加工作量比开始想象的复杂的多，那么在这样一个基础上说服客户放弃这个想法。这也是在合同额确定的情况下砍功能的一种方式。

(6)引导客户的潜在需求

大部分客户对自己要做成一个什么样的软件并没有一个完整的规划或者想法，很多时候都是在谈的过程中逐步的清晰。调研的过程也不会是客户滔滔不绝的谈他的想法，而是靠你一点点的去问客户，那么到底问什么，就需要你掌握，除了不懂的业务以外，重要的是在已经了解的客户需求的基础上分析、扩展，带出其他潜在的客户没有说出来的需求。比如说客户想做一个领用办公用品的功能，开始想的很简单，填一个领用申请，一审批就行了，但是经过仔细分析后，就会衍生出“物品管理”“类别管理”“库存管理”等潜在需求。如果不考虑这些，那么无论是你还是客户都会认为这个功能很简单，那么对完成时间和工作量的估计都会出现问题。防止出现在做系统设计甚至是开发时才发现“当时没想到这个地方没那么简单，还需要再跟客户沟通一下”这种情况。

这里面，潜在需求如果细化的话还分为两个部分：1）系统必须的；2）系统不必须的。“必须的”就是像上面例子一样，如果不挖掘潜在需求，客户已经提出的需求就无法实现，就是把看上去简单的复杂问题，实际上他还是个复杂问题。“不必须的”，就是对已经提出的客户需求影响不大，相对独立，相当于再和客户沟通的过程中又了解到的新的需求。对这部分，就需要根据调研时项目的合同额是否确定，工作量大小，和客户的关系如何等等有需求调研人员灵活掌握，可以提也可以不提。但是提出就肯定会增加工作量和系统的复杂度。

(7)规避客户不合理的要求和较难实现的要求

客户需要的不一定的是客户真正所需要想要的。客户永远没有错，错的只有我们没有真正理解客户的需要。

调研时要把握主题的能力，分清有用功能、可选功能用、无用功能及不可实现功能，及时表达我们的观点，让谈话接近主题。

调研的过程中，不可避免的会出现客户提出一些我们现有条件下根本无法实现或者即使实现也非常困难的要求。这种情况就需要需求调研人员的聪明的头脑和快速反应能力，同时也需要调研人员的良好的沟通技巧，要能巧妙地说服客户放弃这种方式并且还要客户能够理解，而不致认为你在逃避问题不想解决。一般可以采取这些方式：1）客户提出这些要求后能马上了解客户提出这个要求的真实目的，然后快速思考出另外的简单的方式同样能实现客户的这个目的。这是最好的方式；

2）必要时直接告诉客户无法实现并且给出合理的理由，特别是在客户说某某系统已经实现了这个方式时，比如他们用的是什么什么平台支持，这个平台支持需要另外付费等等；

3）直接告诉客户虽然能实现，但是需要很大的精力和成本，而这个可能是客户无法承受的，当然你一定要能说出客户听起来合理的理由。

这些都不是绝对的，需要调研人员丰富的软件开发经验和灵活的头脑较好的表达能力临场发挥。

(8)注意需求调研的覆盖面，防止需求不具代表性

需求调研开始时，客户明确的唯一配合联系人既是我们每个模块的一把手！我们要做的就是“拿着鸡毛当令箭”！找对人才能办好事。

同时也要防止提供需求的客户方面只有一个人，使实际软件需求变成个人需求。受制于这个人的所处层次，以及掌握的业务知识，与领导意图的符合度等等限制，给我们带来较大的需求风险，稍有不慎就会给后面软件需求变更埋下伏笔。避免这种风险，一方面调研人员依据以往的经验和业务知识自己判断客户提出的需求是否合适，有没有过于强烈的个人特征等等，另一方面，在调研开展的最初想办法和客户的上层明确类似风险的存在，让客户领导在人员安排上避免这种情况，同时也是让他明白会存在这种情况，以后一旦真的出现，客户也不会说是我们的责任。

(9)及时总结整理已经完成的调研内容

需求调研、相关会议纪要及时转发，及时总结成果，让客户听听你的理解是否他们提的需求一致。

每次调研回去后，及时把白天调研的内容及时整理出来，当时没来的急记的内容及时补记，同时再深入的分析、过一遍，确保有没有遗漏的问题，列出所有的疑问待到第二天调研时询问客户。

定期汇总的成果：什么情况下？什么人？做了什么决定？产出了什么？

(1)警惕不明确因素

实现某一个功能的前提条件是什么？如果没有哪个先决条件，哪些工作是无法开展的？责任划分清楚。

(2)成本，成本还是成本

高水平的设计师高就高在设计出“恰好”满足客户需求的软件，并且在开发方和客户方获取最大的利益，而不是不惜代价设计出最先进的软件。

(3)避免片面听取了某些用户的需求而忽视其他用户的需求

六、什么是成功的需求调研

1需求规格说明书具备的特性

正确、清楚、无二义性、一致（各个需求之间不产生矛盾）、必要（不画蛇添足增加开发成本）、完备（不遗漏必要的功能如权限配置）、可实现性、可验证性（提供交付依据）、明确优先级（不被细节拖死比如UI）、阐述“做什么”而不是“怎么做”。

2覆盖合同中所有合理的需求

对待需求工程的态度可以分为“被动型”、“主动型”和“领先型”三种，只有后两种才有可能开发出成功的产品。

在实际工作中，可以建立合同与需求规格说明书对应章节对应表、合同与软件功能对应表。时刻提醒需要提供实现的业务范围。

3成本风险在控制之内

4挖掘潜在的需求

适当站在商务的立场上思考，为项目的寻找出路，申请更多的财力物力。

七、签字画押

我们编写完的需求分析报告，最终要展示给客户，让他们对我们的分析结果进行认可。其实这个过程非常重要，对于客户和我们同样的重要。将业务需求与用户进行确认（采用会议讲解的方式），用户领导签字。 这个挺难的。

八、需求调研人员能力

1熟悉客户业务

对于客户主要想让软件来解决他哪一部分的业务，事先最好能通过一些手段尽可能多的了解。即使事先并不能非常深入，那么也要利用调研的机会尽可能多的了解，调研完成后，没有理由你不是个半个业务专家。

2熟悉软件开发

调研的过程中一方面你要随时对客户提出的要求的合理性、难易性作出判断，同时你还要在客户想法不成熟时提供给客户好的实现方式，这一切都需求你对软件开发非常熟悉，很多时候，需求调研人员至少曾经是一个优秀的软件开发人员。因为随着用户使用电脑的增多，对各种软件有一定的了解，往往会直接提出一些功能要求，比如在任务发起时提出需要给多人发送，那么对这样的一个功能会对我们的设计和开发有什么样的影响，那就需要现场需求调研人员根据自己的经验作出判断，然后思考出有利于自己的方式并巧妙的说服客户接受。

3头脑聪明，反应敏捷

对客户表达的内容要能很快的、充分的理解，并且能迅速的思考及时应对。同时因为客户的水平也有高低，特别是对那些不善表达的客户，更需要你从不清楚的表达中分析出实质。

比如对于税务系统预警的调研，客户本身事先并没有完善的预警规则，很多都是调研现场临时思考出来的，那么这样的一个规则敲定后，你敢拿这样的内容去设计开发吗？那么就需要调研人员根据掌握的业务知识，在现场时及时根据客户提出规则迅速的在脑子里发散、扩展、分析、思考，找出规则是否还有漏洞，和客户继续深入探讨下去。

4善于表达，思路清晰

能够把你的想法清晰的传达给客户，特别在一些难以理解的地方，能够灵活的用各种可能的方式让客户明白你的意图。当你在解释半天客户都没有明白的时候，一定要想想你在什么地方没有解释清楚了。

5善于观察，精于总结

和客户打交道的过程中，善于观察每个细节，分析这些细节是否对你的工作有影响，每次阶段性调研完成后及时总结，来帮助更好的进行下一次的调研。比如在调研间隙观察客户的实际工作内容和工作流程，攀谈了解相关情况，观察客户是否还在使用其他系统，了解其他系统的情况；观察客户群体中的关键人物；观察客户各有什么爱好、特点等等。当天调研完成后，及时回顾整理一天的调研内容，筛选出疑问，便于第二天调研时向客户了解清楚。

6善于记录，文笔流畅

一直强调，在客户现场，把你听到的看到的能记多少就记多少，尽可能的多记，，特别是客户在讲述自己实际的工作业务工作内容和方法等时，不要管他回去以后有没有用，千万不能因为当时听明白了就不记了，即使一时没有时间，那么事后也要及时补记下来。这些一手材料里有很多都是能够帮助你和没有参加调研的人理解业务需求的内容。防止出现，1）当时听明白了但没记录的内容，回来后某些细节又忘了；2）当时虽然记了，但写的内容太简单，回来后看当时记得内容已经想不起来是怎么回事了。

针对产品需求、项目需求的调研，会分三章进行讲解：一、需求调研计划；二、需求调研访问模板；三、需求调研报告。这是需求调研相对标准的3个部分。

需求调研计划介绍

如产品或项目是刚启动的，那么一般都会有需求调研阶段，有需求调研就可能会需要编写需求调研计划，但是很多产品的需求都是来自创始人和团队，基本都是靠自己构思产品，然后做一些市场调研分析、竞品分析等，可以不需要做需求调研计划。如果是做项目，通常是需要的，系统越大越需要，但是也有一些小项目也是几次讨论交流就能完成调研的，也可以不用做调研计划。不过不管你的产品要不要做调研计划，多了解一点有备无患。

下面先来说一下如何做需求调研计划。

1、调研的内容要根据大致需求、调研对象以及调研对象时间进行安排，通常企业内的大项目调研阶段，调研对象的时间都会重点倾斜支持调研团队。

2、调研的时间要通常在半小时到2小时，要提前预定好会议室

3、调研对象一定要明确具体业务需求负责人以及所属岗位

4、调研计划编制完成后，要和产品或项目负责人开会确认计划，以便后续的工作能开展。

5、调研计划的内容要有开头启动和结尾汇报的内容，中间为具体需求调研的内容计划。

需求调研计划模板

1、需求阶段监理的定位

原则上尊重承建方的项目管理和项目分析能力，在具体的任务开展上，以不深入、不干扰承建方的自主权为主，但是如果在项目合作过程中发现中软项目管理以及项目分析能力在本项目的进行上存在很大的差距和不足，为了保证项目的成功顺利开展监理内部必须加强项目管理能力和项目分析能力，在具体的 *** 作上可以坚持吸收、同化、贯彻的方法和手段。

2、需求分析的进展方式及监理角色的把握

需求分析是一个项目的开端，也是项目建设的基石，在以往的建设失败的项目中80%的是由于需求分析的不明确而造成的，因此一个项目的成功的关键因素之一，就是对需求分析的把握程度上，项目的整体风险具体表现方式在需求分析不明确、业务流程不合理上，用户不习惯或者不愿意去用承建方的软件，或者很难去用，造成了项目失败。因此作为第三方的监理公司，必须提醒承建方、客户方重视需求分析的重要性，采用必要的手段和方法来进行需求调研。同时监理方也应深入具体的需求调研中去，只有这样才能切切实实的把握用户的需求和方向，才能在将来的功能界定、开发范围上有发言权。

21、为什么咨询监理方要对需求分析进行重点监控

由于项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，所以在整个软件的开发周期中，需求分析的重要性是不言而喻，需求分析难做的的确确难做，这是基本是由于以下几种原因造成的：

（1）客户说不清楚需求；（2）需求自身经常变动；（3）分析人员或客户理解有误。

211客户说不清楚需求

有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如全国各地的很多部门、机构、单位在进行应用系统以及网络建设，客户方的领导和办公人员大多不清楚计算机网络有什么用；缺乏系统的IT建设方面的专家和知识。这时间就会要求软件系统分析人员替他们设想需求。工程的需求存在一定的主观性，为项目建设埋下潜在的风险。

222需求自身经常变动

根据以往的历史经验，随着客户方对信息化建设的认识和自己业务水平的整合提高，会在不同的阶段和时期对项目的需求提出新的要求和需求变更，其实在历史上没有一个软件的需求改动少于三次的，所以必须接受“需求会变动”这个事实，所以在进行需求分析时就要防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上，同时留出变更空间。咨询监理方在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须参与到需求分析的准备中来，以便协助客户方和承建方来界定“做什么”、“不做什么”的系统功能界限。

213 分析人员或客户理解有误

软件系统分析人员不可能都是全才，更不可能是行业方面的专家。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致以后的开发工作劳而无功，记得一则笑话“有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：”主宰地球的是汽车。它们喝汽油，靠四个轮子滚动前进。嗓门极大，在夜里双眼能射出强光。……有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。‘“所以分析人员的知识的专一性也会造成需求分析的误解和失败。这时间咨询监理公司就必须根据实际的项目需求调研计划，提醒承建方加强业务了解程度和注重沟通技巧。

22咨询监理公司如何进行需求分析

需求分析不象侦探推理那样从蛛丝马迹着手。应该先了解宏观的问题，再了解细节的问题，

一个应用软件系统（记为 S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。

S = { D1，D2，D3，… Dn }

问题域Di 由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。

Di = { P1，P2，P3，… Pm }

问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。

Pj = { F1，F2，F3，… Fk }

按图41结构写成的需求说明书，对于那些只想了解宏观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时还应该注意两个问题：

（1）最好为每个需求注释“为什么”，这样可让程序员了解需求的本质，以便选用最合适的技术来实现此需求。

（2）需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。

23咨询监理公司需求分析方法论

根据以往的工程经验基本认为需求分析工作方法，应该定位在“三个阶段”（也称“三步法”）。

首先：“访谈式”，这一阶段为和具体用户方的领导层、业务层人员的访谈式沟通上，主要目的基本是从宏观上把我用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息。建立起良好的沟通渠道和方式，针对具体的职能部门以及各委办局最好能指定本次项目的接口人。

实现手段：访谈、调查表格

输出成果：调查报告、业务流程报告

第三阶段：“确认式”，这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰的向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表； *** 作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受审查过的报告、文档签字确认。

实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统

输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档）

整体来讲，需求分析的三个阶段是需求调研中不可忽视一个重要的部分，三个阶段或者说三步法的实施和采用，对用户、承建方来讲，都同样提供了项目成功的保证。当然在系统建设的过程中，特别在采用迭代法的开发模式后，需求分析的工作会一直进行下去，在后期的需求改进中，基本是处于以后两个阶段。

更多关于工程/服务/采购类的标书代写制作，提升中标率，您可以点击底部官网客服免费咨询：>

以上就是关于如何做好需求分析，需求调研全部的内容，包括:如何做好需求分析，需求调研、软件市场调研报告、实习报告 IT行业等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！