收藏 分享(赏)

第3章 需求获取课件.ppt

上传人:无敌 文档编号:965587 上传时间:2018-05-08 格式:PPT 页数:157 大小:6.03MB
下载 相关 举报
第3章 需求获取课件.ppt_第1页
第1页 / 共157页
第3章 需求获取课件.ppt_第2页
第2页 / 共157页
第3章 需求获取课件.ppt_第3页
第3页 / 共157页
第3章 需求获取课件.ppt_第4页
第4页 / 共157页
第3章 需求获取课件.ppt_第5页
第5页 / 共157页
点击查看更多>>
资源描述

1、1,第3章 需求获取,2018/5/8,2,第3章 需求获取,软件需求获取(简称需求获取)阶段的任务简单的说就是获取用户的需求信息。 其过程如左图所示:,确定非功能需求和约束条件,实地收集用户需求信息,确定调查对象,建立项目范围和目标,确定需求开发计划,2018/5/8,3,第3章 需求获取,3.1确定需求开发计划3.2确定项目的目标和范围3.3确定调查对象3.4实地收集需求信息3.5确定非功能需求3.6在收集需求信息中应注意的问题3.7使用场景技术的需求获取,2018/5/8,4,3.1确定需求开发计划,确定需求开发计划的基本任务是确定需求开发的实施步骤,并给出收集需求活动的具体安排和进度

2、。需求开发计划需要注意以下几点:(1)只考虑与需求开发相关的工作;(2)应考虑困难性和灵活性;(3)应考虑书写和整理需求规格说明及其文档所花费的时间。,2018/5/8,5,3.2确定项目的目标和范围,此阶段的基本任务是根据项目目标把项目相关人员定位到一个共同的和明确的方向上,并决定软件系统的范围。 项目的范围与项目的目标特别是软件系统的目标需求是密切相关的。,2018/5/8,6,3.2确定项目的目标和范围,在收集目标需求时,目标需求会来源于各个不同的人,这些人对要开发的软件系统及该系统最终能为用户或客户提供哪些价值有比较清楚的了解。,2018/5/8,7,3.3确定调查对象,本阶段的基本任

3、务是明确地确定来自不同层次的需求来源和用户,并将其分类。 应根据需求的层次来区分不同的用户: (1)提出目标需求的用户;(2)提出业务需求和功能需求的用户;(3)软件开发人员,主要是指系统分析员。,2018/5/8,8,3.3确定调查对象,软件系统面临的用户是很多的,而这些用户由于所在的部门、职责和掌握的知识不同而存在差异,为了避免忽视和遗漏某些用户的情况,可以根据用户的某些方面将用户分类。,2018/5/8,9,3.3确定调查对象,在将用户分类后,在分类的基础上进一步寻找每类用户的代表或联络人,这些人代表了一个特定的用户类,并可充当该用户类与开发人员之间的“窗口”。 这些人也必须是真正的用户

4、,而不是单纯的代理人。,2018/5/8,10,3.3确定调查对象,2018/5/8,11,3.3确定调查对象,软件需求可来自与各个方面,而且用户类也不一定都是指人。有时也可以把其它应用系统或计算机硬件设备和接口等视为附加的用户类成员,这样就可确定软件系统与哪些外部应用系统或计算机硬件相关的需求。这就是说需求信息来源除了来自用户类外,还可来自于其它方面。,2018/5/8,12,3.3确定调查对象,几个典型的软件需求来源: 直接和间接使用软件系统的用户; 系统需求规格说明; 市场调查和用户问卷调查; 已开发出的和待开发的同类软件系统的描述和文档; 对人工系统的存在问题的报告和增强要求; 观察正

5、在工作的用户; 用户工作内容的分析。,2018/5/8,13,3.3确定调查对象,当确定了用户类及明确了用户需求的主要来源后,这样就可从不同的渠道和不同的人那里收集到大量的需求信息。但这些需求信息既包含了明确的用户需求,也包含了一些不一致和含糊的需求,而且软件开发人员也难以解决。因此,这就需要寻找需求的决策者。 在处理有问题的需求信息时,决策者并不是固定不变的,而是根据实际中可能发生的具体问题来确定。,2018/5/8,14,3.4实地收集需求信息,在确定了需求的来源和调查对象后,下一步就是实地收集需求信息。实地收集需求信息阶段的任务就是到现场实地调查和与用户交流,收集和理解用户需求信息。,2

