软件项目需求调研方法论(共23页).doc

上传人:飞****2 文档编号:13983104 上传时间:2022-05-02 格式:DOC 页数:23 大小:167KB
返回 下载 相关 举报
软件项目需求调研方法论(共23页).doc_第1页
第1页 / 共23页
软件项目需求调研方法论(共23页).doc_第2页
第2页 / 共23页
点击查看更多>>
资源描述

《软件项目需求调研方法论(共23页).doc》由会员分享,可在线阅读,更多相关《软件项目需求调研方法论(共23页).doc(23页珍藏版)》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、精选优质文档-倾情为你奉上需求调研方法论文件版本:文件编号:编制人:编制日期:审核人:审核日期:批准人:批准日期:修改记录版本号修订人修订日期修订描述目 录1 需求概述1.1 软件需求1.1.1 需求定义需求是用户一种期望,是用户期望改善现状,解决某些问题或达到某种目标的需要。需求实现的过程,就是通过软件产品的功能达成用户目标,使之与用户期望目标相符的过程。1.1.2 需求层次软件需求的三个层次 1业务需求:反映了组织机构或用户对系统、产品高层次的目标要求。 2用户需求:描述了用户使用产品必须要完成的任务。 3功能需求:定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足业务需

2、求。 4非功能性的需求:不直接完成用户完成某项工作,但是在用户在操作系统过程中伴随产生的需要,描述了系统展现给用户的行为和执行的操作等,它包括产品必须遵从的标准、规范和约束,操作界面的具体细节和构造上的限制。1.1.3 需求来源软件需求可以来自方方面面,这取决于所开发产品的性质和开发环境。下面是几个软件需求的典型来源。1. 访谈、调查用户或潜在用户 为找出新软件产品的用户需求,最直截了当的方法是询问他们。通过直接与最终用户的访谈或调查,了解用户目前管理或应用过程中存在的问题、思想或想法、业务未来发展趋势,经过整理分析,形成软件需求。2. 研究竞争对手同类产品 当用户在实际工作中产生出新的需求后

3、,总会有对需求感觉灵敏的厂商嗅到商机,把用户的需求转换为产品。在我们没有更好条件深入到客户中进行调研的情况下,可以对竞争对手同类产品进行研究,发掘产品中的优点和存在不足,研究产品功能的目的和意义,倒推出软件需求。3.需求分析人员的经验 需求分析人员要时刻保持对所在领域知识的敏感,勤于思考,结合积累的丰富的所在领域知识,加上自己的分析和判断,形成基于用户实际工作中需求的假设,形成软件需求。 4.市场支持活动 软件产品发布推广后,用户在实际工作中对软件产品进行检验。在市场售后的支持人员在对用户进行培训和提供技术支持工作的同时,他们收集了用户在使用系统过程中所遇到的问题,还接受了用户关于系统改进的想

4、法。因此,可以通过收集市场支持人员接受的系统改进想法,并把它们转换为软件需求。 5. 政策制度和法律法规 公司所在的国家、行业的政策制度和法律法规是企业经营活动过程中必须遵循的规则,对公司活动有强制约束力。研究目标企业所在国家、行业的政策、法规和制度,发现其中信息化相关的要求,经过整理和分析形成软件需求。尤其是当企业所使用的法律法规、政策制度发生变动时,是软件产品更新换代的一个重大契机。1.2 需求调研定义通常情况下,用户无法独立直接提出完整、准确的需求,这就需要通过项目组的介入,借助需求调研把用户已经表述的需求弄清楚,挖掘用户尚未说明的需求。 需求调研指通过和用户进行沟通和交流而获取用户的需

