获取工程项目需求的几种方法及其适用环境

1、获取工程项目需求的几种方法及其适用环境 俗话说，“良好的开端是成功的一半”。需求获取作为项目伊始的活动，是特别重要的。我们知道，需求调研不充分、用户需求描述不完整不精确，轻则影响项目建设的顺当程度，重则影响应用系统的质量，甚至打算项目的成败。 目前我们所开发的软件项目一般有两种类型：产品项目和工程项目。产品项目一般都会有充分的时间进行特别认真的需求调研和分析，而工程项目却并非如此（因为它往往受诸多因素的影响）。 本文拟争论如何依据工程项目管理的实际特点，采用合适的方法低成本高效率地获取用户的需求。 产品项目一般是依据公司战略和市场需求研发的旨在进行批量出售或推广的项目，工程项目一般是依据与用户

2、签定的合同研发的旨在满意特定用户需求的项目。笔者所开发和管理的项目主要是工程项目，在项目的建设过程中，感觉到最头疼的是项目需求的获取；我们往往要花相当大的精力在需求获取和需求确认上，然而有时效果还很不抱负。经过几年时间的项目实践，我们逐步总结出针对不同项目状况所适合采用的需求获取方法，这些方法能大大提高需求获取的效率。现总结之，愿与大家共享。 我们知道，一个工程项目，假如从开发方（即承建方）和用户方（即建设方）对需求的清晰程度来分，大致可以分为如下四种：开发方和用户方都清晰项目需求、开发方不清晰项目需求但用户方清晰、开发方和用户方都不清晰项目需求、开发方清晰项目需求但用户方不清晰。 针对这四种

3、类型的项目，我总结出四种对应的需求获取方法：会议争论法、问卷调查法、界面原型法和可运行原型系统法。 一、会议争论法 所谓“会议争论法”，是指开发方和用户方召开若干次需求争论会议，达到彻底弄清项目需求的一种需求获取方法。 这种方法适合于开发方不清晰项目需求（一般开发方是刚开头做这种业务类型的工程项目）但用户方清晰项目需求的状况。因为用户清晰项目的需求，则用户能精确地表达出他们的需求，而开发方有专业的软件开发经验，对用户供应的需求一般都能精确地描述和把握。 这种方法的一般操作步骤是： 步骤一、开发方依据双方制定的需求调研计划召开相关需求主题沟通会； 步骤二、会后开发方整理出需求调研记录提交给用户方

4、确认； 步骤三、假如此主题还有未明确的问题则再次沟通，否则开头下一主题； 步骤四、全部需求都沟通清晰后，开发方依据历次需求调研记录整理出用户需求说明书，提交给用户方确认签字。 由于开发方不清晰项目需求，因此需要花较多的时间和精力进行需求调研和需求整理工作。 二、问卷调查法 所谓“问卷调查法”，是指开发方就用户需求中的一些个性化的、需要进一步明确的需求（或问题），通过采用向用户发问卷调查表的方式，达到彻底弄清项目需求的一种需求获取方法。 这种方法适合于开发方和用户方都清晰项目需求的状况。因为开发方和建设方都清晰项目的需求，则需要双方进一步沟通的需求（或问题）就比较少，通过采用这种简洁的问卷调查方

5、法就能使问题得到较好的解决。 这种方法的一般操作步骤是： 步骤一、开发方先依据合同和以往类似项目的经验，整理出一份用户需求说明书和待澄清需求（或问题）的问卷调查表提交给用户； 步骤二、用户阅读用户需求说明书，并回答问卷调查表中提出的问题，假如用户需求说明书中有描述不正确或未包括的需求，用户可一并修改或补充； 步骤三、开发方拿到用户返回的用户 需求说明书和问卷调查表进行分析，如仍旧有问题，则重复步骤二，否则执行步骤四； 步骤四、开发方整理出用户需求说明书，提交给用户方确认签字。 由于这种方法比较简洁、侧重点明确，因此能大大缩短需求获取的时间、削减需求获取的成本、提交工作效率。 三、界面原型法 所

6、谓“界面原型法”，是指开发方依据自己所了解的用户需求，描画出应用系统的功能界面后与用户进行交流和沟通，通过“界面原型”这一载体，达到双方逐步明确项目需求的一种需求获取的方法。 这种方法比较适合于开发方和用户方都不清晰项目需求的状况。因为开发方和用户方都不清晰项目需求，因此此时就更需要借助于一定的“载体”来加快对需求的挖掘和双方对需求理解。这种状况下，采用“可视化”的界面原型法比较可取。 这种方法的一般操作步骤是： 步骤一、开发方依据其所了解到的需求（如通过合同或与用户交流），采用界面制作工作描画出应用系统的功能界面； 步骤二、将应用系统的功能界面提交给用户并与用户沟通，挖掘出新需求或就需求达成

7、理解上的全都； 步骤三、开发方就不断获取的需求进行增量式整理，依据新的需求丰富和细化界面原型； 步骤四、双方经过多次界面原型的交互，开发方最终整理出用户需求说明书，提交给用户方确认签字。 由于开发方和用户方都不清晰项目需求，因此此时需求获取工作将会比较困难，可能导致的风险也比较大。采用这种“界面原型”的方式，能加速项目需求的“出现”和双方对需求的全都理解，从而减小由于需求问题可能给项目带来的风险。 针对这种类型的项目，我们也可以采用下面将要介绍的“可运行原型系统法”，但由于开发方对需求不了解（证明以前缺乏类似项目的开发经验和产品积累），假如开发一个可运行的原型系统，则几乎需要从零开头编写代码，

8、前期投入会很大。 四、可运行原型系统法 所谓“可运行原型系统法”，是指开发方依据合同中规定的基本需求，在以往类似项目应用系统的基础上进行少量修改得出一可运行系统，通过“可运行原型系统”这一载体，达到彻底挖掘项目需求的一种需求获取的方法。这种方法比较适合于开发方清晰项目需求但用户方不清晰项目需求的状况。 这种类型的项目，开发方一般都有类似项目的建设经验，因此可以在以往项目的基础上，快速“构建”出一可运行系统，然后借助于这一“载体”来加快对需求的挖掘和双方（特殊是用户方）对需求的理解。这种状况下，采用“所见即所得”的可运行原型系统法比较可取。 这种方法的一般操作步骤是： 步骤一、开发方依据其所了解

9、到的需求（如通过合同或与用户交流），在以往类似项目的基础上，快速“构建”出一可运行系统； 步骤二、通过向用户演示“可运行原型系统”，逐步挖掘并让用户确认项目需求； 步骤三、开发方就不断获取的需求进行增量式整理，依据新的需求丰富可运行原型系统； 步骤四、双方经过多次可运行原型系统的交互，开发方最终整理出用户需求说明书，提交给用户方确认签字。 由于开发方清晰用户的需求（证明以前有类似项目的开发经验和产品积累），但用户方自己不清晰，因此此时开发一个“可运行原型系统”，开发方的投入不会很大，但对于用户理解和确认项目需求特别有利，因此针对这种类型的项目这是一种比较抱负的需求获取方式。 这种方法的另一个好处是：正式系统一般可以在该“可运行原型系统”的基础上演化