6、018/5/8,15,3.4实地收集需求信息,实地收集需求信息可能面临的困难:能提出软件需求的用户可能觉得他们没有充分的时间与开发人员进行交流和讨论 ;有时用户希望通过简单的方法和说明,或者通过简单回答开发人员的询问后,软件开发人员就能清楚地理解他们的需求,而不需要花费太多的时间进行讨论;,2018/5/8,16,3.4实地收集需求信息,用户和开发人员都只考虑自己的利益;如:有些用户由于缺乏使用计算机的经验,导致产生畏难情绪;有些用户认为开发软件系统自己的关系不大,对待需求信息的收集工作采取消极的态度。用户本身不能提出明确的需求 ;开发人员缺乏用户的业务知识,而用户也缺乏计算机方面的知识,导致

7、双方在交流中产生许多的困难,以至收集工作难以进行。,2018/5/8,17,3.4实地收集需求信息,实地调查的步骤:向掌握“全局”的负责人调查;向部门负责人调查;向业务人员调查。,步骤(2)和步骤(3)是一个反复的过程,而且每次调查之前要制定调查提纲,每次调查要作记录,并交由用户审查核实,以保证需求信息的可靠和准确。,2018/5/8,18,3.4实地收集需求信息,实地收集需求信息的方式以座谈会的方式;以书面咨询的方式;利用用例表示方法。,2018/5/8,19,3.4实地收集需求信息,需求信息可大致分类如下:目标需求;用例说明;业务规则;功能需求;性能需求;外部接口需求;限制,数据定义;解决

8、思想。,2018/5/8,20,3.5确定非功能需求,非功能需求是衡量软件能良好运行的定性指标。由于缺乏定量指标,因此很难根据这些需求来评价软件系统,这也是开发出来的软件系统与用户所满足的软件系统之间存在差异的主要原因。,2018/5/8,21,3.5确定非功能需求,用户所关心的非功能需求主要有:可靠性;可扩充性;安全性;互操作性;健壮性;易使用性;可维护性,可移植性;可重用性。,2018/5/8,22,3.5确定非功能需求,在收集非功能需求信息时常用的方法:将不同用户类代表提出的可能很重要的非功能需求进行综合,并根据其中的每个需求设计出许多方法,然后根据用户的回答,使这些需求更明确化;开发人

9、员与用户一起对每一个非功能需求制定可测试和可验证的具体标准;设计与非功能需求相冲突的假设示例,利用反例来提示用户。,2018/5/8,23,3.6 需求定义(RUP模型),2018/5/8,24,关键五步:来源RUP的智慧,目标,Stakeholder,范围,约束,2018/5/8,25,寻找客户的需求,了解用户需求的第一步是在有关问题的定义上和用户达成一致。用户陈述的问题往往是表面现象,我们有必要和用户一起挖掘出问题背后的问题,即找出问题的根源,从而从根本上解决问题。确定系统的涉众,除了开发团队和用户等直接涉众,我们还要找到间接的涉众。系统边界确定了我们系统的内涵,即它究竟包括哪些功能,可以

10、解决哪些问题。确定解决方案的约束条件。,2018/5/8,26,3.6.1在问题定义上达成共识,描述问题的模版,所谓的问题分析,就是理解真实世界中的问题和用户需求并提出满足这些多方面的解决方案的过程。第一步是把问题拿出来,达到所有人的共识,采用统一的格式,RUP为问题定义提供了统一的模板,如下:,2018/5/8,27,下表是一个银行信用卡机构整理的问题定义描述问题定义示例,2018/5/8,28,问题定义技巧:转换,马的遍历问题:寻找一系列的移动步骤,使马走完每个方块,而落入任何一个方块有且只有一次,2018/5/8,29,问题定义技巧: 本源,问题:日内瓦湖上的山脉中建成了一条很长的汽车隧

11、道,为了防止停电时发生灾难,必须提醒司机进入隧道之前把车灯打开。解决方案一:“警告!前有隧道请打开车头灯”新问题:隧道出口风景很美,返回时发现汽车没电忘了关车头灯!解决方案二:出口处立标牌“关掉车灯”新问题:夜行车也会关掉车灯?,2018/5/8,30,案例:小林在一次电子政务项目中遇到了这样一个问题,用户要求对每个政务申请的各种处理都需要记录时间。由于他们选择的是C/S结构,因此取时间时就遇到问题,每台机器上的时间都不尽相同。“不就是时间不统一吗,让所有客户端登录时先从时间服务器上取一个时间就搞定了!”但这个方案在实际的运行时却带来了不小的麻烦,由于时间服务器写的不够稳定,经常会自动退出,当

12、这种情况出现客户端软件就根本无法进入,严重影响了客户的正常使用。,在确定某问题的解决方案时,思考是否引发新问题,2018/5/8,31,问题定义技巧:本源,解决方案三:建充电站新问题:维护开支大,充电站也会坏解决方案四:授权私人经营充电站新问题:风景区商业化,政府与游客均不接受,2018/5/8,32,直接修改错误,不要用其他方案来弥补错误,案例:在小程负责的一个客户关系管理系统项目中,用户在使用了一段时间之后提出了这样一个问题:客户数据库的数据比较乱,有重名、同客户多条记录等现象。小程毫不犹豫地说:“没关系,我可以为你们开发一个功能强大的客户数据清理工具,通过工具可以自动识别出这些混乱的数据