5、求的一系列活动,是为编写需求说明书而做的前期工作。 换言之,需求调研就是假设用户已经掌握需求,通过某些手段或方法将需求准确、完整的描述出来,以便软件开发的后续活动顺利进行。1.3 需求调研目的需求调研就是了解参与实际工作的人们真正需要什么样程序的过程,获取准确、清晰、完整的用户需求信息,编写需求说明书,为后续工作提供依据。 需求调研有三个主要目的:1、获取准确、清晰、完整的需求,包括功能需求和非功能需求; 2、确定需求的分级,划分需求优先级,指导后续工作; 3、收集调研对象业务资料,预测需求的发展趋势,为软件产品发展方向提供依据。1.4 需求调研必要性1、需求调研是减小用户“期望差异”的关键一

6、步 软件产品作为一种特殊的商品,是软件公司通过有限的技术手段、资源为了满足用户的需要而开发出来的。由于需求“效用”的不可计量,再加上软件产品不能直接创造价值的特殊性,用户就有可能会对最终产品产生“期望差异”,这种“期望差异”会影响用户对软件产品的满意度,影响软件产品的销售。需求调研就是要了解到用户的期望,以期在软件研发过程中减小这种差异,提高用户的满意度。软件需求也可以说是用户在一定的条件下为了改善管理条件、追逐更大利润的“欲望” 。当欲望得到满足,人们会感到快乐和幸福,这就是“效用” 。处于软件产品两端的用户和开发商由于受到客观条件的限制,双发不能传递准确的需求信息,在一开始无法在信息系统的

7、需求上达成一致意见。由于技术能力的局限,用户很难准确地把系统需求传达给开发商;由于业务局限,开发商也很难准确获取用户真实的应用需求。需求信息的不对称和需求描述的错位,容易引起系统设计的缺陷,最终导致系统应用不理想甚至系统失败。作为客观世界的存在,用户所处环境、思想等的不同,不同用户对同一领域的需求是存在差异的。软件产品是在有限的资源、有限的时间、有限的技术手段和条件下研发出来的,不可能获取所有潜在用户的需求,也不可能满足所有潜在用户的需要,这就需要软件产品确立目标用户,重点关注目标用户的需求。能够获取目标用户的满意,赢得目标用户的认同,促进目标市场的销售,就是一款成功的产品。作为一家商业的软件

8、公司,其追求的目标是利益最大化,利益的重要来源就是向市场推出更多令人满意的软件产品,获得市场的成功。如何令用户对我们推出的产品满意,是作为软件研发、销售人员时刻警惕和思考的主题。在我看来,让用户满意就是在用户看到、使用我们软件的时候满足其“期望”甚至超出他的“期望”,这就会引起用户的购买欲,从而带来销售机会。而获取、了解用户的期望值,是软件产品能够满足用户期望的先决条件,只有了解了用户的期望,通过产品研发最大限度的实现用户期望,提升用户的满足感, 研发出的软件产品才能更好贴近用户的期望,提升用户期望的满足度。结论: 1) 软件产品一定要有目标客户,目标客户的需求才是需要重点关注的; 2) 需求

9、调研很重要,是软件产品能够赢得市场的先决条件,是任何软件公司、软件研发人员必须重视的一个环节。 3) 需求调研和分析是信息化建设的第一步,牵一发而动全身,做好需求调研是软件产品成功的关键一步。2、需求变动大,可能是因为需求不完整、不清晰。 参与过软件研发的很多人都有这样的抱怨“用户需求又变了,截至今天已经变了 3次,很多工作得重新返工,真不知道下次还会不会变了。”,尽管无奈,又不得不对改变的需求重新评估、设计、开发、测试,这些变更不只是加大了软件研发的成本,对研发人员的积极性也是一种挫伤,降低了研发人员的成就感。 尽管需求发生变化时,对软件研发影响很大,但往往需求变更又是不可控的,需求变化是客

10、观存在的, 是作为软件研发人员必须正视和面对的问题随着目标用户的变化,目标用户认知的提高、用户内部环境的变化、外部境的变化、技术的进步等,需求也总是在不断改变的,往往是在前期需求得到满足后,会产生出更高层次的需求。 诚然,为保证软件研发的顺利进行,保证软件产品的按时交付,我们要对需求加强管理,控制需求变更,但是面对变更,我们更应该考虑如何减少变更发生的机会,让我们更多掌握研发的主动权。更何况控制需求变更,不可避免的要牺牲用户的满意度,在软件产品还没有交付到用户手中时,已经产生了“期望差异”,势必对产品的销售造成影响。 换个角度看这个问题,用户的需求总是发生变化,很有可能是我们原本就没有完全获取

