欢迎来到淘文阁 - 分享文档赚钱的网站! | 帮助中心 好文档才是您的得力助手!
淘文阁 - 分享文档赚钱的网站
全部分类
  • 研究报告>
  • 管理文献>
  • 标准材料>
  • 技术资料>
  • 教育专区>
  • 应用文书>
  • 生活休闲>
  • 考试试题>
  • pptx模板>
  • 工商注册>
  • 期刊短文>
  • 图片设计>
  • ImageVerifierCode 换一换

    第3章_需求获取.ppt

    • 资源ID:70679879       资源大小:6.03MB        全文页数:157页
    • 资源格式: PPT        下载积分:16金币
    快捷下载 游客一键下载
    会员登录下载
    微信登录下载
    三方登录下载: 微信开放平台登录   QQ登录  
    二维码
    微信扫一扫登录
    下载资源需要16金币
    邮箱/手机:
    温馨提示:
    快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
    如填写123,账号就是123,密码也是123。
    支付方式: 支付宝    微信支付   
    验证码:   换一换

     
    账号:
    密码:
    验证码:   换一换
      忘记密码?
        
    友情提示
    2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
    3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
    4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。
    5、试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。

    第3章_需求获取.ppt

    第3章 需求获取1第3章 需求获取软件需求获取(简称需求获取)阶段的任务简单的说就是获取用户的需求信息。其过程如左图所示:确定非功能需求和约束条件实地收集用户需求信息确定调查对象建立项目范围和目标确定需求开发计划2第3章 需求获取3.1确定需求开发计划确定需求开发计划3.2确定项目的目标和范围确定项目的目标和范围3.3确定调查对象确定调查对象3.4实地收集需求信息实地收集需求信息3.5确定非功能需求确定非功能需求3.6在收集需求信息中应注意的问题在收集需求信息中应注意的问题3.7使用场景技术的需求获取使用场景技术的需求获取33.1确定需求开发计划确定需求开发计划确定需求开发计划的基本任务是确定需求开发的实施步骤,并给出收集需求活动的具体安排和进度。需求开发计划需要注意以下几点:(1)只考虑与需求开发相关的工作;(2)应考虑困难性和灵活性;(3)应考虑书写和整理需求规格说明及其文档所花费的时间。43.2确定项目的目标和范围确定项目的目标和范围此阶段的基本任务是根据项目目标把项目相关人员定位到一个共同的和明确的方向上,并决定软件系统的范围。项目的范围与项目的目标特别是软件系统的目标需求是密切相关的。53.2确定项目的目标和范围确定项目的目标和范围在收集目标需求时,目标需求会来源于各个不同的人,这些人对要开发的软件系统及该系统最终能为用户或客户提供哪些价值有比较清楚的了解。63.3确定调查对象确定调查对象本阶段的基本任务是明确地确定来自不同层次的需求来源和用户,并将其分类。应根据需求的层次来区分不同的用户:(1)提出目标需求的用户;(2)提出业务需求和功能需求的用户;(3)软件开发人员,主要是指系统分析员。73.3确定调查对象确定调查对象软件系统面临的用户是很多的,而这些用户由于所在的部门、职责和掌握的知识不同而存在差异,为了避免忽视和遗漏某些用户的情况,可以根据用户的某些方面将用户分类。83.3确定调查对象确定调查对象在将用户分类后,在分类的基础上进一步寻找每类用户的代表或联络人,这些人代表了一个特定的用户类,并可充当该用户类与开发人员之间的“窗口”。这些人也必须是真正的用户,而不是单纯的代理人。93.3确定调查对象确定调查对象表3.1 用户代表的义务1)给分析人员讲解业务及说明业务方面的术语等专业问题。2)抽出时间清楚地说明需求并不断完善。3)当说明系统需求时,力求准确详细。4)需要时要及时对需求做出决策。5)要尊重开发人员的成本估算和对需求的可行性分析。6)对单项需求、系统特性或用例划分优先级。7)评审需求文档和原型。8)一旦知道要对项目需求进行变更,要马上与开发人员联系9)在要求需求变更时,应遵照开发组织确定的工作过程来处理。10)尊重需求工程中开发人员采用的流程(过程)。103.3确定调查对象确定调查对象软件需求可来自与各个方面,而且用户类也不一定都是指人。有时也可以把其它应用系统或计算机硬件设备和接口等视为附加的用户类成员,这样就可确定软件系统与哪些外部应用系统或计算机硬件相关的需求。这就是说需求信息来源除了来自用户类外,还可来自于其它方面。113.3确定调查对象确定调查对象几个典型的软件需求来源:1.直接和间接使用软件系统的用户;2.系统需求规格说明;3.市场调查和用户问卷调查;4.已开发出的和待开发的同类软件系统的描述和文档;5.对人工系统的存在问题的报告和增强要求;6.观察正在工作的用户;7.用户工作内容的分析。123.3确定调查对象确定调查对象当确定了用户类及明确了用户需求的主要来源后,这样就可从不同的渠道和不同的人那里收集到大量的需求信息。但这些需求信息既包含了明确的用户需求,也包含了一些不一致和含糊的需求,而且软件开发人员也难以解决。因此,这就需要寻找需求的决策者。在处理有问题的需求信息时,决策者并不是固定不变的,而是根据实际中可能发生的具体问题来确定。133.4实地收集需求信息实地收集需求信息在确定了需求的来源和调查对象后,下一步就是实地收集需求信息。实地收集需求信息阶段的任务就是到现场实地调查和与用户交流,收集和理解用户需求信息。143.4实地收集需求信息实地收集需求信息实地收集需求信息可能面临的困难:1.能提出软件需求的用户可能觉得他们没有充分的时间与开发人员进行交流和讨论;2.有时用户希望通过简单的方法和说明,或者通过简单回答开发人员的询问后,软件开发人员就能清楚地理解他们的需求,而不需要花费太多的时间进行讨论;153.4实地收集需求信息实地收集需求信息3.用户和开发人员都只考虑自己的利益;如:有些用户由于缺乏使用计算机的经验,导致产生畏难情绪;有些用户认为开发软件系统自己的关系不大,对待需求信息的收集工作采取消极的态度。4.用户本身不能提出明确的需求;5.开发人员缺乏用户的业务知识,而用户也缺乏计算机方面的知识,导致双方在交流中产生许多的困难,以至收集工作难以进行。163.4实地收集需求信息实地收集需求信息实地调查的步骤:1.向掌握“全局”的负责人调查;2.向部门负责人调查;3.向业务人员调查。步骤(2)和步骤(3)是一个反复的过程,而且每次调查之前要制定调查提纲,每次调查要作记录,并交由用户审查核实,以保证需求信息的可靠和准确。173.4实地收集需求信息实地收集需求信息实地收集需求信息的方式1.以座谈会的方式;2.以书面咨询的方式;3.利用用例表示方法。183.4实地收集需求信息实地收集需求信息需求信息可大致分类如下:1.目标需求;2.用例说明;3.业务规则;4.功能需求;5.性能需求;6.外部接口需求;7.限制 8.数据定义;9.解决思想。193.5确定非功能需求确定非功能需求非功能需求是衡量软件能良好运行的定性指标。由于缺乏定量指标,因此很难根据这些需求来评价软件系统,这也是开发出来的软件系统与用户所满足的软件系统之间存在差异的主要原因。203.5确定非功能需求确定非功能需求用户所关心的非功能需求主要有:n可靠性;n可扩充性;n安全性;n互操作性;n健壮性;n易使用性;n可维护性 n可移植性;n可重用性。213.5确定非功能需求确定非功能需求在收集非功能需求信息时常用的方法:1.将不同用户类代表提出的可能很重要的非功能需求进行综合,并根据其中的每个需求设计出许多方法,然后根据用户的回答,使这些需求更明确化;2.开发人员与用户一起对每一个非功能需求制定可测试和可验证的具体标准;3.设计与非功能需求相冲突的假设示例,利用反例来提示用户。223.6 需求定义(RUP模型)23关键五步:来源RUP的智慧在问题定义上达成共识理解根本原因问题背后的问题确定Stakeholder和用户定义解决方案系统的界限确定加在解决方案上的约束目标Stakeholder范围约束24寻找客户的需求 n了解用户需求的第一步是在有关问题的定义上和用户达成一致。n用户陈述的问题往往是表面现象,我们有必要和用户一起挖掘出问题背后的问题,即找出问题的根源,从而从根本上解决问题。n确定系统的涉众,除了开发团队和用户等直接涉众,我们还要找到间接的涉众。n系统边界确定了我们系统的内涵,即它究竟包括哪些功能,可以解决哪些问题。n确定解决方案的约束条件。253.6.1在问题定义上达成共识 描述问题的模版 所谓的问题分析,就是理解真实世界中的问题和用户需求并提出满足这些多方面的解决方案的过程。第一步是把问题拿出来,达到所有人的共识,采用统一的格式,RUP为问题定义提供了统一的模板,如下:26n下表是一个银行信用卡机构整理的问题定义描述问题定义示例项目内容问题竞争性的市场使一家金融组织意识到,它必须开始利用日常交易中包含的大量信息。企业的资产很多,但它还具备预测信用卡使用情况和利润率的情况。影响信用卡部结果在信用卡营销方面针对性不强,导致利润降低优点有效标识出用户特点与信用卡使用情况的关系;标识出利润率较高的用户群体。27问题定义技巧:转换n马的遍历问题:寻找一系列的移动步骤,使马走完每个方块,而落入任何一个方块有且只有一次28问题定义技巧:本源n问题:日内瓦湖上的山脉中建成了一条很长的汽车隧道,为了防止停电时发生灾难,必须提醒司机进入隧道之前把车灯打开。n解决方案一:“警告!前有隧道请打开车头灯警告!前有隧道请打开车头灯”n新问题:隧道出口风景很美,返回时发现汽车没电忘了关车头灯!n解决方案二:出口处立标牌出口处立标牌“关掉车灯关掉车灯”n新问题:夜行车也会关掉车灯?29n案例:n小林在一次电子政务项目中遇到了这样一个问题,用户要求对每个政务申请的各种处理都需要记录时间。由于他们选择的是C/S结构,因此取时间时就遇到问题,每台机器上的时间都不尽相同。n“不就是时间不统一吗,让所有客户端登录时先从时间服务器上取一个时间就搞定了!”n但这个方案在实际的运行时却带来了不小的麻烦,由于时间服务器写的不够稳定,经常会自动退出,当这种情况出现客户端软件就根本无法进入,严重影响了客户的正常使用。在确定某问题的解决方案时,思考是否引发新问题在确定某问题的解决方案时,思考是否引发新问题30问题定义技巧:本源n解决方案三:建充电站建充电站n新问题:维护开支大,充电站也会坏n解决方案四:授权私人经营充电站授权私人经营充电站n新问题:风景区商业化,政府与游客均不接受31直接修改错误,不要用其他方案来弥补错误直接修改错误,不要用其他方案来弥补错误n案例:n在小程负责的一个客户关系管理系统项目中,用户在使用了一段时间之后提出了这样一个问题:客户数据库的数据比较乱,有重名、同客户多条记录等现象。n小程毫不犹豫地说:“没关系,我可以为你们开发一个功能强大的客户数据清理工具,通过工具可以自动识别出这些混乱的数据,并且提供一些合并、汇总、删除功能”。n随着这个功能的开发,项目的范围也不断扩展,针对这个功能的需求也层出不穷。这就是软件开发过程中的“充电站”,成本付出了,但真的对项目有好处么?n这样做,似乎很多人会举手赞成,但是也付出了巨大的成本。如果我们细究一些,这个问题是怎么产生的呢?为什么数据会混乱呢?32n解决方案五:在隧道尽头,树立新标牌 如果是白天,并且车灯开着,请熄灭车灯;如果是白天,并且车灯开着,请熄灭车灯;如果天色已晚,并且车灯没开,请打开车灯;如果天色已晚,并且车灯没开,请打开车灯;如果是白天,并且车灯没打,就别打开它;如果是白天,并且车灯没打,就别打开它;如果天色已晚,并且车灯开着,请别关掉它。如果天色已晚,并且车灯开着,请别关掉它。n新问题:谁能在行驶时读完?!问题定义技巧:本源33n在软件开发中,例如安装过程中的向导就是此类例子:明知道大家都是闭着眼睛点击“下一步”按钮的,那么为什么还要不断重复这样的设计呢?这难道不就是一个蹩脚的标牌吗?n如何解决?q关键在于对问题的定义,先确定到底存在什么样的问题?如下图分析:车没电司机忘关大灯缺乏提醒寻找问题的本源问题定义技巧:本源34n终极解决方案:q在出口处立标牌:你的灯亮着吗?你的灯亮着吗?问题定义技巧:本源35影响人群分析的技巧n问题定义时,还可以对影响人群进行分析,得出推断和结论。q文氏图分析解决方案人群 影响 人群?Internet用户 婴幼儿 母亲和 祖辈?实例:2006年投资开办母婴网站363.6.2了解问题产生的根本原因了解问题产生的根本原因n问题定义达成共识后,下一步分析问题背后的问题,也就是寻找问题的本源。n两种实用工具:q一种是定性分析的鱼骨图q一种是定量分析的帕累托图37鱼骨图n鱼骨图也称为因果鱼骨图,它是一种以直观的图形找出问题或现象的所有潜在原因的方法,它有利于追踪出问题的根源。n具有三个典型的好处:q使分析人员将问题的原因而不是症状放在首位。q提供了一种运用集体智慧解决问题的新方法。q直观、简明、易于操作。通常鱼骨图分析的过程会结合头脑风暴。38鱼骨图n绘制一个鱼骨图通常是一个团队在一起完成,具体步骤如下:q选择问题q头脑风暴q确定原因类型q分配原因q分析根本原因39n案例:开发一个在线图书借阅系统。传统的借书方式要求读者亲自来到图书馆,这显得非常不方便,而且随着藏书的增加和读者群的增长,大量的读者来到图书馆,使得图书馆的场地不足,工作人员也不够了。所以想到借助网络,让读者通过网络借/还书,这样可以节省大量的场地维护和工作人员成本支出,同时计算机可以方便地检索目录,让读者可以足不出户借到需要的书。为了把书送到借阅人手里,联系了快递公司,初步达成协议,由他们往返借阅人和图书馆之间,把图书送出和收回。读者在网上出示和验证借书卡,找到他们需要的书,提交申请,图书管理员确认后,就会通知快递公司来取书。当然在这个过程中,读者是需要付费的。还书基本上也是同样的过程。40鱼骨图n选择问题q首先必须选择一个具体的问题或结果。在选择问题时,要保证问题是专门的、定义严谨的、范围相对较小的,并且保证所有参与人员能够切实理解分析的内容。对于上一步定义出来的每个问题都应该进行一次独立的鱼骨图分析。q先将问题定义在白板或纸上写出来,画出第一层鱼骨,如图所示:41鱼骨图n头脑风暴q就导致问题的所有可能原因进行头脑风暴。如果在白板上进行,可以将大家提出的意见写在记事贴上,然后将它们贴到鱼骨图上。q注意:不能将原因和解决方案混为一谈。头脑风暴法(Brain StormingBS):一种通过集思广益、发挥团体智慧,从各种不同角度找出问题所有原因或构成要素的会议方法。BS有四大原则:严禁批评、自由奔放、多多益善、搭便车。42鱼骨图n确定原因类型q对头脑风暴的结果进行整理,确定出主要的原因类型。q经常使用的类型:人、设备、材料、环境、方法或过程。(划分出来的类型不应该超过6种)q将这些类型补充到鱼骨图上。43鱼骨图n分配原因q把头脑风暴得出的潜在原因放在鱼骨图中,并且确保每一项原因都归类于适当的类别中。如果原因看起来可以放在多个类别中,就表示它是一个多重原因:这种情况多次出现,就表示这个分类有问题,应重新考虑分类是否合适。q相关的原因在组织时是可以分级整理的,可以通过提出“是什么?”、“为什么?”、“怎么样?”、“在那里?”等问题来进一步发展更细等级的原因。q注意:不要过于深究,否则陷入无尽的细节中,三层细节是图表的实际限制。44鱼骨图45鱼骨图n分析根本原因q接下来要对鱼骨图中罗列出来的所有潜在原因进行分析,考察造成某一结果的根本原因最有可能是什么,或者说哪些原因是最核心的,可以通过一些几个方面来考虑:n通过参与者之间的公开讨论来分享看法和经验;n寻找重复的原因,或与特定类别有关的原因的数目;n使用检查表收集资料、制作流程图或进行客户调查,通过帕累托图分析法测试各种原因的相对强度;n一旦对一小部分主要原因达成一致意见,就可以用成对比较法进一步缩小范围;n有时只考虑那些能够影响到的因素是有好处的。46鱼骨图n小结q鱼骨图是一种因果分析工具,它在需求定义、项目管理、过程改进等活动中都是很有价值工作,可以用来:n关注原因而非表面的症状;n获取一个群体的集体知识和经验;n提供了展现导致问题发生的所有原因和全景图;n为进一步收集资料和行动提供了坚实的基础。47n定量分析n帕累托80/20原则q百分之八十的问题是百分之二十的原因所造成的。帕累托图在项目管理中主要用来找出产生大多数问题的关键原因,用来解决大多数问题。n几个方面的作用q为80%的问题找到关键的20%的原因;q一目了然地显示出每个原因的相对重要程度;q有助于预防在解决了一些问题后,却使另外一些问题变得更糟的情况。帕累托图(Pareto Chart)482-8 原则*Walker Royce扩展了Barry Boehm提出的有关软件项目管理的“二八定理”,构成了现代软件管理过程框架的理论基础n 80%的工程活动是由20%的需求消耗的n 80%的软件成本是由20%的构件消耗的n 80%的缺陷是由20%的构件引起的n 80%的软件废品和返工是由20%的缺陷引起的n 80%的资源是由20%的构件消耗的n 80%的工程活动是通过20%的工具完成的n 80%的进展是20%的人完成的49帕累托图(Pareto Chart)503.6.3确定涉众和用户 n涉众(stakeholder),在软件开发项目中主要是指和这个项目有密切相关利益的人,他们共同感兴趣的就是需求分析阶段。这些涉众包括客户、用户、业务或需求分析员(负责收集客户需求并编写文档,以及负责客户与开发机构之间联系沟通的人)、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。51解析stakeholdern简单的项目健康评价方法q问项目经理一个这样的问题:你们的团队和哪一层客户打交道最多?n如果答案是操作层,那么很遗憾,你的项目出现延误的可能性极大,几乎是难以避免的;其中原因很简单,操作层手中的筹码相对来说是很少的,可能只是几个铜板。n如果答案是中层管理人员,那么只要在项目过程中尽力,是有希望避免出现延误情况的,至少延误的比率相对较低;原因是中层手中有一定的筹码,加上人数较操作层少很多。n如果答案是高层管理人员,那么恭喜你,项目出现延误的可能性几乎是没有的;高层管理人员手握着最有分量的筹码,而且人数极少。52确定涉众的问题举例确定涉众的问题举例 53案例:在线图书借阅系统中的涉众 543.6.4 确定系统的界限 n定义系统的关键首先是要给出系统的边界。该边界把我们的系统和外部世界一分为二,换言之,系统边界确定了我们系统的内涵,即它究竟包括哪些功能,可以解决哪些问题。我们可以根据确定的系统边界给出系统的环境模型。它指出了我们的系统以及其它和它交户的系统之间的关系。n绝大部分书籍推荐使用上下文关系图来确定系统范围,实际上就是 数据流图中的顶层图。55在线图书借阅系统的界限563.6.5确定解决方案的约束条件 n潜在的系统约束 57到期催还功能的约束分析 583.6.6 实例n问题描述:n一家制造和网上邮购物品公司,制造和销售家用物品和个人用品。由于公司发现效益太差的问题,采用了全质量管理(TQM)来解决问题。公司量化了非质量成本之后,怀疑生产浪费即“废品”是最主要原因。59n效益太差,找出“废品”的根本原因n鱼骨图:根本原因的鱼骨图理解根本原因-问题背后的问题60根本原因的帕雷托图原因数量比例制造缺陷294.83%制成品折旧457.50%订单不准确31752.83%用户退货8213.67%运输损耗10717.83%其他203.34%合计600100%n帕累托图 1)确定问题与原因 2)收集数据 3)绘制直方图理解根本原因-问题背后的问题61n发现了一条根本原因:“不准确的销售订单”产生了半数的废品。发现已有的订单系统有一个不友好的用户界面,没有在线差错处理机制,那么,开发一个新系统是减少废品的最好办法。n一旦我们确定不准确的订单是一个值得解决的根本原因之后,我们就可以生成一个如下表所示的订单系统问题的称述。62销售订单问题陈述表要素要素描述描述问题不准确的销售订单影响订单操作者、客户、生产者、销售者以及客户服务结果增加废品、额外的处理成本、客户不满意以及收益低优点解决这一问题的新系统有如下优点:n增加了输入点订单的准确性n增加了销售数据的报告,以便进行管理n更好的效益63n确定涉众和用户用户用户其他风险承担人其他风险承担人销售订单输入员MIS主管以及开发团队销售订单监督员首席财务官生成控制人员生成管理人员票据文员确定风险承担人和用户64n订单系统的简化系统透视定义解决方案系统的范围65确定解决方案的约束条件销售订单输入系统的约束、约束源及理由销售订单输入系统的约束、约束源及理由约束源约束源约束约束理由理由操作性销售订单数据的一份完全备份必须被保存在已有系统的数据库中一年的时间数据丢失的风险太大,所以我们要并行运行至少一年的时间系统及操作系统这个应用在服务器上不应该占用超过20M字节的空间服务器上可用的存储空间有限设备预算系统必须在已有的服务器和主机上开发;用户使用的新的客户端硬件可以被提供成本控制以及已有系统维护人员预算固定的人力资源;没有外部资源在现有预算下操作成本固定技术要求应用新的面向对象的方法相信这种技术的应用会增加生产率并增加软件的可靠性663.7 在收集需求信息中应注意的问题在收集需求信息中应注意的问题1.应能适当的调整收集范围;2.尽量把用户所持的假设解释清楚,特别是发生冲突的部分;3.尽量理解用户用于表达他们需求的思维过程,特别是尽量熟悉和掌握用户具有的一些专业知识和术语;4.在收集需求信息时,应尽量避免受不熟悉细节的影响;5.应尽量避免讨论一些具体的解决方案;6.需求信息收集工作的结束。673.7.1需求获取的策略n3.7.1.1需求获取应该是主动的需求获取应该是主动的q强调了需求分析人员在整个过程中应该充分发挥主动性。q需求获取是撒网打渔,不是休闲钓鱼。68钓鱼模式 vs.网罗模式比较钓鱼模式网罗模式心态 被动,愿者上钩主动,为了生计目标 没有计划,时间到就结束访谈是走过场要抓到足够的鱼一定要把计划问题问完地点 找个环境好的地方没预先计划访谈对象要找有鱼的地方选择合适的访谈对象对象 不管什么鱼,不管大鱼小鱼宏观、细节一把抓选择不同密度的网按访谈对象决定信息层次69案例:“小张,你回来了”“唉,是呀!昨天赶晚班机回来的,到家都快两点了!”小张显得一脸的疲倦。“那你这次去客户那里了解到了什么情况?客户好像催你们过去催的很急呀!”小张面带笑容地回答说:“嗨,他们来了一个新的信息主管,要和我们聊聊这个系统的规划和想法,也没有什么实质的东西,就是东拉拉西扯扯的!最大的作用就是混了个脸熟。”q结论:需求获取活动很低效。问题关键在于需求分析人员是否善于去把握主动权,是否能够根据每次访谈的对象制定相应的计划。703.7.1.2需求获取应该是聚焦的需求获取应该是聚焦的 n捕获过程中的问题:q提不出需求 q提的需求太多 n解决方案:提出聚焦的问题71需求获取应该是聚焦的 q案例:老李和小赵是某软件公司的需求分析人员,有一次他们共同参与了一个设备告警监控平台项目。他俩分别对监控中心的小徐和小张进行了访谈。q小赵问监控中心的小张:“你对这个系统有什么需求?”q小张说:“我想到的功能包括值班日志、告警的声光提示、基于短信的告警通知,还有要为值班人员提供一个日程安排工具、一个共享文件管理工具,还要能够自动填报各种上级要的报表”。q而老李问小徐的问题有很大的区别:当监控中心收到一个告警的时候,希望以什么形式体现?收到后,你们一般会进行什么样的处理?在这个过程中需要做什么配套工作?原来处理时存在什么困难?有哪些问题是比较棘手的?q小结:案例场景中,小张提问方法导致整个捕获过程发散的,而老李就能够使整个问题很聚焦,这样产生镀金需求、非重要需求的可能性大大下降。723.7.1.3破解需求的冰山模型n用户的需求是一个冰山,有很大一部分信息是埋藏在海平面之下的,对需求获取工作带来困扰。n冰山可分为三层,如右图所示q1.意识到的需求:(用户层面)位于海平面之上,用户自己能够设想到的需求,(大量的需求以变更的形式出现)q2.无意识的需求:(开发者层面)实际的工作场景,开发者能够对场景“感同身受”的话,那么就可以大大减少变更的数量,需加强业务知识的捕获。73n3.未梦想的需求:q(系统架构师层面,找到最佳的技术解决方案)q用户对技术解决方案永远都不是擅长的,因此他们无法构想出对其工作产生革新性变化的解决方案。这就需要通过需求分析人员在对问题域充分利用的基础上,选择合适的技术方案,才可能创造出用户未梦想到的功能,成为优秀的需求分析人员。q即:善于利用技术为用户创造全新体验是优秀需求人员的特质。74n案例:小宁为一个房产中介公司开发一套信息管理系统,访谈过程中,房产经纪人代表告诉他:“我以前是准备了两个本子,一个记录房源信息,一个记录客源信息,以便查找匹配的机会。但是现在客户多了就产生问题了,一是记录很麻烦,二是查找很困难。”n小宁心想很简单嘛,创建两张数据库表,一个保存房源信息,另一个保存客源信息,然后再开发一个数据查询功能,这样就解决问题了。,于是很肯定的告诉这位房产经纪人说:“我知道了,没问题!”n这就是意识到的需求,用户能够清晰地表示出来。但是小宁却没有进一步分析,会产生问题吗?75n当系统开发完成并交付使用之后,没过多久这位房产经纪人就来找小宁,提出了这样的一个需求:现在系统提供的是一组查询,我希望改成多组查询。n“啊!那你直接查询多次不就可以了吗?”小宁不解地问。n“不行,那样不方便使用!因为查询结果没有合并在一起!”n“为什么要把不同次的查询结果合并在一起呢?”小宁还是想不通。n这就是无意识需求搞的鬼!小宁不了解这行所以想不通,实际上这位房产经纪人提出这个需求的原因是客户对房源的要求是多样化的,他可能需要的是某路段的两房或另一路段的三房,经常是无法用一组查询条件将它们结合在一起。而以前在本子上查找,人的脑子是完全可以记录多组条件的。76n接到这个需求后,小宁找到公司的老张,问他:“你说这种需求我们应不应该响应?”n老张给小宁一个建议:“我建议你增加一个记录销售线索的数据库表,每当新增加一个房源或客源时,就自动生成响应的销售线索,这样你就可以告诉他连查询都不需要使用了!”n未梦想的需求773.7.1.4破解阻碍需求捕获的心理现象 n1.言过其实心理 q解决方案 n1)用户言过其实时的表现:表述都非常肯定的语气,十分流畅。因为此时他只需创造,而不需要回忆。n2)验证;因为在没有串供的情况下,天下谎言皆不同 q验证有谎言存在时,解决方案 n1)差异展现法:q把不同用户的不同表述展示给中层后,找共识 n2)瓶颈分析法 q对流程执行过程中的瓶颈进行分析(如都需经理审批),避免流程瓶颈导致系统无法顺利运转 78n案例:有一次,小李在开发一个物资管理系统的时候就遇到了这样的一个用户。在谈及物资管理的基本单位时,这位用户说:“我们的设备价值都比较高,看起来不起眼的东西都动辄几千块,甚至上万块!因此必须采用按个管理的模式,每个设备都将拥有一个唯一的ID,系统需要能够对其整个生命周期进行跟踪。”n可是当系统实施后,却一直使用不起来。后来才发现,虽然这些物资、设备的价值不菲,但量却也不少,而且很多是备件,因此调配很频繁。再加上人手不足,所以不管是主观还是客观上,都很难做到按个管理。n小结:用户“言过其实”。无法确定是否真正言过其实,采用验证手段。例如再找一个相关的用户代表来进行访谈。79n2.越俎代庖心理 q识别正确的被访谈者最为关键 q1)问题的层次是否正确 n高层宏观、中层脉络问题、操作-细节 q2)根据业务背景判断 n3.非正事心理 q解决方案:对访谈进行计划 n4.抗拒心理 q激将法,倾听对方的抱怨是化敌为友的有效手段n5.推卸责任心里q让被访谈者介绍工作场景803.7.1.5不要忽视对变更可能的捕获不要忽视对变更可能的捕获 n针对常见变更类型的类型 q变更类型捕获问题流程变化快n1.你们上次组织结构调整是什么时候?n2.这个流程以前也是这样的吗?如果不一样,是什么时候的事呢?q业务规则变化快n1.这些规则是来自外部法规,还是内部制定的?n2.如果是外部法规,这些法规通常几年会更新一次?n3.如果是内部制定的,那么是由哪个部门制定的?依据什么进行调整?q用户界面变化大n1.用户界面设计一般由谁确定?n2.你们最满意哪个系统的用户界面?n3.你们最不喜欢哪个系统的用户界面?813.7.1.6需求协商的要点n抛开立场,寻找利益 (卖二手车的交易谈判)(需求协商实例)n天下没有荒唐的需求,每个 荒唐的需求背后都有合理的解释。n只有荒唐的解决方案,没有荒唐的需求!n协商的金钥匙“?”谈判谈判方方立场立场利益利益卖车人10000美元买到游艇买车人80009000美元买到车823.7.2需求获取的方法n用户访谈q有效而直接的用户访谈技巧要求访谈者准备一个问题列表,目的是了解真实的问题和潜在的解决方案。n专题讨论会q专题讨论会可以减少一部分需求冲突,绕开纷繁的情况得到需求列表,以此作为进一步分析的基础。n情节串联板q制作情节串联板就是使用工具向用户说明系统如何适应组织的需要,并表明系统将如何运转。情节串联板的类型包括被动式、主动式和交互式,其复杂度依次递增。833.7.2.1用户访谈用户访谈n有效而直接的用户访谈技巧要求访谈者准备一个问题列表,目的是了解真实的问题和潜在的解决方案。n为了尽可能获得没有偏见的答案,需要确保提出的问题与背景无关(Context Free)。问题列表84n优缺点和访问时机n用户访谈的类型n时间安排n记录工作n访谈的沟通技巧用户访谈用户访谈85n1.优缺点和使用时机q优点是直接有效、形式灵活、交流深入的宽带通信形式(有文字、有声音、有图像)。q缺点:n占用时间长:通常要访谈的人比较多,语言交流会占用大量时间。n信息存在片面性:用户代表经常各执一词,导致收集的信息无法代表所有用户的想法,从而导致偏差的出现。n用户访谈是需求获取中的主要技术,只要有可能,就应该尽可能多地进行用户访谈。用户访谈用户访谈86n2.用户访谈的类型q根据被访谈者的不同,可以将用户访谈分成不同的类型;而在需求获取阶段最常见的被仿谈者包括高层管理人员、中层管理人员、操作层、技术团队4类。被访谈者阶段话题中心目标高层管理人员 需求定义问题/机会探讨系统的目标与范围中层管理人员 需求捕获阶段一 业务事件理清需求的脉络信息操作层需求捕获阶段二 业务活动填充需求的细节技术团队需求捕获解决方案论证解决方案的可行性用户访谈用户访谈87n3.用户访谈的时空安排q一般建议不超过1小时,否则可以考虑中场休息或安排下一次面谈。n时间安排:n地点选择:适当的不受干扰和避免打扰用户访谈用户访谈88n4.用户访谈中的记录工作q自己做笔记(分神)q专门一同事做笔记(成本高)q录音(失去身体语言)q录像(难操作)q自己做笔记+录音用户访谈用户访谈89n5.用户访谈中的沟通技巧q制作访谈问卷并事先发给被访谈者 q把握语言节奏 q有效结合不同的问题类型 q善于安排问题顺序q注意沟通细节用户访谈用户访谈90n制作访谈问卷并事先发给被访谈者 q在访谈前整理一份访谈计划,罗列出要问的问题,然后预先发送给被访谈者,以便对方能够更好地做好相关资料的准备。q发送访谈计划时,应该记住一个时间原则:2天前,1周内!q使问卷表尽可能的简短。通常,一个问卷表包含的问题不超过10-15个。q估计回答问题需要的时间。q确保问题是前后一致的,没有让人含混的理解q为了保证不会理解含混,让与回答者关系密切的人员来进行问卷调查,并保证他们对问题的理解是正确的。q在制订问题前,先确定你需要得到怎样的答案q分别列出所有可能的答案q确保所有的需求能被问题覆盖。最后,剔除掉与需求无关的问题。用户访谈技巧:基础篇91用户访谈技巧:语言篇n把握语言节奏语言简单:短兵相接,句式简明短兵相接,句式简明说话限制在说话限制在2033%以内以内n问术语含义:你对xx是如何解释的?92用户访谈技巧:语言篇n有效利用各种问题的特点q可以使用的问题类型有3种:n封闭式问题(判断题)n半封闭式问题(选择题)n开放式问题(简答题)93用户访谈技巧:语言篇n开放式问题q被访谈者在回答问题时没有任何限制,答复可能是两个词,也可能是一段话,因此通常理解为简答题。q例如:用户提交一个申请后,会进行怎样的处理?q优点:能够让被访谈者感到更自在、更有兴趣;能够反馈更丰富的信息;允许更多的自发性;访谈者也更容易措词。q缺点:会产生太多不相干的细节;访谈过程可能失控;回答内容需花费大量时间提取有用信息。94用户访谈技巧:语言篇n封闭式和半封闭式问题q都属于封闭式问题范畴,给被访谈者一个明确的答案范畴,让他从几个候选答案中选择一个。q半封闭式问题是指提供了多个选项。“选择题”q封闭式问题则是两极式问题,例如是或不是、真或假、同意或不同意。“判断题”q优点:节省时间;容易切中要点;易于对不同被访者的回答进行比较;可以保持对访谈过程的控制;在探讨大范围问题时更快速;可以得到更贴切的数据。q缺点:容易使被访谈者感到厌烦,无法得到丰富的细节,易于失去主要思想,不利于双方友好关系的建立。95n三种问题的比较n访谈中应尽可能采用开放式问题作为主体,而在开场时、访谈出现僵局时就应该通过封闭式、半封闭式问题来缓解。比较项封闭式 半封闭式开放式信息收集有效性最弱较弱最强被访谈者回答难度 最简单 较简单较难对被访谈者诱导性 较容易 容易不会访谈所需时间节省节省可能会浪费信息的广度和尝试 较窄较窄较广96用户访谈技巧:语言篇(善于安排问题顺序)n正金字塔探索 倒金字塔聚焦、破局在库存管理方面有问题吗?这个问题表现在什么方面?你认为怎样才能解决这些问题呢?请概括一下,你认为怎样才能使库存管理更加有效你对新的物资管理系统有何看法?它在使用过程中会遇到什么障碍你最关心的障碍有哪些可用性问题关注吗?97用户访谈技巧:体态篇(注意沟通细节)n避免出一些干扰访谈的不良暗示:1)我的时间比你宝贵眼神不聚焦,看表2)不知道你在说什么、做什么不良打断 暂停时打断 断点恢复n基本的体态语言现象内涵语速极快、描述过程逻辑性强 1.用户很熟悉2.可能是理想化的语速缓慢、中间有很多的停顿 1.用户不够熟悉2.容易产生变化,需注意突然改变语气、脸色1.问题是对方很敏感的2.传递的信息有明显的误解98用户访谈技巧:体态篇现象内涵回答问题时眼珠常向左上方转动 很可能在回忆,信息相对真实回答问题时眼珠常向右上方转动 很可能在“创造”,真实性待确认坐姿很随意,诸如翘着二郎腿对访谈内容重视度不高回答比较强势,甚至有攻击性对信息系统的建设有反对意见或敌意身体或腿部晃动十分厉害情绪较不安n有趣的体态语言:n座位里的奥秘:助手用户访谈对抗99用户访谈技巧:计划篇n高层访谈 1)准备:发现的问题、认为的机会抛砖引玉 2)产物:目标、主要业务范围n中层访谈 1)准备:业务事件列表、预构思的管控点列表 2)产物:流程图、领域类图片段、用例图片段、细化后的管控点列表,Stakeholder关注点n操作层访谈:1)准备:业务活动列表、各类细节问题 2)产物:事件流(上下文)、问题(Why)、原始需求(What)100用户访谈计划表用户访谈计划示例101用户调查n利:面广,能获得更多用户的反馈。n弊:不够深入,易形而上学。n要点:结合用户访谈技术使用1)先访谈,后调查验证访谈结果2)先调查,后访谈理清方向n时机:1)跨地域用户流程级差异2)大样本用户细节差异n价值:搜索某项假设的统计依据搜索某项假设的统计依据(主主)获取意见与建议获取意见与建议(次次)102用户调查的困难与应对n相关的问题不能事先决定先访谈,后调查先访谈,后调查n问题会对答案会造成偏颇尽量避免使用简单的判断题尽量避免使用简单的判断题,用选择、排序,用选择、排序代替代替n难以继续用户的模糊响应需求调查应实名制需求调查应实名制103调查问卷设计要点n篇幅与布局1.由易到难2.逻辑相关性3.控制在13页内n问题类型选择1.封闭性问题半封闭性问题2.开放性问题:跟随策略简短n小技巧:1.C现象 2.D现象104案例:n20世纪可口可乐公司在计划更新可口可乐的配方时做了一次调查,其中一个问题是:你喜欢新口味的可口可乐吗?你喜欢新口味的可口可乐吗?喜欢喜欢 不喜欢不喜欢 无所谓无所谓调查结果显示:有百分之九十几的被调查者喜欢,因此高层就决定停产旧配方,但市场却最终投入反对票!问题出在哪呢?当然问题很多,但这个问题的设计就是原因之一。这个封闭式的问题诱导了用户,更合适的方法是改成一个半封闭式问题,使用户的意愿更容易表达出来:请根据你的喜爱程度对以下饮料进行排序:请根据你的喜爱程度对以下饮料进行排序:老口味可口可乐老口味可口可乐新口味可口可乐新口味可口可乐百事可乐百事可乐 七喜七喜 美年达美年达105n案例:n当你想了解被调查喜欢什么样的运动时,就应该采用如下所示的问卷设计方式:n你喜欢什么运动(可多选)n足球足球 篮球篮球 围棋围棋器械器械n其他(请写出)其他(请写出)。106用户调查问卷的分析要点n筛除无效问卷:q存在大量空白q连续出现相同的答案n对问卷填写人进行分类q实名制F对回复模糊不清,有明显差异的问

    注意事项

    本文(第3章_需求获取.ppt)为本站会员(hyn****60)主动上传,淘文阁 - 分享文档赚钱的网站仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知淘文阁 - 分享文档赚钱的网站(点击联系客服),我们立即给予删除!

    温馨提示:如果因为网速或其他原因下载失败请重新下载,重复下载不扣分。




    关于淘文阁 - 版权申诉 - 用户使用规则 - 积分规则 - 联系我们

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

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

    收起
    展开