如何做软件开发的前期需求调研（软件项目开发流程需求调研）
今天给各位分享如何做软件开发的前期需求调研的知识，其中也会对软件项目开发流程需求调研进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
如何做好软件项目需求分析
软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，通过对应用问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化、最终形成需求规格说明，这一系列的活动即构成软件开发生命周期的需求分析阶段。
需求分析是介于系统分析和软件设计阶段之间的重要桥梁。一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整;另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。
需求分析阶段的基本任务是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件其它有效的需求。
需求确定为什么困难?
最主要的原因是对于开发小组的使用成员(包括用户)来说，需求确定是极具认知性和创造性的活动。需求确定也许是仍在苦苦等待人工智能支持的最后领域之一。
具体表现如下：
系统分析员对问题域的了解程度也是一大困难。
系统分析员感到需求确定很困难的另一个原因是问题域的动态性。
生活是动态的，公司也是。
项目团队成员之间的沟通也一直是需求确定的另一大困难。
每个问题域都有术语。
最后，需求确定过程还会受到其它因素的影响。例如劳累、不舒服、开会时室内和窗外的干扰、团队成员的压力等等。
如何进行需求调研
力，才能真正体现出软件的价值。
4.编写用户需求说明书
需求调研的步骤
需求分析员对收集到的所有需求信息进行分类整理，消除错误，归纳与总结共性的用户需求，然后形成文档，编写《用户需求说明书》。对于《用户需求说明书》要和客户以及相关的行业专家进行共同评审。以前整理的需求记录可以作为附件整理在《用户需求说明书》之后。
《用户需求说明书》与《产品需求规格说明书》的主要区别与联系是：
（1）前者主要采用自然语言（和应用域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够详细。
（2）后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，产品需求是软件系统设计的直接依据。
（3）两者之间可能并不存在一一影射关系，因为软件开发商会根据产品发展战略、企业当前状况适当地调整产品需求，例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据《产品需求规格说明书》来开发当前产品。
需求调研的步骤
用户需求说明书的模板
需求调研中的注意事项
对每一次的调研形成正确的文档
需求调研中的注意事项
需求调研是一个漫长的过程。能够正确理解用户的需求，并且将用户的各种需求完整地体现在《软件需求规格说明书》中将更是一个复杂而艰辛的过程，因此在每一次的会谈之后必须将当天的会谈纪录形成文档，可以以备忘录的形式让用户进行确认。
需求调研后形成的文档文档必须是正确的，是经过验证的，是在受控的状态下变更的。而很多开发人员往往会问：“简单的系统就不用写需求了吧？”其实简单的系统未必简单，只有想清楚、写清楚、说清楚才说明已经真正把需求整理清楚了。
做好需求变更的控制
需求调研中的注意事项
对每一次的变更要双发进行确认，并进行版本控制，做到有据可依。
如何进行需求分析（教科书式的回答）
一、什么是需求调研？
需求调研对于一个应用软件开发来说，是一个系统开发的开始阶段，它的输出“软件需求分析报告”是设计阶段的输入，需求调研的质量对于一个应用软件来说，是一个极其重要的阶段，它的质量在一定程度上来说决定了一个软件的交付结果。怎样从客户中听取用户需求、分析用户需求就成为调研人员最重要的任务。
需求调研是为需求说明书撰写做前期工作，需求说明书是从需求调研表中得到或抽取而出；是了解实际工作中真正需要什么样的程序的过程，再把这些需求细节整理由设计部开发，给用户使用。
需求调研，特别是合同额已经确定的项目的需求调研，就像外交一样，实际上是一种策略艺术，它是在和客户相互尊重、平等互利的基础上，不卑不亢的去交流沟通，守住我方底线，尽可能的争取有利于我方条件，在完成任务的同时，还能赢得客户的理解和尊重。
需求调研，简而言之就是和客户进行谈话沟通，把客户的想法和要求记录下来，最后整理成为《用户需求说明》，以便进行下一步的需求分析、系统设计等，正因为后面的需求分析、系统设计，乃至开发等等都以需求调研的内容为依据，那么需求调研质量的好坏直接就决定了软件系统的好坏，也即项目的成败。
通常我们一提到某个系统，感觉上应该始终就是一个东西，但其实在不同人眼里，可能是不一样的，比如按照一般软件开发过程来说，就有如下几种：
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).挖掘客户最原始的需求，而不是仅仅只是记录
客户跟你说的内容只是他的一个理解，他的理解可能也有偏差，而且现在有的客户因为对软件比较了解，往往告诉你的不是需求，而是他的设计思路，比如直接跟你说“你做个这样的功能，我一点就能出来什么什么”，对我们来说，就需要多问几个问什么，“你为什么会这样做呢？”“你想看的结果是什么呢？目的是什么呢”等等，一定要想办法了解到客户没有经过转化的最原始的需求，因为往往很多时候客户告诉你的他的想法并不能实现他原本的目的，而他以为能实现，所以就直接告诉你想法。需求调研人员如果没有了解到最原始的需求而只是把客户的想法记录下来，那么就会出现做出来的东西解决不了客户实际的问题。
这个过程往往同时也能够帮助我们缩小需求范围，比如客户开始想的好好的一些功能，但是在我们深入分析思考后发现因为存在某些问题这些功能无法实现，或者即使实现也会大幅增加工作量比开始想象的复杂的多，那么在这样一个基础上说服客户放弃这个想法。这也是在合同额确定的情况下砍功能的一种方式。
(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）当时虽然记了，但写的内容太简单，回来后看当时记得内容已经想不起来是怎么回事了。
如何做好需求分析，需求调研
转载以下资料供参考
从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解需求分析指需求的分析、定义过程。
原因
需求分析就是分析软件用户的需求是什么。如果投入大量的人力，物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的(相信大家都有体会)。比如：用户需要一个for linux的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发for windows的软件。当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。
需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。在一个大型软件系统的开发中，他的作用要远远大于程序设计。
任务
简言之，需求分析的任务就是解决“做什么"的问题，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求。
过程
需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。
问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。
分析与综合： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。
制订规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。
评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。
方法
需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从来没用过这些方法在此不讨论。
原型化方法是十分重要的，原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。
原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。
原型主要有三种类型：探索型、实验型、进化型。
探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。
实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。
进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。
在使用原型化方法时有两种不同的策略：废弃策略、追加策略。
废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模型系统就被废弃不用。探索型和实验型属于这种策略。
追加策略：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，发展成为最终系统。进化型属于这种策略。
需求分析20条法则
客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。
1、 分析人员要使用符合客户语言习惯的表达
需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。
2、分析人员要了解客户的业务及目标
只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下旧系统，有利于他们明白系统是怎样工作的，其流程情况以及可供改进之处。
3、 分析人员必须编写软件需求报告
分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。
4、 要求得到需求工作结果的解释说明
分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。
5、 开发人员要尊重客户的意见
如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。
6、 开发人员要对需求及产品实施提出建议和解决方案
通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。
7、 描述产品使用特性
客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。
8、 允许重用已有的软件组件
需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。
9、 要求对变更的代价提供真实可靠的评估
有不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。
10、 获得满足客户功能和质量要求的系统
每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。
11、 给分析人员讲解您的业务
分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。
12、 抽出时间清楚地说明并完善需求
客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。
13、 准确而详细地说明需求
编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。
在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。
14、 及时作出决定
分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。
15、 尊重开发人员的需求可行性及成本评估
所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。
16、 划分需求的优先级
绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。
在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。
17、 评审需求文档和原型
客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。
18、 需求变更要立即联系
不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。
19、 遵照开发小组处理需求变更的过程
为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。
20、 尊重开发人员采用的需求分析过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。
“需求确认”意味着什么
在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”
这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”
同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”
这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。
对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。 需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人ONT
如何做好需求分析，需求调研？
转载以下资料供参考\x0d\x0a\x0d\x0a从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。\x0d\x0a狭义上理解需求分析指需求的分析、定义过程。\x0d\x0a原因\x0d\x0a需求分析就是分析软件用户的需求是什么。如果投入大量的人力，物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的(相信大家都有体会)。比如：用户需要一个for linux的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发for windows的软件。当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。\x0d\x0a需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。在一个大型软件系统的开发中，他的作用要远远大于程序设计。\x0d\x0a任务\x0d\x0a简言之，需求分析的任务就是解决“做什么"的问题，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求。\x0d\x0a过程\x0d\x0a需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。\x0d\x0a问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。\x0d\x0a分析与综合： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。\x0d\x0a制订规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。\x0d\x0a评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。\x0d\x0a方法\x0d\x0a需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从来没用过这些方法在此不讨论。\x0d\x0a原型化方法是十分重要的，原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。\x0d\x0a原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。\x0d\x0a原型主要有三种类型：探索型、实验型、进化型。\x0d\x0a探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。\x0d\x0a实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。\x0d\x0a进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。\x0d\x0a在使用原型化方法时有两种不同的策略：废弃策略、追加策略。\x0d\x0a废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模型系统就被废弃不用。探索型和实验型属于这种策略。\x0d\x0a追加策略：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，发展成为最终系统。进化型属于这种策略。\x0d\x0a\x0d\x0a需求分析20条法则\x0d\x0a客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。\x0d\x0a1、 分析人员要使用符合客户语言习惯的表达\x0d\x0a需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。\x0d\x0a2、分析人员要了解客户的业务及目标\x0d\x0a只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下旧系统，有利于他们明白系统是怎样工作的，其流程情况以及可供改进之处。\x0d\x0a3、 分析人员必须编写软件需求报告\x0d\x0a分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。\x0d\x0a4、 要求得到需求工作结果的解释说明\x0d\x0a分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。\x0d\x0a5、 开发人员要尊重客户的意见\x0d\x0a如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。\x0d\x0a6、 开发人员要对需求及产品实施提出建议和解决方案\x0d\x0a通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。\x0d\x0a7、 描述产品使用特性\x0d\x0a客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。\x0d\x0a8、 允许重用已有的软件组件\x0d\x0a需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。\x0d\x0a9、 要求对变更的代价提供真实可靠的评估\x0d\x0a有不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。\x0d\x0a10、 获得满足客户功能和质量要求的系统\x0d\x0a每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。\x0d\x0a11、 给分析人员讲解您的业务\x0d\x0a分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。\x0d\x0a12、 抽出时间清楚地说明并完善需求\x0d\x0a客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。\x0d\x0a13、 准确而详细地说明需求\x0d\x0a编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。\x0d\x0a在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。\x0d\x0a14、 及时作出决定\x0d\x0a分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。\x0d\x0a15、 尊重开发人员的需求可行性及成本评估\x0d\x0a所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。\x0d\x0a16、 划分需求的优先级\x0d\x0a绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。\x0d\x0a在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。\x0d\x0a17、 评审需求文档和原型\x0d\x0a客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。\x0d\x0a18、 需求变更要立即联系\x0d\x0a不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。\x0d\x0a19、 遵照开发小组处理需求变更的过程\x0d\x0a为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。\x0d\x0a20、 尊重开发人员采用的需求分析过程\x0d\x0a软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。\x0d\x0a“需求确认”意味着什么\x0d\x0a在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”\x0d\x0a这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”\x0d\x0a同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”\x0d\x0a这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。\x0d\x0a对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。 需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人ONT
如何进行软件需求分析
软件需求分析免费下载
链接:
提取码:qoyw
需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。
如何做软件开发的前期需求调研的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于软件项目开发流程需求调研、如何做软件开发的前期需求调研的信息别忘了在本站进行查找喔。