11、用户的需求,或者没有挖掘出用户隐含的需求,研发所依据的需求是不完整、不清晰的。通过需求调研,是获取完整、清晰用户需求的很好途径,有了完整、清晰需求作为研发依据,可以很好降低需求发生变化的几率。结论: 1) 需求变化是客观存在的,作为软件研发人员必须保持良好心态处理好需求变更; 2) 需求在一定的时间范围、一定的环境下(经济环境、组织结构、发展期间、IT 应用水平)、一定的用户群体范围内是确定的,或者说是相对确定的。 3) 加强需求管理,进行需求调研,尽快、尽早获取完整、清晰需求是比控制需求变更更好的办法;3、错误越早修复成本越低 需求阶段是软件研发中的一个重要阶段,其成果是研发后续各阶段工作的

12、重要依据,对研发有着重大影响,需求质量的高低往往决定着一个项目的成败。 做好需求调研是获取完整、准确、清晰需求的前提,准确的需求是项目成功的关键。 据权威机构对软件各阶段发现错误修复成本的统计,如下图:从上图可以看出,在软件研发过程中,越到后面阶段修复错误的成本越高,而且往往是需求阶段成本的成百上千倍。进行需求调研,可以尽早使不清晰的需求更加明确,可以对不准确的需求进行修订,补充完善需求,尽早发现错误,尽快修复,减少研发过程中后续阶段的潜在错误数,缩短研发周期,降低研发成本。 结论: 需求调研可以有效减少研发过程中潜在的需求错误数量,降低研发成本。1.5 需求调研是否可裁剪在实际的研发过程中,

13、由于外部环境或内部环境的压力,软件研发往往面临着时间紧、任务重的局面,为了能够保证按时交付软件产品,项目管理者往往会选择裁剪或压缩需求调研,而给软件编码和测试预留充足时间,结果往往是项目结束时按期交付了产品,质量如何就不好说了。 在我看来,这样的过程是很危险的,很可能是花费了大量的时间成本和人力成本,得到一个并不被市场认可的产品,公司浪费了人力财力,参与其中的研发人员也不能从中获取成就感。即使软件研发团队面临着工作量大、人员不足、时间紧张的局面,研发团队也不能在不了解需求的情况下直接编码,凭自我感觉做事。 需求不清晰、不完整、不稳定是项目最大的风险,可能导致项目的返工,导致项目延期,最终导致项

14、目的终止。一个有生命力的软件产品,必然要以真实用户的需求为依据,严谨的研发过程为保证,从用户中来,回到用户中去。 需求调研的过程是否可以裁减,我认为是可以的,只要需求是清晰、完整、准确的,并且研发团队与用户对需求的认知是一致的,在这样的条件下,需求调研过程是可以裁减的,但是建议项目团队出具需求文档,便于项目的传承交接。在其他情况下,需求调研过程应该都是不可以裁减的,但可以根据条件选择适合的调研方式。1.6 需求调研启动时机从软件研发阶段来看,项目立项后, 软件产品范围和目标用户就确定了,产品人员就可以着手准备进行需求调研了。2 需求调研过程2.1 调研实施前活动2.1.1 识别调研范围需求调研

15、范围对需求调研过程影响重大,决定了需求调研对象、调研参与人员和调研周期的长短,清晰、准确的需求调研范围是调研活动获得成功的先决条件,在决定进行需求调研后,必须要尽快识别需求调研范围,确定调研内容。 调研范围从宏观上划分了调研内容边界,决定了本次调研的主要内容,可以依据产品范围和预期目标分析目标组织特征和业务特征,确定需求调研范围,划分清楚调研业务边界。 如果一次需求调研范围过大,则可能导致调研实施周期长,调研质量不稳定。在这种情况下,项目管理者可以依据经验把调研范围划分成若干个业务域,识别其中关键的业务域,确定调研重点,便于调研过程的控制。2.1.2 组建调研团队项目成功的一个重要前提条件就是