13、,并且提供一些合并、汇总、删除功能”。随着这个功能的开发,项目的范围也不断扩展,针对这个功能的需求也层出不穷。这就是软件开发过程中的“充电站”,成本付出了,但真的对项目有好处么?这样做,似乎很多人会举手赞成,但是也付出了巨大的成本。如果我们细究一些,这个问题是怎么产生的呢?为什么数据会混乱呢?,2018/5/8,33,解决方案五:在隧道尽头,树立新标牌 如果是白天,并且车灯开着,请熄灭车灯; 如果天色已晚,并且车灯没开,请打开车灯; 如果是白天,并且车灯没打,就别打开它; 如果天色已晚,并且车灯开着,请别关掉它。新问题:谁能在行驶时读完?!,问题定义技巧:本源,2018/5/8,34,在软件开

14、发中,例如安装过程中的向导就是此类例子:明知道大家都是闭着眼睛点击“下一步”按钮的,那么为什么还要不断重复这样的设计呢?这难道不就是一个蹩脚的标牌吗?如何解决?关键在于对问题的定义,先确定到底存在什么样的问题?如下图分析:,车没电,司机忘关大灯,缺乏提醒,寻找问题的本源,问题定义技巧:本源,2018/5/8,35,终极解决方案:在出口处立标牌:你的灯亮着吗?,问题定义技巧:本源,2018/5/8,36,影响人群分析的技巧,问题定义时,还可以对影响人群进行分析,得出推断和结论。文氏图分析,解决方案人群,影响 人群,?,Internet用户,婴幼儿 母亲和 祖辈,?,实例:2006年投资开办母婴网

15、站,2018/5/8,37,3.6.2了解问题产生的根本原因,问题定义达成共识后,下一步分析问题背后的问题,也就是寻找问题的本源。两种实用工具:一种是定性分析的鱼骨图一种是定量分析的帕累托图,2018/5/8,38,鱼骨图,鱼骨图也称为因果鱼骨图,它是一种以直观的图形找出问题或现象的所有潜在原因的方法,它有利于追踪出问题的根源。具有三个典型的好处:使分析人员将问题的原因而不是症状放在首位。提供了一种运用集体智慧解决问题的新方法。直观、简明、易于操作。通常鱼骨图分析的过程会结合头脑风暴。,2018/5/8,39,鱼骨图,绘制一个鱼骨图通常是一个团队在一起完成,具体步骤如下:选择问题头脑风暴确定原

16、因类型分配原因分析根本原因,2018/5/8,40,案例:开发一个在线图书借阅系统。传统的借书方式要求读者亲自来到图书馆,这显得非常不方便,而且随着藏书的增加和读者群的增长,大量的读者来到图书馆,使得图书馆的场地不足,工作人员也不够了。所以想到借助网络,让读者通过网络借/还书,这样可以节省大量的场地维护和工作人员成本支出,同时计算机可以方便地检索目录,让读者可以足不出户借到需要的书。为了把书送到借阅人手里,联系了快递公司,初步达成协议,由他们往返借阅人和图书馆之间,把图书送出和收回。读者在网上出示和验证借书卡,找到他们需要的书,提交申请,图书管理员确认后,就会通知快递公司来取书。当然在这个过程

17、中,读者是需要付费的。还书基本上也是同样的过程。,2018/5/8,41,鱼骨图,选择问题首先必须选择一个具体的问题或结果。在选择问题时,要保证问题是专门的、定义严谨的、范围相对较小的,并且保证所有参与人员能够切实理解分析的内容。对于上一步定义出来的每个问题都应该进行一次独立的鱼骨图分析。先将问题定义在白板或纸上写出来,画出第一层鱼骨,如图所示:,2018/5/8,42,鱼骨图,头脑风暴就导致问题的所有可能原因进行头脑风暴。如果在白板上进行,可以将大家提出的意见写在记事贴上,然后将它们贴到鱼骨图上。注意:不能将原因和解决方案混为一谈。头脑风暴法(Brain StormingBS):一种通过集思

18、广益、发挥团体智慧,从各种不同角度找出问题所有原因或构成要素的会议方法。BS有四大原则:严禁批评、自由奔放、多多益善、搭便车。,2018/5/8,43,鱼骨图,确定原因类型对头脑风暴的结果进行整理,确定出主要的原因类型。经常使用的类型:人、设备、材料、环境、方法或过程。(划分出来的类型不应该超过6种)将这些类型补充到鱼骨图上。,2018/5/8,44,鱼骨图,分配原因把头脑风暴得出的潜在原因放在鱼骨图中,并且确保每一项原因都归类于适当的类别中。如果原因看起来可以放在多个类别中,就表示它是一个多重原因:这种情况多次出现,就表示这个分类有问题,应重新考虑分类是否合适。相关的原因在组织时是可以分级整

