需求获取的方法.docx

需求获取的方法.docx

《需求获取的方法.docx》由会员分享，可在线阅读，更多相关《需求获取的方法.docx（7页珍藏版）》请在冰豆网上搜索。

需求获取的方法

需求获取的方法

需求获取技术

　　需求获取的目的：

（1）清楚地理解所要解决的问题；

（2）完整地获取用户需求。

　　需求获取面临的挑战：

问题的复杂性和问题空间；理解的不完备性与不一致性；交流障碍；需求易变性。

　　所以，分析人员必须掌握一些基本技术，包括初步需求获取技术、需求建模、问题抽象与问题分解快速原型技术。

需求获取技术包括两方面的工作：

建立获取用户需求的方法的框架；支持和监控需求获取的过程的机制。

　　一、需求获取的常用方法

　　1.组织人员　　

　　组织人员，建立分析小组，其中包括领域专家：

主角，也就是用户方面的问题专家，了解软件所解决问题的领域知识。

系统分析员：

导演，软件开发人员方面的人，其主要分析，抽象领域专家的知识，形成软件模型。

　　2.客户访谈

　　客户访谈，也就是获取用户需求，其主要方法是调查研究。

其主要内容包括：

（1）了解系统的需求。

软件开发常常是系统开发的一部分。

仔细分析研究系统的需求规格说明，对软件的需求获取是很有必要的。

（2）市场调查。

了解市场对待开发软件有什么样的要求；了解市场上有无与待开发软件类似的系统。

如果有，在功能上、性能上、价格上情况如何。

　　（3）访问用户和用户领域的专家。

把从用户那里得到的信息作为重要的原始资料进行分析；访问用户领域的专家所得到的信息将有助于对用户需求的理解。

　　（4）考察现场。

了解用户实际的操作环境、操作过程和操作要求。

对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。

　　在做调查研究时，可以采取如下的调查方式：

　　·制定调查提纲，向不同层次的用户发调查表。

　　·按用户的不同层次，分别召开调查会，了解用户对待开发系统的想法和建议。

　　·向用户领域的专家或在关键岗位上工作的人个别咨询。

　　·实地考察，跟踪现场业务流程。

　　·查阅与待开发系统有关的资料。

　　·使用各种调查工具，如数据流图、任务分解图、网络图等。

　　为了能够有效地获取和理清用户需求，应当打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，协同工作。

　　3.问题分析与确认

　　问题分析与确认，主要组织分析并评审，最终确定问题是否比较完整。

　　二、需求获取的内容

　　需求分析目标主要搞清楚软件用户要“做什么”，其用户需求内容主要是两方面：

一是功能性需求：

定义了系统做什么（描述系统必须支持的功能和过程）；二是非功能性需求（技术需求）：

定义了系统工作时的特性（描述操作环境和性能目标）；

　　两类需求包括的内容：

功能；性能；环境；界面；用户或人的因素；文档；数据；资源；安全保密；软件成本消耗与开发进度；质量保证。

下面分别对其作一定解释：

（1）功能需求：

系统做什么？

系统何时做什么？

系统何时及如何修改或升级？

（2）性能需求：

软件开发的技术性指标：

例如：

存储容量限制；执行速度、相应时间、吞吐量。

　　（3）环境需求：

硬件设备：

机型、外设、接口、地点、分布、温度、湿度、磁场干扰等;软件操作系统；网络；数据库。

　　（4）界面需求：

有来自其他系统的输入吗？

到自其他系统的输出吗？

对数据格式有规定吗？

对数据存储介质有规定吗？

　　（5）用户或人的因素：

用户类型？

各种用户熟练程度？

需受何种训练？

用户理解、使用系统的难度？

用户错误操作系统的可能性？

　　（6）文档需求：

需哪些文档？

文档针对哪些读者？

　　（7）数据需求：

输入、输出数据的格式？

接收、发送数据的频率？

数据的准确性和精度？

数据流量？

数据需保持的时间？

　　（8）资源需求：

软件运行时所需的数据、软件。

内存空间等资源。

软件开发、维护所需的人力、支撑软件、开发设备等。

　　（9）安全保密要求：

需对访问系统或系统信息加以控制吗？