16、有一个责权分明、强有力的执行团队。根据项目需求调研工作要求,为及时有效沟通,更好的推进需求调研工作,组建调研团队,可以视项目大小和复杂程度确定人员要求和数量。 需求调研工作的参与方包括业务用户和调研实施人员: 1、业务用户:由熟悉调研范围相关业务实际工作的用户组成,负责提出需求,评审需求结果,协助调研实施人员完成需求调研工作; 为保证需求调研的质量,需求调研应该选择尽可能多的用户进行调研,但是由于项目时间和成本上的原因,不可能对所有的用户都进行需求调研,所以要识别出能够确定需求和便于了解业务流程的用户作为每类用户的代表。 系统用户在很多方面存在着差异,例如:知识技能、所处岗位(所进行的业务过程

17、) 、权限、地理上的布局以及个人的素质和喜好等等。根据这些差异,你可以把这些不同的用户分成不同的用户类,从每类用户中选择具有代表性的部分用户作为调研对象。每类用户户至少选择一位能真正代表他们需求的人作为代表并且能够作出决策,用户代表往往是本类用户中三类人:对项目有决定权的领导、熟悉业务流程的专家、系统最终用户。每一个用户代表者代表了一个特定的用户类,并在那个用户类和开发者之间充当主要的接口,用户代表从他们所代表的用户类中收集需求信息,同时每个用户代表又负责协调他们所代表的用户在需求表达上的不一致性和不兼容性。 用户类不一定都指人,也可以包括其他应用系统、接口或者硬件,这样做使得与系统边界外的接

18、口也成为系统需求。将用户群分类并归纳各自特点,并详细描述出它们的个性特点及任务状况,将有助于需求的获取和系统设计。 2、调研实施人员:由熟悉调研业务领域人员组成,负责组织、协调和开展需求调研工作,记录调研内容,编写需求说明书。 调研实施人员是整个需求调研过程的执行者,通过调研实施人员按计划、按步骤的与用户沟通,收集调研范围需求,最终出具需求规格说明书。 调研实施人员的能力和活动对需求调研的进度、质量起着重大影响作用。调研实施人员的组成应以互补为原则,至少由三类人组成:技术人员、业务人员和管理者,根据需求调研范围选择能力与之相匹配的人员参与调研。 确定调研实施人员后,结合调研实施人员能力和调研内

19、容,以充分发挥个人特长和利于需求调研为原则,确定调研实施人员角色,并结合调研范围进行分工。 3、需求调研管理人员:负责需求调研工作的整体工作部署,重大业务、进度等事项的协调,调研进度和质量的控制。2.1.3 确定调研方案在进行调研前,项目负责人要充分了解参与调研双方的基本情况,依调研对象的工作习惯、业务能力及调研人员能力、调研进度要求等因素选择调研方式。2.1.3.1 调研方式n 主导型调研 参与调研的用户对调研范围业务领域内知识、经验不足,没有系统、完整的认识,在调研过程中需要充分发挥调研实施人员的“专家”作用,利用调研实施人员掌握的知识、经验整理需求概要内容,提交给用户进行分析和初步确认,

20、最终由用户和调研实施人员对需求内容进行细化、确认的过程称之为主导型调研。 此种调研方式对调研实施人员能力要求高,调研实施人员可以根据项目时间要求自由安排进行调研,进度风险较低。但是由于缺少业务用户的支持,需求质量往往依赖于调研实施人员的能力,导致需求结果与业务用户的真实意图可能存在偏差,给调研进度和需求质量带来风险。 采用主导型调研方式,调研实施人员不仅要求具备业务领域内知识和丰富经验,还要有良好的沟通协调能力,在调研过程中,要反复和业务用户进行沟通,对双发达成一致的需求必须由业务用户签字确认。n 引导型调研业务用户在调研业务领域内有较为完整、系统的知识、经验积累,在调研过程中,调研人员利用自