19、理的,可以通过提出“是什么?”、“为什么?”、“怎么样?”、“在那里?”等问题来进一步发展更细等级的原因。注意:不要过于深究,否则陷入无尽的细节中,三层细节是图表的实际限制。,2018/5/8,45,鱼骨图,2018/5/8,46,鱼骨图,分析根本原因接下来要对鱼骨图中罗列出来的所有潜在原因进行分析,考察造成某一结果的根本原因最有可能是什么,或者说哪些原因是最核心的,可以通过一些几个方面来考虑:通过参与者之间的公开讨论来分享看法和经验;寻找重复的原因,或与特定类别有关的原因的数目;使用检查表收集资料、制作流程图或进行客户调查,通过帕累托图分析法测试各种原因的相对强度;一旦对一小部分主要原因达成

20、一致意见,就可以用成对比较法进一步缩小范围;有时只考虑那些能够影响到的因素是有好处的。,2018/5/8,47,鱼骨图,小结鱼骨图是一种因果分析工具,它在需求定义、项目管理、过程改进等活动中都是很有价值工作,可以用来:关注原因而非表面的症状;获取一个群体的集体知识和经验;提供了展现导致问题发生的所有原因和全景图;为进一步收集资料和行动提供了坚实的基础。,2018/5/8,48,定量分析帕累托80/20原则百分之八十的问题是百分之二十的原因所造成的。帕累托图在项目管理中主要用来找出产生大多数问题的关键原因,用来解决大多数问题。 几个方面的作用为80%的问题找到关键的20%的原因;一目了然地显示出

21、每个原因的相对重要程度;有助于预防在解决了一些问题后,却使另外一些问题变得更糟的情况。,帕累托图(Pareto Chart),2018/5/8,49,2-8 原则*,Walker Royce扩展了Barry Boehm提出的有关软件项目管理的“二八定理”,构成了现代软件管理过程框架的理论基础 80%的工程活动是由20%的需求消耗的 80%的软件成本是由20%的构件消耗的 80%的缺陷是由20%的构件引起的 80%的软件废品和返工是由20%的缺陷引起的 80%的资源是由20%的构件消耗的 80%的工程活动是通过20%的工具完成的 80%的进展是20%的人完成的,2018/5/8,50,帕累托图(

22、Pareto Chart),2018/5/8,51,3.6.3确定涉众和用户,涉众 (stakeholder) ,在软件开发项目中主要是指和这个项目有密切相关利益的人,他们共同感兴趣的就是需求分析阶段。这些涉众包括客户、用户、业务或需求分析员(负责收集客户需求并编写文档,以及负责客户与开发机构之间联系沟通的人)、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。,2018/5/8,52,解析stakeholder,简单的项目健康评价方法问项目经理一个这样的问题:你们的团队和哪一层客户打交道最多?如果答案是操作层,那么很遗憾,你的项目出现延误的可能性极大,几乎是难以避免的;其中原因很简

23、单,操作层手中的筹码相对来说是很少的,可能只是几个铜板。如果答案是中层管理人员,那么只要在项目过程中尽力,是有希望避免出现延误情况的,至少延误的比率相对较低;原因是中层手中有一定的筹码,加上人数较操作层少很多。如果答案是高层管理人员,那么恭喜你,项目出现延误的可能性几乎是没有的;高层管理人员手握着最有分量的筹码,而且人数极少。,2018/5/8,53,确定涉众的问题举例,2018/5/8,54,案例:在线图书借阅系统中的涉众,2018/5/8,55,3.6.4 确定系统的界限,定义系统的关键首先是要给出系统的边界。该边界把我们的系统和外部世界一分为二,换言之,系统边界确定了我们系统的内涵,即它

24、究竟包括哪些功能,可以解决哪些问题。我们可以根据确定的系统边界给出系统的环境模型。它指出了我们的系统以及其它和它交户的系统之间的关系。绝大部分书籍推荐使用上下文关系图来确定系统范围,实际上就是 数据流图中的顶层图。,2018/5/8,56,在线图书借阅系统的界限,2018/5/8,57,3.6.5确定解决方案的约束条件,潜在的系统约束,2018/5/8,58,到期催还功能的约束分析,2018/5/8,59,3.6.6 实例,问题描述:一家制造和网上邮购物品公司,制造和销售家用物品和个人用品。由于公司发现效益太差的问题,采用了全质量管理(TQM)来解决问题。公司量化了非质量成本之后,怀疑生产浪费

