需求获取的方法
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
需求获取技术
需求获取的目的:(1)清楚地理解所要解决的问题;(2)完整地获取用户需求。
需求获取面临的挑战:问题的复杂性和问题空间;理解的不完备性与不一致性;交流障碍;需求易变性。
所以,分析人员必须掌握一些基本技术,包括初步需求获取技术、需求建模、问题抽象与问题分解快速原型技术。需求获取技术包括两方面的工作:建立获取用户需求的方法的框架;支持和监控需求获取的过程的机制。
一、需求获取的常用方法
1.组织人员
组织人员,建立分析小组,其中包括领域专家:主角,也就是用户方面的问题专家,了解软件所解决问题的领域知识。系统分析员:导演,软件开发人员方面的人,其主要分析,抽象领域专家的知识,形成软件模型。
2.客户访谈
客户访谈,也就是获取用户需求,其主要方法是调查研究。其主要内容包括:
(1)了解系统的需求。软件开发常常是系统开发的一部分。仔细分析研究系统的需求规格说明,对软件的需求获取是很有必要的。
(2)市场调查。了解市场对待开发软件有什么样的要求;了解市场上有无与待开发软件类似的系统。如果有,在功能上、性能上、价格上情况如何。
(3)访问用户和用户领域的专家。把从用户那里得到的信息作为重要的原始资料进行分析;访问用户领域的专家所得到的信息将有助于对用户需求的理解。
(4)考察现场。了解用户实际的操作环境、操作过程和操作要求。对照用户提交的问题陈述,对用户需求可以有更全面、更细致的认识。
在做调查研究时,可以采取如下的调查方式:
·制定调查提纲,向不同层次的用户发调查表。
·按用户的不同层次,分别召开调查会,了解用户对待开发系统的想法和建议。
·向用户领域的专家或在关键岗位上工作的人个别咨询。
·实地考察,跟踪现场业务流程。
·查阅与待开发系统有关的资料。
·使用各种调查工具,如数据流图、任务分解图、网络图等。
为了能够有效地获取和理清用户需求,应当打破用户(需方)和开发者(供方)的界限,共同组成一个联合小组,发挥各自的长处,协同工作。
3.问题分析与确认
问题分析与确认,主要组织分析并评审,最终确定问题是否比较完整。
二、需求获取的内容
需求分析目标主要搞清楚软件用户要“做什么”,其用户需求内容主要是两方面:一是功能性需求:定义了系统做什么(描述系统必须支持的功能和过程);二是非功能性需求(技术需求):定义了系统工作时的特性(描述操作环境和性能目标);
两类需求包括的内容:功能;性能;环境;界面;用户或人的因素;文档;数据;资源;安全保密;软件成本消耗与开发进度;质量保证。下面分别对其作一定解释:
(1)功能需求:系统做什么系统何时做什么系统何时及如何修改或升级
(2)性能需求:软件开发的技术性指标:例如:存储容量限制;执行速度、相应时间、吞吐量。
(3)环境需求:硬件设备:机型、外设、接口、地点、分布、温度、湿度、磁场干扰等;软件操作系统;网络;数据库。
(4)界面需求:有来自其他系统的输入吗到自其他系统的输出吗对数据格式有规定吗对数据存储介质有规定吗
(5)用户或人的因素:用户类型各种用户熟练程度需受何种训练用户理解、使用系统的难度用户错误操作系统的可能性
(6)文档需求:需哪些文档文档针对哪些读者
(7)数据需求:输入、输出数据的格式接收、发送数据的频率数据的准确性和精度数据流量数据需保持的时间
(8)资源需求:软件运行时所需的数据、软件。内存空间等资源。软件开发、维护所需的人力、支撑软件、开发设备等。
(9)安全保密要求:需对访问系统或系统信息加以控制吗如何隔离用户之间的数据用户程序如何与其他程序和操作系统隔离系统备份要求
(10)软件成本消耗与开发进度需求:开发有规定的时间表吗软硬件投资有无限制
(11)质量保证:系统的可靠性要求系统必须监测和隔离错误吗规定系统平均出错时间出错后,重启系统允许的时间系统变化如何反映到设计中维护是否包括对系统的改进系统的可移植性
摘要:我们知道,需求调研不充分、用户需求描述不完整不准确,轻则影响项目建设的顺利程度,重则影响应用系统的质量,甚至决定项目的成败。
俗话说,“良好的开端是成功的一半”。需求获取作为项目伊始的活动,是非常重要的。
目前我们所开发的软件项目一般有两种类型:产品项目和工程项目。
产品项目一般都会有充足的时间进行非常仔细的需求调研和分析,而工程项目却并非如此(因为它往往受诸多因素的影响)。
本文拟讨论如何根据工程项目的实际特点,采用合适的方法低成本高效率地获取用户的需求。
关键词:工程项目需求获取方法
产品项目一般是根据公司战略和市场需求研发的旨在进行批量出售或推广的项目,工程项目一般是根据
与用户签定的合同研发的旨在满足特定用户需求的项目。
笔者所开发和管理的项目主要是工程项目,在项目的建设过程中,感觉到最头疼的是项目需求的获取;我们往往要花相当大的精力在需求获取和需求确认上,然而有时效果还很不理想。
经过几年时间的项目实践,我们逐步总结出针对不同项目情况所适合采用的需求获取方法,这些方法能大大提高需求获取的效率。现总结之,愿与大家分享。
我们知道,一个工程项目,如果从开发方(即承建方)和用户方(即建设方)对需求的清楚程度来分,大致可以分为如下四种:开发方和用户方都清楚项目需求、开发方不清楚项目需求但用户方清楚、开发方和用户方都不清楚项目需求、开发方清楚项目需求但用户方不清楚。
针对这四种类型的项目,我总结出四种对应的需求获取方法:问卷调查法、会议讨论法、界面原型法和可运行原型系统法。
以下逐一解析之
一、问卷调查法
??????? 所谓“问卷调查法”,是指开发方就用户需求中的一些个性化的、需要进一步明确的需求(或问题),通过采用向用户发问卷调查表的方式,达到彻底弄清项目需求的一种需求获取方法。
这种方法适合于开发方和用户方都清楚项目需求的情况。因为开发方和建设方都清楚项目的需求,则需要双方进一步沟通的需求(或问题)就比较少,通过采用这种简单的问卷调查方法就能使问题得到较好的解决。
这种方法的一般操作步骤是:
步骤一、开发方先根据合同和以往类似项目的经验,整理出一份《用户需求说明书》和待澄清需求(或问题)的《问卷调查表》提交给用户;
步骤二、用户阅读《用户需求说明书》,并回答《问卷调查表》中提出的问题,如果《用户需求说明书》中有描述不正确或未包括的需求,用户可一并修改或补充;
步骤三、开发方拿到用户返回的《用户需求说明书》和《问卷调查表》进行分析,如仍然有问题,则重复步骤二,否则执行步骤四
步骤四、开发方整理出《用户需求说明书》,提交给用户方确认签字。
由于这种方法比较简单、侧重点明确,因此能大大缩短需求获取的时间、减少需求获取的成本、提交工作效率。二、会议讨论
所谓“会议讨论法”,是指开发方和用户方召开若干次需求讨论会议,达到彻底弄清项目需求的一种需求获取方法。
这种方法适合于开发方不清楚项目需求(一般开发方是刚开始做这种业务类型的工程项目)但用户方清楚项目需求的情况。因为用户清楚项目的需求,则用户能准确地表达出他们的需求,而开发方有专业的软件开发经验,对用户提供的需求一般都能准确地描述和把握。
这种方法的一般操作步骤是:
步骤一、开发方根据双方制定的《需求调研计划》召开相关需求主题沟通会;
步骤二、会后开发方整理出《需求调研记录》提交给用户方确认;
步骤三、如果此主题还有未明确的问题则再次沟通,否则开始下一主题;
步骤四、所有需求都沟通清楚后,开发方根据历次《需求调研记录》整理出《用户需求说明书》,提交给用户方确认签字。
由于开发方不清楚项目需求,因此需要花较多的时间和精力进行需求调研和需求整理工作。
三、界面原型法
所谓“界面原型法”,是指开发方根据自己所了解的用户需求,描画出应用系统的功能界面后与用户进行交流和沟通,通过“界面原型”这一载体,达到双方逐步明确项目需求的一种需求获取的方法。
这种方法比较适合于开发方和用户方都不清楚项目需求的情况。因为开发方和用户方都不清楚项目需求,因此此时就更需要借助于一定的“载体”来加快对需求的挖掘和双方对需求理解。这种情况下,采用“可