21、身掌握的知识引导业务用户将需求阐述完整、清晰,最终由用户对需求进行确认的过程称之为引导型调研。 此种调研方式的调研过程业务用户和调研实施人员相互配合程度高,调研实施人员可以根据项目进度要求安排调研计划,按计划进行调研。调研实施人员通过引导业务用户提出需求,利用自身的知识积累、职业判断、整理需求信息,由业务用户对需求进行确认,此种调研方式的进度和质量风险最小。n 被动型调研业务用户强势,且在调研领域内知识、经验丰富,对未来建设系统有较为清晰的认识,在调研过程中采取由业务用户主动说明、阐述需求,调研人员记录、分析需求的方式,或由业务用户按照调研实施人员要求出具需求的方式,称之为被动型调研; 此种调

22、研方式对调研人员要求最低,但调研人员不能掌握调研进度,无法对收集到的需求质量进行判断,因而进度风险较大。 采用被动型调研方式,调研人员要提前做好调研提纲,把调研内容划分成若干个可独立调研的调研点,并按照调研提纲制定调研计划,按照调研计划进行调研,并在过程中加强监控,发现偏差尽快采取措施,降低进度偏差风险。在调研过程中,把调研对象提出的需求与调研提纲进行比较,分析收集的需求是否全面,保证需求质量。2.1.3.2 调研策略1、由粗到细,从宏观到微观,由外到内,逐步深入 需求调研是一项系统工程,调研过程是围绕业务需求展开的,调研收集的用户需求必须参照业务需求。调研过程必须先从宏观上了解用户业务的整体

23、概况,再逐步依序有计划的深入细节,在过程中不断修正对业务概况的理解,直至完成整个调研活动。因为对于用户的业务而言,我们是外行,如果从业务细节着手,很容易迷失方向,失去对业务核心的把握。同时要认识到,对于一个外行而言,我们对细节的理解也必定是有限的,不要指望自己能够无穷的、彻底的了解每一个细枝末节。一是项目是有计划、有成本控制的,不可能有无限的时间给你了解,二是用户作为业务领域专家,对业务有很好的理解,作为调研实施人员也没有必要熟悉每个细节,因为未来的系统也不可能完全包办所有业务的细节,还有很多事情是要靠用户企业中这些具有专业技能的人来做的。 2、从不同层次的用户代表那里收集不同层次的需求 不同

24、层次的用户由于工作内容、擅长业务等的差异,造成不同层次用户往往对同一业务有着不同层次的需求。作为调研人员,我们要明确知道哪类需求应该从哪个层次的用户获取,并在调研过程中检查需求调研对象的层次和获取需求的层次是否一致。通过由上到下的逐级访谈,对未来系统的描述就从一个大黑箱变成多个小黑箱,再变成透明、明确、详细的系统定义的过程。 通过调研企业高层决策者,更多的是了解系统预期目标、功能蓝图;通过调研业务操作人员,可以收集业务细节和操作细节。 3、以业务领域为主线,搞清楚每个业务的环节流程关系 1)按照调研内容的关联程度和特征,把调研内容划分成若干个调研主题,先理清楚每个主题的目标以及和其他主题发生的

25、关系; 2)理清楚每个主题内部存在的活动以及和其他主题之间发生的活动,并划分清楚每个活动的边界; 3)针对每个活动进行调研,弄清楚每个活动的流程环节和内容。2.1.3.3 调研方法需求调研方法一般有实地观察法、面谈法、问卷调查法、查阅资料等方法。 1、实地观察法 不和调研对象进行正面接触,而是在旁边对具体业务进行观察,参观调研对象的工作流程,观察调研对象的操作。根据观察收集到的信息,进行整理和分析,出具需求规格说明书。 2、面谈法 与调研对象进行面对面交谈,由调研对象描述业务信息和需求信息,调研人员向调研对象提出事先准备好的问题,并记录访谈过程。经过对访谈过程记录的整理和分析出具需求规格说明书

