工程项目中需求获取方法
在工程项目的建设过程中，我们通常感觉到最头疼的就是项目需求的获取，我们往往花费相当大的精力在需求获取和需求确认上，然而效果还很不理想。经过几年项目实践和锻炼，逐步总结出针对不同项目情况所适合采用的需求获取方法，这些方法能大大提高需求获取的效率。希望与大家分享。
我们知道，一个项目，如果从建设方和使用方对需求的清楚程度来分，大致可以分为如下四种：建设方和使用方都清楚项目需求；建设方不清楚项目需求但使用方清楚；建设方和使用方都不清楚项目需求；建设方清楚项目需求但使用方不清楚。我们目前建设的项目基本都囊括了以上四种情况，但是我们项目大多数情况是使用方和建设方都是同一用户，目前的项目建设中也出现了中国联通的其他部门提相关需求，由网管中心来建设。
针对这四种类型的项目，总结出四种对应的需求获取方法：问卷调查法、会议讨论法、界面原型法和demo版系统法。
一、问卷调查法
所谓“问卷调查法”，是指我们方就用户需求中的一些个性化的、需要进一步明确的需求（或问题），通过采用向用户发问卷调查表的方式，达到彻底弄清项目需求的一种需求获取方法。
这种方法适合于我们和建设方、使用方都清楚项目需求的情况。因为建设方和使用方都清楚项目的需求，需要双方进一步沟通的需求（或问题）就比较少，通过采用这种简单的问卷调查方法就能使问题得到较好的解决。
这种方法的一般操作步骤是：
1. 我们先根据合同和以往类似项目的经验，整理出一份《用户需求说明书》和相关业务层面的《问卷调查表》提交给用户；
2. 用户阅读《用户需求说明书》，并回答《问卷调查表》中提出的问题，如果《用户需求说明书》中有描述不正确或未包括的需求，用户可一并修改或补充；
3. 我们拿到用户返回的《用户需求说明书》和《问卷调查表》进行分析，如仍然有问题，则重复步骤2，否则执行步骤4；
4. 经过我方和承建方、使用方反复交流沟通，最后整理出《用户需求说明书》，提交给用户（此处的用户可以是建设方、也可以是使用方）确认签字。
由于这种方法比较简单、侧重点明确，因此能大大缩短需求获取的时间、减少需求获取的成本、提高工作效率。
二、会议讨论法
所谓“会议讨论法”，是指我方和用户相关人员（包括建设方和使用方）方召开若干次需求讨论会议，达到彻底弄清项目需求的一种需求获取方法。
这种方法适合于我方不清楚用户的详细业务需求，但使用方清楚项目需求的情况（比如重庆的网优项目）。因为使用方清楚项目的需求，他们能准确地表达出他们的需求，而我们有专业的软件开发经验，经过会议讨论交流之后，能够对用户的需求进行准确描述和把握。
这种方法的一般操作步骤是：
1. 我方先制定《需求调研计划》，然后和建设方以及使用方交流《需求调研计划》，最后根据需求调研计划召开相关需求主题沟通会；
2. 会后我方整理出《需求调研记录》提交给用户确认；
3. 如果此主题还有未明确的问题则再次沟通，否则开始下一主题；
4. 所有需求都沟通清楚后，我方根据历次《需求调研记录》整理出《用户需求说明书》，提交给使用方确认签字。
由于我方不清楚项目明确业务流程和相关需求，因此需要花较多的时间和精力进行需求调研和需求整理工作。
三、界面原型法
所谓“界面原型法”，是指我方根据自己所了解的用户需求，描画出应用系统的功能界面后与用户进行交流和沟通，通过“界面原型”这一载体，达到双方逐步明确项目需求的一种需求获取的方法。
这种方法比较适合于我方和用户都不是非常清楚项目需求、只是大概了解用户需求的情况。因为我方和用户方都不能非常准确的描述出客户的需求，因此此时就更需要借助于一定的“载体”来加快对需求的挖掘和双方对需求理解。这种情况下，采用“可视化”的界面原型法比较可取。
这种方法的一般操作步骤是：
1. 我方根据其所了解到的需求（如通过合同或与用户交流），采用界面制作工作描画出应用系统的功能界面；
2. 将应用系统的功能界面提交给用户并与用户沟通，挖掘出新需求或就需求达成理解上的一致；
3. 我方就不断获取的需求进行增量式整理，根据新的需求丰富和细化界面原型；
4. 双方经过多次界面原型的交互，建设方最终整理出《用户需求说明书》，提交给使用方确认签字。
由于我方和用户都不清楚项目需求，因此此时需求获取工作将会比较困难，可能导致的风险也比较大。采用这种“界面原型”的方式，能加速项目需求的“浮现”和双方对需求的一致理解，从而减小由于需求问题可能给项目带来的风险。
四、demo版系统法
所谓“demo版系统法”，是指我方根据合同中规定的基本需求，在以往类似项目应用系统的基础上进行少量修改得出一可运行系统，通过“可运行原型系统”这一载体，达到彻底挖掘项目需求的一种需求获取的方法。
这种方法比较适合于我方清楚项目需求但用户不清楚项目需求的情况。这种类型的项目，我方一般都有类似项目的建设经验，因此可以在以往项目的基础上，快速“构建”出一可运行系统，然后借助于这一“载体”来加快对需求的挖掘和双方（特别是使用方）对需求的理解。这种情况下，采用demo版运行系统法比较可取。
这种方法的一般操作步骤是：
1. 我方根据其所了解到的需求（如通过合同或与用户交流），在以往类似项目的基础上，快速“构建”出一可运行系统；
2. 通过向用户演示“可运行原型系统”，逐步挖掘并让用户确认项目需求；
3. 我方就不断获取的需求进行增量式整理，根据新的需求丰富可运行原型系统；
4. 双方经过多次可运行原型系统的交互，我方最终整理出《用户需求说明书》，提交给用户确认签字。
由于我方清楚用户的需求（以前有类似项目的开发经验和产品积累），但用户自己描述不清楚，因此此时开发一个“deom系统”，我方的投入不会很大，但对于用户理解和确认项目需求非常有利，因此针对这种类型的项目这是一种比较理想的需求获取方式。
这种方法的另一个好处是：正式系统一般可以在该“可运行原型系统”的基础上演化而成，为后续开发工作节省不少的工作量和成本。
值得注意的是，以上总结出的这四种需求获取方法不是互斥的，我们可以根据项目的实际特点独立应用或组合应用。
以上是我在以往的项目实施中总结的，希望我的方法能够给我们的需求调研人员有一个良好的指引。有良好的方法，相信我们的项目开展达到了“事半功倍”的作用。
我们知道，一个项目，如果从建设方和使用方对需求的清楚程度来分，大致可以分为如下四种：建设方和使用方都清楚项目需求；建设方不清楚项目需求但使用方清楚；建设方和使用方都不清楚项目需求；建设方清楚项目需求但使用方不清楚。我们目前建设的项目基本都囊括了以上四种情况，但是我们项目大多数情况是使用方和建设方都是同一用户，目前的项目建设中也出现了中国联通的其他部门提相关需求，由网管中心来建设。
针对这四种类型的项目，总结出四种对应的需求获取方法：问卷调查法、会议讨论法、界面原型法和demo版系统法。
一、问卷调查法
所谓“问卷调查法”，是指我们方就用户需求中的一些个性化的、需要进一步明确的需求（或问题），通过采用向用户发问卷调查表的方式，达到彻底弄清项目需求的一种需求获取方法。
这种方法适合于我们和建设方、使用方都清楚项目需求的情况。因为建设方和使用方都清楚项目的需求，需要双方进一步沟通的需求（或问题）就比较少，通过采用这种简单的问卷调查方法就能使问题得到较好的解决。
这种方法的一般操作步骤是：
1. 我们先根据合同和以往类似项目的经验，整理出一份《用户需求说明书》和相关业务层面的《问卷调查表》提交给用户；
2. 用户阅读《用户需求说明书》，并回答《问卷调查表》中提出的问题，如果《用户需求说明书》中有描述不正确或未包括的需求，用户可一并修改或补充；
3. 我们拿到用户返回的《用户需求说明书》和《问卷调查表》进行分析，如仍然有问题，则重复步骤2，否则执行步骤4；
4. 经过我方和承建方、使用方反复交流沟通，最后整理出《用户需求说明书》，提交给用户（此处的用户可以是建设方、也可以是使用方）确认签字。
由于这种方法比较简单、侧重点明确，因此能大大缩短需求获取的时间、减少需求获取的成本、提高工作效率。
二、会议讨论法
所谓“会议讨论法”，是指我方和用户相关人员（包括建设方和使用方）方召开若干次需求讨论会议，达到彻底弄清项目需求的一种需求获取方法。
这种方法适合于我方不清楚用户的详细业务需求，但使用方清楚项目需求的情况（比如重庆的网优项目）。因为使用方清楚项目的需求，他们能准确地表达出他们的需求，而我们有专业的软件开发经验，经过会议讨论交流之后，能够对用户的需求进行准确描述和把握。
这种方法的一般操作步骤是：
1. 我方先制定《需求调研计划》，然后和建设方以及使用方交流《需求调研计划》，最后根据需求调研计划召开相关需求主题沟通会；
2. 会后我方整理出《需求调研记录》提交给用户确认；
3. 如果此主题还有未明确的问题则再次沟通，否则开始下一主题；
4. 所有需求都沟通清楚后，我方根据历次《需求调研记录》整理出《用户需求说明书》，提交给使用方确认签字。
由于我方不清楚项目明确业务流程和相关需求，因此需要花较多的时间和精力进行需求调研和需求整理工作。
三、界面原型法
所谓“界面原型法”，是指我方根据自己所了解的用户需求，描画出应用系统的功能界面后与用户进行交流和沟通，通过“界面原型”这一载体，达到双方逐步明确项目需求的一种需求获取的方法。
这种方法比较适合于我方和用户都不是非常清楚项目需求、只是大概了解用户需求的情况。因为我方和用户方都不能非常准确的描述出客户的需求，因此此时就更需要借助于一定的“载体”来加快对需求的挖掘和双方对需求理解。这种情况下，采用“可视化”的界面原型法比较可取。
这种方法的一般操作步骤是：
1. 我方根据其所了解到的需求（如通过合同或与用户交流），采用界面制作工作描画出应用系统的功能界面；
2. 将应用系统的功能界面提交给用户并与用户沟通，挖掘出新需求或就需求达成理解上的一致；
3. 我方就不断获取的需求进行增量式整理，根据新的需求丰富和细化界面原型；
4. 双方经过多次界面原型的交互，建设方最终整理出《用户需求说明书》，提交给使用方确认签字。
由于我方和用户都不清楚项目需求，因此此时需求获取工作将会比较困难，可能导致的风险也比较大。采用这种“界面原型”的方式，能加速项目需求的“浮现”和双方对需求的一致理解，从而减小由于需求问题可能给项目带来的风险。
四、demo版系统法
所谓“demo版系统法”，是指我方根据合同中规定的基本需求，在以往类似项目应用系统的基础上进行少量修改得出一可运行系统，通过“可运行原型系统”这一载体，达到彻底挖掘项目需求的一种需求获取的方法。
这种方法比较适合于我方清楚项目需求但用户不清楚项目需求的情况。这种类型的项目，我方一般都有类似项目的建设经验，因此可以在以往项目的基础上，快速“构建”出一可运行系统，然后借助于这一“载体”来加快对需求的挖掘和双方（特别是使用方）对需求的理解。这种情况下，采用demo版运行系统法比较可取。
这种方法的一般操作步骤是：
1. 我方根据其所了解到的需求（如通过合同或与用户交流），在以往类似项目的基础上，快速“构建”出一可运行系统；
2. 通过向用户演示“可运行原型系统”，逐步挖掘并让用户确认项目需求；
3. 我方就不断获取的需求进行增量式整理，根据新的需求丰富可运行原型系统；
4. 双方经过多次可运行原型系统的交互，我方最终整理出《用户需求说明书》，提交给用户确认签字。
由于我方清楚用户的需求（以前有类似项目的开发经验和产品积累），但用户自己描述不清楚，因此此时开发一个“deom系统”，我方的投入不会很大，但对于用户理解和确认项目需求非常有利，因此针对这种类型的项目这是一种比较理想的需求获取方式。
这种方法的另一个好处是：正式系统一般可以在该“可运行原型系统”的基础上演化而成，为后续开发工作节省不少的工作量和成本。
值得注意的是，以上总结出的这四种需求获取方法不是互斥的，我们可以根据项目的实际特点独立应用或组合应用。
以上是我在以往的项目实施中总结的，希望我的方法能够给我们的需求调研人员有一个良好的指引。有良好的方法，相信我们的项目开展达到了“事半功倍”的作用。