如何隔离用户之间的数据？

用户程序如何与其他程序和操作系统隔离？

系统备份要求？

　　（10）软件成本消耗与开发进度需求：

开发有规定的时间表吗？

软硬件投资有无限制？

　　（11）质量保证：

系统的可靠性要求？

系统必须监测和隔离错误吗？

规定系统平均出错时间？

出错后，重启系统允许的时间？

系统变化如何反映到设计中？

维护是否包括对系统的改进？

系统的可移植性？

摘要：

我们知道，需求调研不充分、用户需求描述不完整不准确，轻则影响项目建设的顺利程度，重则影响应用系统的质量，甚至决定项目的成败。

　　俗话说，“良好的开端是成功的一半”。

需求获取作为项目伊始的活动，是非常重要的。

　　目前我们所开发的软件项目一般有两种类型：

产品项目和工程项目。

　　产品项目一般都会有充足的时间进行非常仔细的需求调研和分析，而工程项目却并非如此（因为它往往受诸多因素的影响）。

　　本文拟讨论如何根据工程项目的实际特点，采用合适的方法低成本高效率地获取用户的需求。

　　关键词：

工程项目需求获取方法

　　产品项目一般是根据公司战略和市场需求研发的旨在进行批量出售或推广的项目，工程项目一般是根据与用户签定的合同研发的旨在满足特定用户需求的项目。

　　笔者所开发和管理的项目主要是工程项目，在项目的建设过程中，感觉到最头疼的是项目需求的获取；我们往往要花相当大的精力在需求获取和需求确认上，然而有时效果还很不理想。

　　经过几年时间的项目实践，我们逐步总结出针对不同项目情况所适合采用的需求获取方法，这些方法能大大提高需求获取的效率。

现总结之，愿与大家分享。

　　我们知道，一个工程项目，如果从开发方（即承建方）和用户方（即建设方）对需求的清楚程度来分，大致可以分为如下四种：

开发方和用户方都清楚项目需求、开发方不清楚项目需求但用户方清楚、开发方和用户方都不清楚项目需求、开发方清楚项目需求但用户方不清楚。

　　针对这四种类型的项目，我总结出四种对应的需求获取方法：

问卷调查法、会议讨论法、界面原型法和可运行原型系统法。

　　以下逐一解析之

　　一、问卷调查法

       所谓“问卷调查法”，是指开发方就用户需求中的一些个性化的、需要进一步明确的需求（或问题），通过采用向用户发问卷调查表的方式，达到彻底弄清项目需求的一种需求获取方法。

　　这种方法适合于开发方和用户方都清楚项目需求的情况。

因为开发方和建设方都清楚项目的需求，则需要双方进一步沟通的需求（或问题）就比较少，通过采用这种简单的问卷调查方法就能使问题得到较好的解决。

　　这种方法的一般操作步骤是：

　　步骤一、开发方先根据合同和以往类似项目的经验，整理出一份《用户需求说明书》和待澄清需求（或问题）的《问卷调查表》提交给用户；

　　步骤二、用户阅读《用户需求说明书》，并回答《问卷调查表》中提出的问题，如果《用户需求说明书》中有描述不正确或未包括的需求，用户可一并修改或补充；

　　步骤三、开发方拿到用户返回的《用户需求说明书》和《问卷调查表》进行分析，如仍然有问题，则重复步骤二，否则执行步骤四

　　步骤四、开发方整理出《用户需求说明书》，提交给用户方确认签字。

　　由于这种方法比较简单、侧重点明确，因此能大大缩短需求获取的时间、减少需求获取的成本、提交工作效率。

二、会议讨论

　　所谓“会议讨论法”，是指开发方和用户方召开若干次需求讨论会议，达到彻底弄清项目需求的一种需求获取方法。

　　这种方法适合于开发方不清楚项目需求（一般开发方是刚开始做这种业务类型的工程项目）但用户方清楚项目需求的情况。

因为用户清楚项目的需求，则用户能准确地表达出他们的需求，而开发方有专业的软件开发经验，对用户提供的需求一般都能准确地描述和把握。

　　这种方法的一般操作步骤是：

　　步骤一、开发方根据双方制定的《需求调研计划》召开相关需求主题沟通会；