26、。 3、问卷调查法 调研人员根据调研内容将相关问题制成问卷表格,向调研对象发放调研问卷,调研对象根据实际业务填写问卷表格,调研人员按时回收问卷表格。调研人员根据收集到调研问卷进行整理和分析,获取需求,出具需求规格说明书。 4、查阅资料法 收集调研对象在调研范围内相关的规章制度、规范指南、工作过程产出等书面资料,并对收集到的资料进行整理和分析,获取需求的方式。 对于需求调研来说,访问调查宜采用直接面谈,并且使用非标准化的方式,这样便于发挥和沟通, 通过调研过程的互动,可以激发调研对象积极性,收获调研实施前遗漏的需求;问卷调查法是标准化调查,可作为一种辅助手段,对于较为复杂的信息系统调研,不建议问

27、卷调查作为唯一调研方法;而实地观察法和查阅资料法,作为由调研人员主动实施的调研方法,依赖于调研人员的主观判断,有一定局限性,可作为一种辅助手段对收集需求进行判断。 几种常用调研方法比较表: 调研方法调研周期调研成本人员要求调研效果实地观察法长次高次高中面谈法次长高低优问卷调查法中中中良查阅资料法短低高差2.1.4 调研准备为确保调研工作的顺利开展,在调研实施开始前,应安排一系列支持性工作,加强团队管理和建设,保障调研工作的顺利进行。 1、编制需求调研计划 需求调研过程是项目的一个阶段,需求调研计划是项目计划的一个组成部分。在需求调研范围、调研团队确定后,调研负责人预估工作量,编制调研计划。 通

28、常来说,需求调研过程是非标准化的过程,在调研的过程中围绕主题进行发散性的探讨,编制需求调研计划,任务的粒度一般只需到业务块,由调研人员把握具体进度,调研人员可以视调研过程的实际情况在“大”计划指导下灵活调整细节计划。 2、编制调研活动使用的文档模版 调研活动的主要成果是记载需求的一系列文档,为便于文档的理解和后期整理、使用,软件需求应使用统一的模版,并按照一致的规范编写,调研过程使用的文档模版主要包括调研记录模版、用户需求说明书模版、软件需求说明书模版等。 编写规范和模版确定后,在调研组内进行推广、培训。 3、准备调研过程使用的工具,并分发给参与调研人员,如 word、 excel、 visi

29、o等。 4、制作调研提纲 为确保调研质量,在调研活动实施前,调研人员应根据调研范围编制调研提纲。 调研提纲至少应包括如下几个方面: 1) 调研对象的基本情况 2) 调研对象的预期目标 13) 调研业务的功能需求 4) 调研业务的非功能需求 调研提纲是贯穿于整个调研活动,在调研实施过程中,调研人员可以根据调研提纲引导用户提出需求,检查用户提出需求是否完整;调研结束前,调研提纲是判断调研是否完成的一个重要依据,调研提纲所有内容都已经收集到相关用户需求,调研活动可以宣告完成。5、调研背景培训 向调研人员介绍本项目的主要目标、项目范围和重点工作,避免在需求调研过程中业务人员所提需求超出范围,抓不住重点

30、; 介绍调研对象基本情况,包括调研对象目前总体状况、主要业务、组织机构和关键人物等; 培训调研对象的行业知识,学习调研对象使用的术语,标准,以便能够准确的理解用户的需求,提高调研人员的行业知识面;2.1.5 前期沟通在调研实施前的准备工作基本就绪,调研工作实施前,由调研工作负责人将调研工作计划、团队及分工等信息告知业务用户,便于业务用户进行调研的相关准备工作。2.2 调研实施2.2.1 调研实施一、倾听、记录需求 以用户为主,面对面的进行沟通和交流,完全倾听用户的心声,调研实施随时记录用户所说的一切有用信息,并使用调研记录模版格式记录下自己的认识和问题。用户完成某一主题的表述后,调研人员复述自