25、即“废品”是最主要原因。,2018/5/8,60,效益太差,找出 “废品”的根本原因鱼骨图:,根本原因的鱼骨图,2018/5/8,61,根本原因的帕雷托图,帕累托图 1) 确定问题与原因 2) 收集数据 3) 绘制直方图,2018/5/8,62,发现了一条根本原因:“不准确的销售订单”产生了半数的废品。发现已有的订单系统有一个不友好的用户界面,没有在线差错处理机制,那么,开发一个新系统是减少废品的最好办法。一旦我们确定不准确的订单是一个值得解决的根本原因之后,我们就可以生成一个如下表所示的订单系统问题的称述。,2018/5/8,63,销售订单问题陈述表,2018/5/8,64,确定涉众和用户,

26、2018/5/8,65,订单系统的简化系统透视,2018/5/8,66,确定解决方案的约束条件,销售订单输入系统的约束、约束源及理由,2018/5/8,67,3.7 在收集需求信息中应注意的问题,应能适当的调整收集范围;尽量把用户所持的假设解释清楚,特别是发生冲突的部分;尽量理解用户用于表达他们需求的思维过程,特别是尽量熟悉和掌握用户具有的一些专业知识和术语;在收集需求信息时,应尽量避免受不熟悉细节的影响;应尽量避免讨论一些具体的解决方案; 需求信息收集工作的结束。,2018/5/8,68,3.7.1需求获取的策略,3.7.1.1需求获取应该是主动的强调了需求分析人员在整个过程中应该充分发挥主

27、动性。需求获取是撒网打渔,不是休闲钓鱼。,2018/5/8,69,钓鱼模式 vs. 网罗模式,2018/5/8,70,案例: “小张,你回来了” “唉,是呀!昨天赶晚班机回来的,到家都快两点了!”小张显得一脸的疲倦。 “那你这次去客户那里了解到了什么情况?客户好像催你们过去催的很急呀!” 小张面带笑容地回答说:“嗨,他们来了一个新的信息主管,要和我们聊聊这个系统的规划和想法,也没有什么实质的东西,就是东拉拉西扯扯的!最大的作用就是混了个脸熟。”结论:需求获取活动很低效。问题关键在于需求分析人员是否善于去把握主动权,是否能够根据每次访谈的对象制定相应的计划。,2018/5/8,71,3.7.1.

28、2需求获取应该是聚焦的,捕获过程中的问题:提不出需求 提的需求太多 解决方案: 提出聚焦的问题,2018/5/8,72,需求获取应该是聚焦的,案例:老李和小赵是某软件公司的需求分析人员,有一次他们共同参与了一个设备告警监控平台项目。他俩分别对监控中心的小徐和小张进行了访谈。小赵问监控中心的小张:“你对这个系统有什么需求?”小张说:“我想到的功能包括值班日志、告警的声光提示、基于短信的告警通知,还有要为值班人员提供一个日程安排工具、一个共享文件管理工具,还要能够自动填报各种上级要的报表”。而老李问小徐的问题有很大的区别:当监控中心收到一个告警的时候,希望以什么形式体现?收到后,你们一般会进行什么

29、样的处理?在这个过程中需要做什么配套工作?原来处理时存在什么困难?有哪些问题是比较棘手的?小结:案例场景中,小张提问方法导致整个捕获过程发散的,而老李就能够使整个问题很聚焦,这样产生镀金需求、非重要需求的可能性大大下降。,2018/5/8,73,3.7.1.3破解需求的冰山模型,用户的需求是一个冰山,有很大一部分信息是埋藏在海平面之下的,对需求获取工作带来困扰。冰山可分为三层,如右图所示1.意识到的需求: (用户层面) 位于海平面之上,用户自己能够设想到的需求,(大量的需求以变更的形式出现) 2.无意识的需求: (开发者层面) 实际的工作场景,开发者能够对场景“感同身受”的话,那么就可以大大减

30、少变更的数量,需加强业务知识的捕获。,2018/5/8,74,3.未梦想的需求: (系统架构师层面,找到最佳的技术解决方案) 用户对技术解决方案永远都不是擅长的,因此他们无法构想出对其工作产生革新性变化的解决方案。这就需要通过需求分析人员在对问题域充分利用的基础上,选择合适的技术方案,才可能创造出用户未梦想到的功能,成为优秀的需求分析人员 。即:善于利用技术为用户创造全新体验是优秀需求人员的特质。,2018/5/8,75,案例:小宁为一个房产中介公司开发一套信息管理系统,访谈过程中,房产经纪人代表告诉他:“我以前是准备了两个本子,一个记录房源信息,一个记录客源信息,以便查找匹配的机会。但是现在