　　步骤二、会后开发方整理出《需求调研记录》提交给用户方确认；

　　步骤三、如果此主题还有未明确的问题则再次沟通，否则开始下一主题；

　　步骤四、所有需求都沟通清楚后，开发方根据历次《需求调研记录》整理出《用户需求说明书》，提交给用户方确认签字。

　　由于开发方不清楚项目需求，因此需要花较多的时间和精力进行需求调研和需求整理工作。

　　三、界面原型法

　　所谓“界面原型法”，是指开发方根据自己所了解的用户需求，描画出应用系统的功能界面后与用户进行交流和沟通，通过“界面原型”这一载体，达到双方逐步明确项目需求的一种需求获取的方法。

　　这种方法比较适合于开发方和用户方都不清楚项目需求的情况。

因为开发方和用户方都不清楚项目需求，因此此时就更需要借助于一定的“载体”来加快对需求的挖掘和双方对需求理解。

这种情况下，采用“可视化”的界面原型法比较可取。

　　这种方法的一般操作步骤是：

　　步骤一、开发方根据其所了解到的需求（如通过合同或与用户交流），采用界面制作工作描画出应用系统的功能界面；

　　步骤二、将应用系统的功能界面提交给用户并与用户沟通，挖掘出新需求或就需求达成理解上的一致；

　　步骤三、开发方就不断获取的需求进行增量式整理，根据新的需求丰富和细化界面原型；

　　步骤四、双方经过多次界面原型的交互，开发方最终整理出《用户需求说明书》，提交给用户方确认签字。

　　由于开发方和用户方都不清楚项目需求，因此此时需求获取工作将会比较困难，可能导致的风险也比较大。

采用这种“界面原型”的方式，能加速项目需求的“浮现”和双方对需求的一致理解，从而减小由于需求问题可能给项目带来的风险。

　　针对这种类型的项目，我们也可以采用下面将要介绍的“可运行原型系统法”，但由于开发方对需求不了解（证明以前缺乏类似项目的开发经验和产品积累），如果开发一个可运行的原型系统，则几乎需要从零开始编写代码，前期投入会很大。

　　四、可运行原型系统法

　　所谓“可运行原型系统法”，是指开发方根据合同中规定的基本需求，在以往类似项目应用系统的基础上进行少量修改得出一可运行系统，通过“可运行原型系统”这一载体，达到彻底挖掘项目需求的一种需求获取的方法。

　　这种方法比较适合于开发方清楚项目需求但用户方不清楚项目需求的情况。

这种类型的项目，开发方一般都有类似项目的建设经验，因此可以在以往项目的基础上，快速“构建”出一可运行系统，然后借助于这一“载体”来加快对需求的挖掘和双方（特别是用户方）对需求的理解。

这种情况下，采用“所见即所得”的可运行原型系统法比较可取。

　　这种方法的一般操作步骤是：

　　步骤一、开发方根据其所了解到的需求（如通过合同或与用户交流），在以往类似项目的基础上，快速“构建”出一可运行系统；

　　步骤二、通过向用户演示“可运行原型系统”，逐步挖掘并让用户确认项目需求；

　　步骤三、开发方就不断获取的需求进行增量式整理，根据新的需求丰富可运行原型系统；　

　　步骤四、双方经过多次可运行原型系统的交互，开发方最终整理出《用户需求说明书》，提交给用户方确认签字。

　　由于开发方清楚用户的需求（证明以前有类似项目的开发经验和产品积累），但用户方自己不清楚，因此此时开发一个“可运行原型系统”，开发方的投入不会很大，但对于用户理解和确认项目需求非常有利，因此针对这种类型的项目这是一种比较理想的需求获取方式。

　　这种方法的另一个好处是：

正式系统一般可以在该“可运行原型系统”的基础上演化而成，为后续开发工作节省不少的工作量和成本。

　　值得注意的是，以上总结出的这四种需求获取方法不是互斥的，我们可以根据项目的实际特点独立应用或组合应用。

　　“忙碌，不代表有效率；方法，远胜于苦干”。

但愿我们从事软件项目开发的朋友们，都能掌握好恰当的方法，以图能获得“事半功倍”的效果．