31、己记录的需求内容,在复述的同时可以结合自己的认识和记录的问题发表建议,使得记录的需求条理化、合理化。调研内容应至少包括以下内容: 1. 用户和本行业业务现状及存在问题; 2. 调研对象涵盖业务的组织机构及对应职责和权限; 3. 调研对象主要业务及业务的大概流程,每个业务的流程流经哪些部门,业务如何在部门之间流转; 4. 调研对象解决问题、改变现状的需求内容。 5. 调研业务未来发展趋势是怎样的? 6. 非功能方面的需求调研记录是调研人员在调研过程中记录下调研对象的意思表述,是需求最为原始的记录,是进行需求分析、总结的唯一依据。调研记录的质量高低直接决定了需求质量的好坏,写好调研记录不仅要求调研

32、人员如实记录调研对象的真实意图,还需要根据自己的理解将用户繁琐、含糊不清的语言转换为言简意赅的语句。 调研记录应至少包括业务流程、工作方法和具体内容,推荐使用 4W1H的方式编写调研记录,4W即“What、Who、When、Why”,1H即“How”。What 需求是要做什么,实现什么目标?通过把调研内容划分成若干领域,逐步弄清各个领域的工作流程和工作内容。 Who 处理过程中涉及了哪些部门、人或岗位, 业务过程会有哪些相关者? When 在什么时间或什么条件下发生,如果是周期性构成,周期有多长? Why 为什么会产生这个需求,需求的目的是什么? How 如何完成需求处理过程,为完成业务目标所

33、采用的方法或手段是怎样的?二、引导需求 由于用户语言表达、个人能力、所处环境等原因,有时不能很好表达内心想法,这样的情况下调研实施人员的业务背景和经验往往对需求收集有效性有很大的影响。需求调研过程不是简单的听用户讲,而是需要我们去引导用户讲出他们真正面临的问题和解决问题的想法,通过我们积极的沟通让用户把他们真实的想法真正的表达出来。 引导用户的需求应做到能够描述用户的常规需求外,能够发掘用户的潜在需求,争取能够提出用户的兴奋需求,挖掘用户的隐性需求,这样作出的软件才有生命力,才能真正体现出软件的价值。 引导用户需求的几种常用方法: n 向用户讲述基本的计算机操作。 n 向用户演示将要实施的系统

34、的原型。 n 从软件开发中需求的完整、准确、清晰、一致等几个方面入手,使得n 用户提出的需求完整、准确、清晰、前后一致。 n 从显性需求出发,推断用户需求的真实意图,超越显性需求,发掘n 潜在的隐性需求。三、评估需求 不是所有需求都是受欢迎的,也不意味着用户提出的所有需求都是正确的。在调研过程中,往往存在着如下情况: n 由于用户所处环境(如工作内容的差异)的不同,不同岗位、层次n 的用户的需求层次不同,彼此间对类似业务提出的需求存在着差异; n 由于用户个人能力的原因,对类似业务提出的需求不一致,相互矛n 盾; n 由于用户对计算机知识了解不多,提出的需求无法利用信息化手段n 实现,或花费很

35、高的成本实现并不重要的需求; 这就需要调研人员在充分理解需求的基础上,对需求的合理性、可实现性进行评估, 并将评估结果反馈给需求提出人,与需求提出人达成一致意见,尽可能早的发现不合理需求,减少后期需求分析复杂度和工作量。四、需求确认 需求调研是一个漫长的过程,在这个过程中调研的用户在不同时间对同一业务的表述可能是不一样的,如何避免由于用户想法的改变而导致的双方对需求认知的不一致,是我们在需求调研过程中必须解决好的一个问题。能够正确理解用户的需求,并且将用户的各种需求完整地体现在需求规格说明书中将更是一个复杂而艰辛的过程,因此在每一次的会谈之后必须将当天的会谈纪录形成文档,在下一次的调研开始前由