31、客户多了就产生问题了,一是记录很麻烦,二是查找很困难。”小宁心想很简单嘛,创建两张数据库表,一个保存房源信息,另一个保存客源信息,然后再开发一个数据查询功能,这样就解决问题了。,于是很肯定的告诉这位房产经纪人说:“我知道了,没问题!”这就是意识到的需求,用户能够清晰地表示出来。但是小宁却没有进一步分析,会产生问题吗?,2018/5/8,76,当系统开发完成并交付使用之后,没过多久这位房产经纪人就来找小宁,提出了这样的一个需求:现在系统提供的是一组查询,我希望改成多组查询。“啊!那你直接查询多次不就可以了吗?”小宁不解地问。“不行,那样不方便使用!因为查询结果没有合并在一起!”“为什么要把不同次

32、的查询结果合并在一起呢?”小宁还是想不通。这就是无意识需求搞的鬼!小宁不了解这行所以想不通,实际上这位房产经纪人提出这个需求的原因是客户对房源的要求是多样化的,他可能需要的是某路段的两房或另一路段的三房,经常是无法用一组查询条件将它们结合在一起。而以前在本子上查找,人的脑子是完全可以记录多组条件的。,2018/5/8,77,接到这个需求后,小宁找到公司的老张,问他:“你说这种需求我们应不应该响应?”老张给小宁一个建议:“我建议你增加一个记录销售线索的数据库表,每当新增加一个房源或客源时,就自动生成响应的销售线索,这样你就可以告诉他连查询都不需要使用了!”未梦想的需求,2018/5/8,78,3

33、.7.1.4破解阻碍需求捕获的心理现象,1.言过其实心理 解决方案 1)用户言过其实时的表现:表述都非常肯定的语气,十分流畅。因为此时他只需创造,而不需要回忆。 2)验证;因为在没有串供的情况下,天下谎言皆不同 验证有谎言存在时,解决方案 1 ) 差异展现法: 把不同用户的不同表述展示给中层后,找共识 2 )瓶颈分析法 对流程执行过程中的瓶颈进行分析(如都需经理审批),避免流程瓶颈导致系统无法顺利运转,2018/5/8,79,案例:有一次,小李在开发一个物资管理系统的时候就遇到了这样的一个用户。在谈及物资管理的基本单位时,这位用户说:“我们的设备价值都比较高,看起来不起眼的东西都动辄几千块,甚

34、至上万块!因此必须采用按个管理的模式,每个设备都将拥有一个唯一的ID,系统需要能够对其整个生命周期进行跟踪。”可是当系统实施后,却一直使用不起来。后来才发现,虽然这些物资、设备的价值不菲,但量却也不少,而且很多是备件,因此调配很频繁。再加上人手不足,所以不管是主观还是客观上,都很难做到按个管理。小结:用户“言过其实”。无法确定是否真正言过其实,采用验证手段。例如再找一个相关的用户代表来进行访谈。,2018/5/8,80,2.越俎代庖心理 识别正确的被访谈者最为关键 1)问题的层次是否正确 高层宏观、中层脉络问题、操作-细节 2)根据业务背景判断 3.非正事心理 解决方案:对访谈进行计划 4.抗

35、拒心理 激将法,倾听对方的抱怨是化敌为友的有效手段5.推卸责任心里让被访谈者介绍工作场景,2018/5/8,81,3.7.1.5不要忽视对变更可能的捕获,针对常见变更类型的类型 变更类型捕获问题流程变化快1.你们上次组织结构调整是什么时候?2.这个流程以前也是这样的吗?如果不一样,是什么时候的事呢?业务规则变化快1.这些规则是来自外部法规,还是内部制定的?2.如果是外部法规,这些法规通常几年会更新一次?3.如果是内部制定的,那么是由哪个部门制定的?依据什么进行调整?用户界面变化大1.用户界面设计一般由谁确定?2.你们最满意哪个系统的用户界面?3.你们最不喜欢哪个系统的用户界面?,2018/5/

36、8,82,3.7.1.6需求协商的要点,抛开立场,寻找利益 (卖二手车的交易谈判) (需求协商实例)天下没有荒唐的需求,每个 荒唐的需求背后都有合理的解释。只有荒唐的解决方案,没有荒唐的需求!协商的金钥匙“?”,2018/5/8,83,3.7.2需求获取的方法,用户访谈有效而直接的用户访谈技巧要求访谈者准备一个问题列表,目的是了解真实的问题和潜在的解决方案。专题讨论会专题讨论会可以减少一部分需求冲突,绕开纷繁的情况得到需求列表,以此作为进一步分析的基础。情节串联板制作情节串联板就是使用工具向用户说明系统如何适应组织的需要,并表明系统将如何运转。情节串联板的类型包括被动式、主动式和交互式,其复杂

