软件项目需求调研方法论.docx
《软件项目需求调研方法论.docx》由会员分享，可在线阅读，更多相关《软件项目需求调研方法论.docx（20页珍藏版）》请在冰豆网上搜索。
软件项目需求调研方法论
需求调研方法论
文件版本：
文件编号：
编制人：
编制日期：
审核人：
审核日期：
批准人：
批准日期：
修改记录
版本号
修订人
修订日期
修订描述
1需求概述
1.1软件需求
1.1.1需求定义
需求是用户一种期望，是用户期望改善现状，解决某些问题或达到某种目标的需要。
需求实现的过程，就是通过软件产品的功能达成用户目标，使之与用户期望目标相符的过程。
1.1.2需求层次
软件需求的三个层次
1．业务需求：
反映了组织机构或用户对系统、产品高层次的目标要求。
2．用户需求：
描述了用户使用产品必须要完成的任务。
3．功能需求：
定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。
4．非功能性的需求：
不直接完成用户完成某项工作，但是在用户在操作系统过程中伴随产生的需要，描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。
1.1.3需求来源
软件需求可以来自方方面面，这取决于所开发产品的性质和开发环境。
下面是几个软件需求的典型来源。
1.访谈、调查用户或潜在用户
为找出新软件产品的用户需求，最直截了当的方法是询问他们。
通过直接与最终用户的访谈或调查，了解用户目前管理或应用过程中存在的问题、思想或想法、业务未来发展趋势，经过整理分析，形成软件需求。
2.研究竞争对手同类产品
当用户在实际工作中产生出新的需求后，总会有对需求感觉灵敏的厂商嗅到商机，把用户的需求转换为产品。
在我们没有更好条件深入到客户中进行调研的情况下，可以对竞争对手同类产品进行研究，发掘产品中的优点和存在不足，研究产品功能的目的和意义，倒推出软件需求。
3.需求分析人员的经验
需求分析人员要时刻保持对所在领域知识的敏感，勤于思考，结合积累的丰富的所在领域知识，加上自己的分析和判断，形成基于用户实际工作中需求的假设，形成软件需求。
4.市场支持活动
软件产品发布推广后，用户在实际工作中对软件产品进行检验。
在市场售后的支持人员在对用户进行培训和提供技术支持工作的同时，他们收集了用户在使用系统过程中所遇到的问题，还接受了用户关于系统改进的想法。
因此，可以通过收集市场支持人员接受的系统改进想法，并把它们转换为软件需求。
5.政策制度和法律法规
公司所在的国家、行业的政策制度和法律法规是企业经营活动过程中必须遵循的规则，对公司活动有强制约束力。
研究目标企业所在国家、行业的政策、法规和制度，发现其中信息化相关的要求，经过整理和分析形成软件需求。
尤其是当企业所使用的法律法规、政策制度发生变动时，是软件产品更新换代的一个重大契机。
1.2需求调研定义
通常情况下，用户无法独立直接提出完整、准确的需求，这就需要通过项目组的介入，借助需求调研把用户已经表述的需求弄清楚，挖掘用户尚未说明的需求。
需求调研指通过和用户进行沟通和交流而获取用户的需求的一系列活动，是为编写需求说明书而做的前期工作。
换言之，需求调研就是假设用户已经掌握需求，通过某些手段或方法将需求准确、完整的描述出来，以便软件开发的后续活动顺利进行。
1.3需求调研目的
需求调研就是了解参与实际工作的人们真正需要什么样程序的过程，获取准确、清晰、完整的用户需求信息，编写需求说明书，为后续工作提供依据。
需求调研有三个主要目的：
1、获取准确、清晰、完整的需求，包括功能需求和非功能需求；
2、确定需求的分级，划分需求优先级，指导后续工作；
3、收集调研对象业务资料，预测需求的发展趋势，为软件产品发展方向
提供依据。
1.4需求调研必要性
1、需求调研是减小用户“期望差异”的关键一步
软件产品作为一种特殊的商品，是软件公司通过有限的技术手段、资源为了满足用户的需要而开发出来的。
由于需求“效用”的不可计量，再加上软件产品不能直接创造价值的特殊性，用户就有可能会对最终产品产生“期望差异”，这种“期望差异”会影响用户对软件产品的满意度，影响软件产品的销售。
需求调研就是要了解到用户的期望，以期在软件研发过程中减小这种差异，提高用户的满意度。
软件需求也可以说是用户在一定的条件下为了改善管理条件、追逐更大利润的“欲望”。
当欲望得到满足，人们会感到快乐和幸福，这就是“效用”。
处于软件产品两端的用户和开发商由于受到客观条件的限制，双发不能传递准确的需求信息，在一开始无法在信息系统的需求上达成一致意见。
由于技术能力的局限，用户很难准确地把系统需求传达给开发商；由于业务局限，开发商也很难准确获取用户真实的应用需求。
需求信息的不对称和需求描述的错位，容易引起系统设计的缺陷，最终导致系统应用不理想甚至系统失败。
作为客观世界的存在，用户所处环境、思想等的不同，不同用户对同一领域的需求是存在差异的。
软件产品是在有限的资源、有限的时间、有限的技术手段和条件下研发出来的，不可能获取所有潜在用户的需求，也不可能满足所有潜在用户的需要，这就需要软件产品确立目标用户，重点关注目标用户的需求。
能够获取目标用户的满意，赢得目标用户的认同，促进目标市场的销售，就是一款成功的产品。
作为一家商业的软件公司，其追求的目标是利益最大化，利益的重要来源就是向市场推出更多令人满意的软件产品，获得市场的成功。
如何令用户对我们推出的产品满意，是作为软件研发、销售人员时刻警惕和思考的主题。
在我看来，让用户满意就是在用户看到、使用我们软件的时候满足其“期望”甚至超出他的“期望”，这就会引起用户的购买欲，从而带来销售机会。
而获取、了解用户的期望值，是软件产品能够满足用户期望的先决条件，只有了解了用户的期望，通过产品研发最大限度的实现用户期望，提升用户的满足感，研发出的软件产品才能更好贴近用户的期望，提升用户期望的满足度。
结论：
1）软件产品一定要有目标客户，目标客户的需求才是需要重点关注的；
2）需求调研很重要，是软件产品能够赢得市场的先决条件，是任何软件公司、软件研发人员必须重视的一个环节。
3）需求调研和分析是信息化建设的第一步，牵一发而动全身，做好需求调研是软件产品成功的关键一步。
2、需求变动大，可能是因为需求不完整、不清晰。
参与过软件研发的很多人都有这样的抱怨“用户需求又变了，截至今天已经变了3次，很多工作得重新返工，真不知道下次还会不会变了。
”，尽管无奈，又不得不对改变的需求重新评估、设计、开发、测试，这些变更不只是加大了软件研发的成本，对研发人员的积极性也是一种挫伤，降低了研发人员的成就感。
尽管需求发生变化时，对软件研发影响很大，但往往需求变更又是不可控的，需求变化是客观存在的，是作为软件研发人员必须正视和面对的问题随着目标用户的变化，目标用户认知的提高、用户内部环境的变化、外部境的变化、技术的进步等，需求也总是在不断改变的，往往是在前期需求得到满足后，会产生出更高层次的需求。
诚然，为保证软件研发的顺利进行，保证软件产品的按时交付，我们要对需求加强管理，控制需求变更，但是面对变更，我们更应该考虑如何减少变更发生的机会，让我们更多掌握研发的主动权。
更何况控制需求变更，不可避免的要牺牲用户的满意度，在软件产品还没有交付到用户手中时，已经产生了“期望差异”，势必对产品的销售造成影响。
换个角度看这个问题，用户的需求总是发生变化，很有可能是我们原本就没有完全获取用户的需求，或者没有挖掘出用户隐含的需求，研发所依据的需求是不完整、不清晰的。
通过需求调研，是获取完整、清晰用户需求的很好途径，有了完整、清晰需求作为研发依据，可以很好降低需求发生变化的几率。
结论：
1）需求变化是客观存在的，作为软件研发人员必须保持良好心态处理好需求变更；
2）需求在一定的时间范围、一定的环境下（经济环境、组织结构、发展期间、IT应用水平）、一定的用户群体范围内是确定的，或者说是相对确定的。
3）加强需求管理，进行需求调研，尽快、尽早获取完整、清晰需求是比控制需求变更更好的办法；
3、错误越早修复成本越低
需求阶段是软件研发中的一个重要阶段，其成果是研发后续各阶段工作的重要依据，对研发有着重大影响，需求质量的高低往往决定着一个项目的成败。
做好需求调研是获取完整、准确、清晰需求的前提，准确的需求是项目成功的关键。
据权威机构对软件各阶段发现错误修复成本的统计，如下图：
从上图可以看出，在软件研发过程中，越到后面阶段修复错误的成本越高，而且往往是需求阶段成本的成百上千倍。
进行需求调研，可以尽早使不清晰的需求更加明确，可以对不准确的需求进行修订，补充完善需求，尽早发现错误，尽快修复，减少研发过程中后续阶段的潜在错误数，缩短研发周期，降低研发成本。
结论：
需求调研可以有效减少研发过程中潜在的需求错误数量，降低研发成本。
1.5需求调研是否可裁剪
在实际的研发过程中，由于外部环境或内部环境的压力，软件研发往往面临着时间紧、任务重的局面，为了能够保证按时交付软件产品，项目管理者往往会选择裁剪或压缩需求调研，而给软件编码和测试预留充足时间，结果往往是项目结束时按期交付了产品，质量如何就不好说了。
在我看来，这样的过程是很危险的，很可能是花费了大量的时间成本和人力成本，得到一个并不被市场认可的产品，公司浪费了人力财力，参与其中的研发人员也不能从中获取成就感。
即使软件研发团队面临着工作量大、人员不足、时间紧张的局面，研发团队也不能在不了解需求的情况下直接编码，凭自我感觉做事。
需求不清晰、不完整、不稳定是项目最大的风险，可能导致项目的返工，导致项目延期，最终导致项目的终止。
一个有生命力的软件产品，必然要以真实用户的需求为依据，严谨的研发过程为保证，从用户中来，回到用户中去。
需求调研的过程是否可以裁减，我认为是可以的，只要需求是清晰、完整、准确的，并且研发团队与用户对需求的认知是一致的，在这样的条件下，需求调研过程是可以裁减的，但是建议项目团队出具需求文档，便于项目的传承交接。
在其他情况下，需求调研过程应该都是不可以裁减的，但可以根据条件选择适合的调研方式。
1.6需求调研启动时机
从软件研发阶段来看，项目立项后，软件产品范围和目标用户就确定了，产品人员就可以着手准备进行需求调研了。
2需求调研过程
2.1调研实施前活动
2.1.1识别调研范围
需求调研范围对需求调研过程影响重大，决定了需求调研对象、调研参与人员和调研周期的长短，清晰、准确的需求调研范围是调研活动获得成功的先决条件，在决定进行需求调研后，必须要尽快识别需求调研范围，确定调研内容。
调研范围从宏观上划分了调研内容边界，决定了本次调研的主要内容，可以依据产品范围和预期目标分析目标组织特征和业务特征,确定需求调研范围，划分清楚调研业务边界。
如果一次需求调研范围过大，则可能导致调研实施周期长，调研质量不稳定。
在这种情况下，项目管理者可以依据经验把调研范围划分成若干个业务域，识别其中关键的业务域，确定调研重点，便于调研过程的控制。
2.1.2组建调研团队
项目成功的一个重要前提条件就是有一个责权分明、强有力的执行团队。
根据项目需求调研工作要求，为及时有效沟通，更好的推进需求调研工作，组建调研团队，可以视项目大小和复杂程度确定人员要求和数量。
需求调研工作的参与方包括业务用户和调研实施人员：
1、业务用户：
由熟悉调研范围相关业务实际工作的用户组成，负责提出需求，评审需求结果,协助调研实施人员完成需求调研工作；
为保证需求调研的质量，需求调研应该选择尽可能多的用户进行调研，但是由于项目时间和成本上的原因，不可能对所有的用户都进行需求调研，所以要识别出能够确定需求和便于了解业务流程的用户作为每类用户的代表。
系统用户在很多方面存在着差异，例如：
知识技能、所处岗位（所进行的业务过程）、权限、地理上的布局以及个人的素质和喜好等等。
根据这些差异，你可以把这些不同的用户分成不同的用户类，从每类用户中选择具有代表性的部分用户作为调研对象。
每类用户户至少选择一位能真正代表他们需求的人作为代表并且能够作出决策，用户代表往往是本类用户中三类人：
对项目有决定权的领导、熟悉业务流程的专家、系统最终用户。
每一个用户代表者代表了一个特定的用户类，并在那个用户类和开发者之间充当主要的接口，用户代表从他们所代表的用户类中收集需求信息，同时每个用户代表又负责协调他们所代表的用户在需求表达上的不一致性和不兼容性。
用户类不一定都指人，也可以包括其他应用系统、接口或者硬件，这样做使得与系统边界外的接口也成为系统需求。
将用户群分类并归纳各自特点，并详细描述出它们的个性特点及任务状况，将有助于需求的获取和系统设计。
2、调研实施人员：
由熟悉调研业务领域人员组成，负责组织、协调和开展需求调研工作，记录调研内容，编写需求说明书。
调研实施人员是整个需求调研过程的执行者，通过调研实施人员按计划、按步骤的与用户沟通，收集调研范围需求，最终出具需求规格说明书。
调研实施人员的能力和活动对需求调研的进度、质量起着重大影响作用。
调研实施人员的组成应以互补为原则，至少由三类人组成：
技术人员、业务人员和管理者，根据需求调研范围选择能力与之相匹配的人员参与调研。
确定调研实施人员后，结合调研实施人员能力和调研内容，以充分发挥个人特长和利于需求调研为原则，确定调研实施人员角色，并结合调研范围进行分工。
3、需求调研管理人员：
负责需求调研工作的整体工作部署，重大业务、进度等事项的协调，调研进度和质量的控制。
2.1.3确定调研方案
在进行调研前，项目负责人要充分了解参与调研双方的基本情况，依调研对象的工作习惯、业务能力及调研人员能力、调研进度要求等因素选择调研方式。
2.1.3.1调研方式
主导型调研
参与调研的用户对调研范围业务领域内知识、经验不足，没有系统、完整的认识，在调研过程中需要充分发挥调研实施人员的“专家”作用，利用调研实施人员掌握的知识、经验整理需求概要内容，提交给用户进行分析和初步确认，最终由用户和调研实施人员对需求内容进行细化、确认的过程称之为主导型调研。
此种调研方式对调研实施人员能力要求高，调研实施人员可以根据项目时间要求自由安排进行调研，进度风险较低。
但是由于缺少业务用户的支持，需求质量往往依赖于调研实施人员的能力，导致需求结果与业务用户的真实意图可能存在偏差，给调研进度和需求质量带来风险。
采用主导型调研方式，调研实施人员不仅要求具备业务领域内知识和丰富经验，还要有良好的沟通协调能力，在调研过程中，要反复和业务用户进行沟通，对双发达成一致的需求必须由业务用户签字确认。
引导型调研
业务用户在调研业务领域内有较为完整、系统的知识、经验积累，在调研过程中，调研人员利用自身掌握的知识引导业务用户将需求阐述完整、清晰，最终由用户对需求进行确认的过程称之为引导型调研。
此种调研方式的调研过程业务用户和调研实施人员相互配合程度高，调研实施人员可以根据项目进度要求安排调研计划，按计划进行调研。
调研实施人员通过引导业务用户提出需求，利用自身的知识积累、职业判断、整理需求信息，由业务用户对需求进行确认，此种调研方式的进度和质量风险最小。
被动型调研
业务用户强势，且在调研领域内知识、经验丰富，对未来建设系统有较为清晰的认识，在调研过程中采取由业务用户主动说明、阐述需求，调研人员记录、分析需求的方式，或由业务用户按照调研实施人员要求出具需求的方式，称之为被动型调研；
此种调研方式对调研人员要求最低，但调研人员不能掌握调研进度，无法对收集到的需求质量进行判断，因而进度风险较大。
采用被动型调研方式，调研人员要提前做好调研提纲，把调研内容划分成若干个可独立调研的调研点，并按照调研提纲制定调研计划，按照调研计划进行调研，并在过程中加强监控，发现偏差尽快采取措施，降低进度偏差风险。
在调研过程中，把调研对象提出的需求与调研提纲进行比较，分析收集的需求是否全面，保证需求质量。
2.1.3.2调研策略
1、由粗到细，从宏观到微观，由外到内，逐步深入
需求调研是一项系统工程，调研过程是围绕业务需求展开的，调研收集的用户需求必须参照业务需求。
调研过程必须先从宏观上了解用户业务的整体概况，再逐步依序有计划的深入细节，在过程中不断修正对业务概况的理解，直至完成整个调研活动。
因为对于用户的业务而言，我们是外行，如果从业务细节着手，很容易迷失方向，失去对业务核心的把握。
同时要认识到，对于一个外行而言，我们对细节的理解也必定是有限的，不要指望自己能够无穷的、彻底的了解每一个细枝末节。
一是项目是有计划、有成本控制的，不可能有无限的时间给你了解，二是用户作为业务领域专家，对业务有很好的理解，作为调研实施人员也没有必要熟悉每个细节，因为未来的系统也不可能完全包办所有业务的细节，还有很多事情是要靠用户企业中这些具有专业技能的人来做的。
2、从不同层次的用户代表那里收集不同层次的需求
不同层次的用户由于工作内容、擅长业务等的差异，造成不同层次用户往往对同一业务有着不同层次的需求。
作为调研人员，我们要明确知道哪类需求应该从哪个层次的用户获取，并在调研过程中检查需求调研对象的层次和获取需求的层次是否一致。
通过由上到下的逐级访谈，对未来系统的描述就从一个大黑箱变成多个小黑箱，再变成透明、明确、详细的系统定义的过程。
通过调研企业高层决策者，更多的是了解系统预期目标、功能蓝图；通过调研业务操作人员，可以收集业务细节和操作细节。
3、以业务领域为主线，搞清楚每个业务的环节流程关系
1）按照调研内容的关联程度和特征，把调研内容划分成若干个调研主题，先理清楚每个主题的目标以及和其他主题发生的关系；
2）理清楚每个主题内部存在的活动以及和其他主题之间发生的活动，并划分清楚每个活动的边界；
3）针对每个活动进行调研，弄清楚每个活动的流程环节和内容。
2.1.3.3调研方法
需求调研方法一般有实地观察法、面谈法、问卷调查法、查阅资料等方法。
1、实地观察法
不和调研对象进行正面接触，而是在旁边对具体业务进行观察，参观调研对象的工作流程，观察调研对象的操作。
根据观察收集到的信息，进行整理和分析，出具需求规格说明书。
2、面谈法
与调研对象进行面对面交谈，由调研对象描述业务信息和需求信息，调研人员向调研对象提出事先准备好的问题，并记录访谈过程。
经过对访谈过程记录的整理和分析出具需求规格说明书。
3、问卷调查法
调研人员根据调研内容将相关问题制成问卷表格，向调研对象发放调研问卷，调研对象根据实际业务填写问卷表格，调研人员按时回收问卷表格。
调研人员根据收集到调研问卷进行整理和分析，获取需求，出具需求规格说明书。
4、查阅资料法
收集调研对象在调研范围内相关的规章制度、规范指南、工作过程产出等书面资料，并对收集到的资料进行整理和分析，获取需求的方式。
对于需求调研来说，访问调查宜采用直接面谈，并且使用非标准化的方式，这样便于发挥和沟通，通过调研过程的互动，可以激发调研对象积极性，收获调研实施前遗漏的需求；问卷调查法是标准化调查，可作为一种辅助手段，对于较为复杂的信息系统调研，不建议问卷调查作为唯一调研方法；而实地观察法和查阅资料法，作为由调研人员主动实施的调研方法，依赖于调研人员的主观判断，有一定局限性，可作为一种辅助手段对收集需求进行判断。
几种常用调研方法比较表：
调研方法
调研周期
调研成本
人员要求
调研效果
实地观察法
长
次高
次高
中
面谈法
次长
高
低
优
问卷调查法
中
中
中
良
查阅资料法
短
低
高
差
2.1.4调研准备
为确保调研工作的顺利开展，在调研实施开始前，应安排一系列支持性工作，加强团队管理和建设，保障调研工作的顺利进行。
1、编制需求调研计划
需求调研过程是项目的一个阶段，需求调研计划是项目计划的一个组成部分。
在需求调研范围、调研团队确定后，调研负责人预估工作量，编制调研计划。
通常来说，需求调研过程是非标准化的过程，在调研的过程中围绕主题进行发散性的探讨，编制需求调研计划，任务的粒度一般只需到业务块，由调研人员把握具体进度，调研人员可以视调研过程的实际情况在“大”计划指导下灵活调整细节计划。
2、编制调研活动使用的文档模版
调研活动的主要成果是记载需求的一系列文档，为便于文档的理解和后期整理、使用，软件需求应使用统一的模版，并按照一致的规范编写，调研过程使用的文档模版主要包括调研记录模版、用户需求说明书模版、软件需求说明书模版等。
编写规范和模版确定后，在调研组内进行推广、培训。
3、准备调研过程使用的工具，并分发给参与调研人员，如word、excel、visio
等。
4、制作调研提纲
为确保调研质量，在调研活动实施前，调研人员应根据调研范围编制调研提纲。
调研提纲至少应包括如下几个方面：
1）调研对象的基本情况
2）调研对象的预期目标1
3）调研业务的功能需求
4）调研业务的非功能需求
调研提纲是贯穿于整个调研活动，在调研实施过程中，调研人员可以根据调研提纲引导用户提出需求，检查用户提出需求是否完整；调研结束前，调研提纲是判断调研是否完成的一个重要依据，调研提纲所有内容都已经收集到相关用户需求，调研活动可以宣告完成。
5、调研背景培训
向调研人员介绍本项目的主要目标、项目范围和重点工作，避免在需求调研过程中业务人员所提需求超出范围，抓不住重点；介绍调研对象基本情况，包括调研对象目前总体状况、主要业务、组织机构和关键人物等；
培训调研对象的行业知识，学习调研对象使用的术语，标准，以便能够准确的理解用户的需求，提高调研人员的行业知识面；
2.1.5前期沟通
在调研实施前的准备工作基本就绪，调研工作实施前，由调研工作负责人将调研工作计划、团队及分工等信息告知业务用户，便于业务用户进行调研的相关准备工作。
2.2调研实施
2.2.1调研实施
一、倾听、记录需求
以用户为主，面对面的进行沟通和交流，完全倾听用户的心声，调研实施随时记录用户所说的一切有用信息，并使用调研记录模版格式记录下自己的认识和问题。
用户完成某一主题的表述后，调研人员复述自己记录的需求内容，在复述的同时可以结合自己的认识和记录的问题发表建议，使得记录的需求条理化、合理化。
调研内容应至少包括以下内容：
1.用户和本行业业务现状及存在问题；
2.调研对象涵盖业务的组织机构及对应职责和权限；
3.调研对象主要业务及业务的大概流程，每个业务的流程流经哪些部门，
业务如何在部门之间流转；
4.调研对象解决问题、改变现状的需求内容。
5.调研业务未来发展趋势是怎样的
6.非功能方面的需求
调研记录是调研人员在调研过程中记录下调研对象的意思表述，是需求最为原始的记录，是进行需求分析、总结的唯一依据。
调研记录的质量高低直接决定了需求质量的好坏，写好调研记录不仅要求调研人员如实记录调研对象的真实意图，还需要根据自己的理解将用户繁琐、含糊不清的语言转换为言简意赅的语句。
调研记录应至少包括业务流程、工作方法和具体内容，推荐使用4W1H的方式编写调研记录，4W即“What、Who、When、Why”,1H即“How”。
What
需求是要做什么，实现什么目标通过把调研内容划分成若干领域，逐步弄清各个领域的工作流程和工作内容。
处理过程中涉及了哪些部门、人或岗位，业务过程会有哪些相关者
在什么时间或什么条件下发生，如果是周期性构成，周期有多长
为什么会产生这个需求，需求的
升级会员 