一、什么是需求调研？
　　需求调研对于一个应用软件开发来说，是一个系统开发的开始阶段，它的输出“软件需求分析报告”是设计阶段的输入，需求调研的质量对于一个应用软件来说，是一个极其重要的阶段，它的质量在一定程度上来说决定了一个软件的交付结果。怎样从客户中听取用户需求、分析用户需求就成为调研人员最重要的任务。
　　需求调研是为需求说明书撰写做前期工作，需求说明书是从需求调研表中得到或抽取而出；是了解实际工作中真正需要什么样的程序的过程，再把这些需求细节整理由设计部开发，给用户使用。
　　需求调研，特别是合同额已经确定的项目的需求调研，就像外交一样，实际上是一种策略艺术，它是在和客户相互尊重、平等互利的基础上，不卑不亢的去交流沟通，守住我方底线，尽可能的争取有利于我方条件，在完成任务的同时，还能赢得客户的理解和尊重。
　　需求调研，简而言之就是和客户进行谈话沟通，把客户的想法和要求记录下来，最后整理成为《用户需求说明》，以便进行下一步的需求分析、系统设计等，正因为后面的需求分析、系统设计，乃至开发等等都以需求调研的内容为依据，那么需求调研质量的好坏直接就决定了软件系统的好坏，也即项目的成败。
　　通常我们一提到某个系统，感觉上应该始终就是一个东西，但其实在不同人眼里，可能是不一样的，比如按照一般软件开发过程来说，就有如下几种：
　　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).总结以往的实施经验，引导需求;
　　*以上各条也是尽量减少需求变更的手段之一；
　　4.5W + 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).挖掘客户最原始的需求，而不是仅仅只是记录
　　客户跟你说的内容只是他的一个理解，他的理解可能也有偏差，而且现在有的客户因为对软件比较了解，往往告诉你的不是需求，而是他的设计思路，比如直接跟你说“你做个这样的功能，我一点就能出来什么什么”，对我们来说，就需要多问几个问什么，“你为什么会这样做呢？”“你想看的结果是什么呢？目的是什么呢”等等，一定要想办法了解到客户没有经过转化的最原始的需求，因为往往很多时候客户告诉你的他的想法并不能实现他原本的目的，而他以为能实现，所以就直接告诉你想法。需求调研人员如果没有了解到最原始的需求而只是把客户的想法记录下来，那么就会出现做出来的东西解决不了客户实际的问题。
　　这个过程往往同时也能够帮助我们缩小需求范围，比如客户开始想的好好的一些功能，但是在我们深入分析思考后发现因为存在某些问题这些功能无法实现，或者即使实现也会大幅增加工作量比开始想象的复杂的多，那么在这样一个基础上说服客户放弃这个想法。这也是在合同额确定的情况下砍功能的一种方式。