37、度依次递增。,2018/5/8,84,3.7.2.1用户访谈,有效而直接的用户访谈技巧要求访谈者准备一个问题列表,目的是了解真实的问题和潜在的解决方案。 为了尽可能获得没有偏见的答案,需要确保提出的问题与背景无关(Context Free)。问题列表,2018/5/8,85,优缺点和访问时机用户访谈的类型时间安排记录工作访谈的沟通技巧,用户访谈,2018/5/8,86,1.优缺点和使用时机优点是直接有效、形式灵活、交流深入的宽带通信形式(有文字、有声音、有图像)。缺点:占用时间长:通常要访谈的人比较多,语言交流会占用大量时间。信息存在片面性:用户代表经常各执一词,导致收集的信息无法代表所有用户

38、的想法,从而导致偏差的出现。用户访谈是需求获取中的主要技术,只要有可能,就应该尽可能多地进行用户访谈。,用户访谈,2018/5/8,87,2.用户访谈的类型根据被访谈者的不同,可以将用户访谈分成不同的类型;而在需求获取阶段最常见的被仿谈者包括高层管理人员、中层管理人员、操作层、技术团队4类。,用户访谈,2018/5/8,88,3.用户访谈的时空安排一般建议不超过1小时,否则可以考虑中场休息或安排下一次面谈。时间安排:地点选择:适当的不受干扰和避免打扰,用户访谈,2018/5/8,89,4.用户访谈中的记录工作自己做笔记(分神)专门一同事做笔记(成本高)录音 (失去身体语言)录像(难操作)自己做

39、笔记+录音,用户访谈,2018/5/8,90,5.用户访谈中的沟通技巧制作访谈问卷并事先发给被访谈者 把握语言节奏 有效结合不同的问题类型 善于安排问题顺序注意沟通细节,用户访谈,2018/5/8,91,制作访谈问卷并事先发给被访谈者 在访谈前整理一份访谈计划,罗列出要问的问题,然后预先发送给被访谈者,以便对方能够更好地做好相关资料的准备。发送访谈计划时,应该记住一个时间原则:2天前,1周内!使问卷表尽可能的简短。通常,一个问卷表包含的问题不超过10-15个。估计回答问题需要的时间。确保问题是前后一致的,没有让人含混的理解为了保证不会理解含混,让与回答者关系密切的人员来进行问卷调查,并保证他们

40、对问题的理解是正确的。在制订问题前,先确定你需要得到怎样的答案分别列出所有可能的答案确保所有的需求能被问题覆盖。最后,剔除掉与需求无关的问题。,用户访谈技巧:基础篇,2018/5/8,92,用户访谈技巧:语言篇,把握语言节奏语言简单:短兵相接,句式简明说话限制在2033%以内问术语含义:你对xx是如何解释的?,2018/5/8,93,用户访谈技巧:语言篇,有效利用各种问题的特点可以使用的问题类型有3种:封闭式问题(判断题)半封闭式问题(选择题)开放式问题(简答题),2018/5/8,94,用户访谈技巧:语言篇,开放式问题被访谈者在回答问题时没有任何限制,答复可能是两个词,也可能是一段话,因此通

41、常理解为简答题。例如:用户提交一个申请后,会进行怎样的处理?优点:能够让被访谈者感到更自在、更有兴趣;能够反馈更丰富的信息;允许更多的自发性;访谈者也更容易措词。缺点:会产生太多不相干的细节;访谈过程可能失控;回答内容需花费大量时间提取有用信息。,2018/5/8,95,用户访谈技巧:语言篇,封闭式和半封闭式问题都属于封闭式问题范畴,给被访谈者一个明确的答案范畴,让他从几个候选答案中选择一个。半封闭式问题是指提供了多个选项。“选择题”封闭式问题则是两极式问题,例如是或不是、真或假、同意或不同意。“判断题”优点:节省时间;容易切中要点;易于对不同被访者的回答进行比较;可以保持对访谈过程的控制;在

42、探讨大范围问题时更快速;可以得到更贴切的数据。缺点:容易使被访谈者感到厌烦,无法得到丰富的细节,易于失去主要思想,不利于双方友好关系的建立。,2018/5/8,96,三种问题的比较访谈中应尽可能采用开放式问题作为主体,而在开场时、访谈出现僵局时就应该通过封闭式、半封闭式问题来缓解。,2018/5/8,97,用户访谈技巧:语言篇(善于安排问题顺序),正金字塔探索 倒金字塔聚焦、破局,2018/5/8,98,用户访谈技巧:体态篇(注意沟通细节),避免出一些干扰访谈的不良暗示:1)我的时间比你宝贵眼神不聚焦,看表2)不知道你在说什么、做什么不良打断 暂停时打断 断点恢复基本的体态语言,2018/5/