36、用户对上次的调研记录进行确认,减少需求在传递过程中的损耗。 五、需求分级 需求调研收集到用户需求后,如何利用需求进行系统建设?软件研发的实际情况往往是:由于客观条件的限制,我们没有能力一次就把所有需求做到尽善尽美,在软件研发过程中通常采用迭代的方法先把一大部分有把握的需求做好,再在前面成功的基础上不断做好剩余的部分,直至用户预期目标的达成。 摆在我们面前很重要的一个问题就是,如何确定需求实现的先后顺序?哪些需求是用户重点关注,需要优先、重点实现的,又有哪些需求可以暂缓提供的。哪些需求在开发过程中应该尽可能完整,才能符合用户预期,又哪些需求只需提供基本功能,就能满足用户需求的 为了使得各阶段提供

37、的软件产品更符合用户预期,为后续系统建设、开发提供依据,在了解用户需求后,很重要的一个工作就是在理解需求的基础上确定需求层级。 1)需求满足层级 基本性需求:用户主动提出的、迫切需要实现、未来建设的信息系统必须满足的需求,如果此类需求不获得满足,系统无法达成用户的预期目标。 满足性需求:符合用户预期,此类需求相对独立,并且不对主要业务实现造成很大影响。需求实现后,能够给用户实际工作带来一定便利,能够提升用户对软件产品的满意度。 兴奋性需求:超出用户预期,是同类产品无法满足而未来建设信息系统可以满足的需求。需求实现后,能够给用户实际工作带来很大帮助,是信息系统吸引用户,培养用户忠诚度的重要因素。

38、 2)需求优先级 按照用户对需求关注的重要程度、需求对系统建设目标影响程度,可以将需求优先级划分为高、中、低三个层次。2.2.2 调研注意事项1、 需求调研实施人员应事先了解用户的身份、背景,以便随机应变; 2、 保持一种和用户平等合作的心态,确定需求调研是为了给用户解决问题,探讨问题,而不是接受问题,更不是来指导工作的; 3、 切勿迟到或早退,注意礼节,尽可能获得用户的好感,并为下次打扰他们埋下伏笔; 4、如果双方气氛融洽,可以采用灵活的访谈形式,轻易不要打断用户的谈话。当双方对某些问题的交流合乎逻辑地结束后,再继续讨论问题表中的其它问题; 5、避免片面地听取某些用户的需求而忽视其它用户的需

39、求。 6、需求调研中,学会尽量不使用 IT 行业的术语,而采用浅显易懂的口头语言来解释 IT 行业中高深莫测的术语,以便用户能够很好的理解,提高自己的沟通交流能力; 7、调研工作结束后,制作通讯录,方便后期需求不清晰通过电话、电子邮件等方式进行沟通。3 编写用户需求规格说明书需求规格说明书是需求的载体,调研人员对收集到的所有需求记录进行分类整理,消除其中的错误信息,通过归纳与分析,识别、归并共性需求,将用户的意思表述用结构化的语言描述对用户需求进行转换, 并按照统一模版格式编写需求规格说明书。 我们不能期望用户反馈的需求都是清晰的,结构化的,但提交给开发部门的需求必须是清晰的、准确的、抽象的和可测试的,这就对我们编写需求规格说明书过程提出了质量的要求。编写高质量需求没有一个简单的规律可循,很大程度上,它是从过去编写需求问题中得到的教训与经验,这里有几条编写需求时的原则,供各位参考: n 保持句子和段落简短,不拖沓啰嗦; n 从开发者的立场来看,检查需求陈述是否足够明确,是否存在含混不清的表述; n 检查是否有一个需求描述表达了多个需求,如果有,将它们分开; n 检查文档中是否存在重复或相似的需求,如果有,将它们归并。专心-专注-专业

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 教育专区 > 教案示例

本站为文档C TO C交易模式,本站只提供存储空间、用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。本站仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知淘文阁网,我们立即给予删除!客服QQ:136780468 微信:18945177775 电话:18904686070

工信部备案号:黑ICP备15003705号© 2020-2023 www.taowenge.com 淘文阁