43、8,99,用户访谈技巧:体态篇,有趣的体态语言:座位里的奥秘:,助手,用户,访谈,对抗,2018/5/8,100,用户访谈技巧:计划篇,高层访谈 1) 准备:发现的问题、认为的机会抛砖引玉 2)产物:目标、主要业务范围中层访谈 1) 准备:业务事件列表、预构思的管控点列表 2) 产物:流程图、领域类图片段、用例图片段、 细化后的管控点列表,Stakeholder关注点操作层访谈: 1) 准备:业务活动列表、各类细节问题 2)产物:事件流(上下文)、问题(Why)、原始需求(What),2018/5/8,101,用户访谈计划表,用户访谈计划示例,2018/5/8,102,用户调查,利:面广,能获

44、得更多用户的反馈。弊:不够深入,易形而上学。要点:结合用户访谈技术使用1) 先访谈,后调查验证访谈结果2)先调查,后访谈理清方向时机:1) 跨地域用户流程级差异2)大样本用户细节差异价值:搜索某项假设的统计依据(主) 获取意见与建议(次),2018/5/8,103,用户调查的困难与应对,相关的问题不能事先决定先访谈,后调查问题会对答案会造成偏颇尽量避免使用简单的判断题,用选择、排序代替难以继续用户的模糊响应需求调查应实名制,2018/5/8,104,调查问卷设计要点,篇幅与布局1.由易到难2.逻辑相关性3.控制在13页内问题类型选择1.封闭性问题半封闭性问题2.开放性问题:跟随策略简短小技巧:

45、1.C现象 2.D现象,2018/5/8,105,案例:,20世纪可口可乐公司在计划更新可口可乐的配方时做了一次调查,其中一个问题是:你喜欢新口味的可口可乐吗?喜欢 不喜欢 无所谓调查结果显示:有百分之九十几的被调查者喜欢,因此高层就决定停产旧配方,但市场却最终投入反对票!问题出在哪呢?当然问题很多,但这个问题的设计就是原因之一。这个封闭式的问题诱导了用户,更合适的方法是改成一个半封闭式问题,使用户的意愿更容易表达出来:请根据你的喜爱程度对以下饮料进行排序:老口味可口可乐新口味可口可乐百事可乐 七喜美年达,2018/5/8,106,案例:当你想了解被调查喜欢什么样的运动时,就应该采用如下所示的

46、问卷设计方式:你喜欢什么运动(可多选)足球 篮球 围棋器械其他(请写出) 。,2018/5/8,107,用户调查问卷的分析要点,筛除无效问卷:存在大量空白连续出现相同的答案对问卷填写人进行分类实名制对回复模糊不清,有明显差异的问卷进行针对性访谈,了解其背后的原因,2018/5/8,108,用户访谈的五个阶段,准备访谈 计划和安排访谈日程 访谈开始和结束引导访谈后续的访谈整理工作,2018/5/8,109,3.7.2.2专题讨论会,常见的专题讨论会专题讨论会模板,2018/5/8,110,需求专题讨论会,需求专题讨论会 项目主要风险承担人在短暂而紧凑的时间段内集中在一起,一般为1 至2 天,与会

47、者可以在应用需求上达成共识、对操作过程尽快取得统一意见。优点 协助建立一支高效的团队,围绕项目成功的目标; 所有的风险承担人都畅所欲言; 促进风险承担人和开发团队之间达成共识; 揭露和解决那些妨碍项目成功的行政问题; 能够很快地产生初步的系统定义。,2018/5/8,111,专题讨论会,利:客户、需求、开发人员直接的头脑风暴,可击破双方盲点弊:成本高,如果缺乏控制会变成一次闲扯大会要点:需要有一个经验丰富、能够把控大局的主持人,2018/5/8,112,需求专题讨论会,专题讨论会准备 参加会议人员:主持人、用户、技术人员、项目组人员 安排日程:通常在具有相应支持设备的专用房间进行举行会议 可能出现行政间的责备或冲突,主持人应掌握讨论气氛并 控制会场。 会议最重要的部分是自由讨论阶段,这种技术非常符合专 题讨论会的气氛,并且营造一种创造性的和积极的氛围, 同时可以获得所有相关者的意见。 注意分配会议时间,记录所有言论。,2018/5/8,113,会前有准备,准备气氛:1)推销概念:邀请函2)后勤保障:提升现场重视度准备人员:该来的人要请到,不该来的人不要来准备材料:在开会前散发资料 项目专有信息:需求文件草案、已排序的特性 摆脱束缚思想的:创新方法、自由讨论规则 2天1周内散发,太早会使人忘记!,

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 企业管理 > 经营企划

本站链接:文库   一言   我酷   合作


客服QQ:2549714901微博号:道客多多官方知乎号:道客多多

经营许可证编号: 粤ICP备2021046453号世界地图

道客多多©版权所有2020-2025营业执照举报