软件需求-第5课-软件需求获取概述(二)(第1版)_第1页
软件需求-第5课-软件需求获取概述(二)(第1版)_第2页
软件需求-第5课-软件需求获取概述(二)(第1版)_第3页
软件需求-第5课-软件需求获取概述(二)(第1版)_第4页
软件需求-第5课-软件需求获取概述(二)(第1版)_第5页
已阅读5页,还剩64页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

第 5 章 软件需求获取,1 需求定义,(1),(2),(3),1 需求定义,在上下文图完成后,可以编写一个软件需求规格说明书大纲,示例:XX体检医院管理系统需求规格说明书大纲,1 文档概述 内容为编写目的、背景、定义和参考资料等。2 任务概述 2.1 业务需求 (1)解决预约安排不合理的问题。避免出现体检部门超负荷。 (2)解决物资供应脱节的问题,通过安全库存管理避免物资短缺现象出现。 2.2 相关人员 .3 业务模型分析 本系统主要包括:体检业务子系统、物质管理子系统、客服子系统组成。子系统 之间的关系如下图所示:,1 需求定义,物质管理子系统,客服管理子系统,体检业务子系统,示例:XX体检医院管理系统需求规格说明书大纲,提交物质使用情况,物质领取,查询客户体检情况,获取预约单获取客户资料,获取客户收费信息,1 需求定义,示例:XX体检医院管理系统需求规格说明书大纲,3.1 客服管理子系统3.2 体检业务子系统,1 需求定义,示例:XX体检医院管理系统需求规格说明书大纲,3.2.1 业务事件 3.2.1.1 体检者申请体检 3.2.1.2 体检者中途改单 3.2.1.3 财务部门提交团队缴费情况 3.2.1.4 客服中心查询团队体检情况 3.2.1.5 维护人员管理体检项 3.2.1.6 系统通知用户取报告3.2.2 报表 3.2.2.1 体检业务周期统计报表 3.2.2.2 当前体检业务情况 3.2.2.3 团队体检过程报告 3.2.2.4 改单业务情况统计 3.2.2.5 报告领域情况查询 3.2.2.6 体检科室超负荷预警 3.2.2.7 体检业务分类统计 3.2.2.8 各项体检统计表,3.2.3 服务接口 3.2.3.1 获取公司客户收费情况 3.2.3.2 查询团队体检完成情况 3.3 物资管理子系统 .,.4 具体需求 4.1 客服管理子系统 4.2 体检业务子系统 4.3 物资管理子系统,主要讨论问题,2 需求获取的策略,3 需求获取的主要方法,4 需求获取的记录工具,1 需求定义,2 需求获取的策略,主要讨论问题,2 需求获取的主动性策略,3 需求获取时对问题的描述策略,4 理解业务场景的重要性,1 需求获取概述,5 需求协商,2 需求获取的策略,需求获取概述,需求获取就是进行需求收集的一个过程或者活动,它从人员,资料和环境中得到系统开发所需要的相关信息。 传统上,不管是结构化或者是面向对象的开发都不太重视需求获取。主要还是将需求分析放在首位。 当前的实践表明,需求阶段的主要活动除了需求分析外,其前应有需求获取,其后至少要包括需求验证。原因在于由于系统规模和应用领域的不断扩大,需求获取的信息逐渐庞杂,需求分析人员在需求获取的过程中要面对的困难不断增加。由于需求获取不够充分、全面所造成的项目变更工作不断升级,并导致项目无法继续进展下去的现象越来越突出。,2 需求获取的策略,需求获取概述,需求获取的非平凡性,用户和开发人员的背景不同,立场不同 首先是知识理解的困难。尽力去研究应用的背景,理解组织的状况,形成一个能够和用户进行有效沟通的粗略的知识框架 默认(Tacit)知识现象 利用有效的获取方法与技巧(角色扮演、观察等)来发现并获取默认知识,2 需求获取的策略,普通用户缺乏概括性、综合性的表述能力普通用户的知识结构就相对局限于一些具体的业务细节 善于表达具体业务的细节问题 专家用户的知识结构因其渊博性而具有概括性和广泛性 能够回答概括性和综合性的问题 开发人员在与用户接触之前就先行确定获取的内容主题,然后设计具体的应用环境和场景条件,由用户根据细节业务的执行来描述问题、表达期望。,需求获取概述,需求获取的非平凡性,2 需求获取的策略,用户存在认知困境 潜在(Latency)知识 需要利用各种有效的需求获取方法和技巧 用户越俎代庖 用户提出的不是需求,而是解决方案注意保持业务领域和解决方案的区分界限用户固执的坚持某些特征和功能分析用户的深层目的,找到隐藏在背后的需求,需求获取概述,需求获取的非平凡性,2 需求获取的策略,缺乏用户参与 用户数量太多,选择困难 用户认识不足,不愿参与 用户情绪抵制,消极参与 没有明确的用户 对系统的用户以及用户的替代源等相关涉众进行分析,需求获取概述,需求获取的非平凡性,2 需求获取的策略,需求获取概述,需求获取的主要活动,研究应用背景,建立初始的知识框架;根据获取的需要,采用必要的获取方法和技巧;先行确定获取的内容和主题,设定场景;分析用户的高(深)层目标,理解用户的意图;进行涉众分析,针对涉众的特点开展工作。,2 需求获取的策略,需求获取概述,需求获取的主要活动,2 需求获取的策略,主要讨论问题,2 需求获取的主动性策略,3 需求获取时对问题的描述策略,4 理解业务场景的重要性,1 需求获取概述,5 需求协商,2 需求获取的策略,需求获取的主动性策略,需求获取,“获取”是一个主动性词汇,强调需求分析人员在整个过程中应该充分发挥主动性。主动性的返回取决于两点:对用户和系统的理解(对业务的理解),掌握相关的获取技巧。 如果没有对业务系统的知识了解,将无从着手,或者即使着手也没有章法,难以组织和发挥技巧的作用。所以说对业务系统的知识理解,是需求获取的基础。,2 需求获取的策略,需求获取的主动性策略,需求获取是撒网打鱼,而不是休闲钓鱼,需求获取要主动,表现为有计划性,要针对不同的用户层次选择不同的方法。,2 需求获取的策略,主要讨论问题,2 需求获取的主动性策略,3 需求获取时对问题的描述策略,4 理解业务场景的重要性,1 需求获取概述,5 需求协商,2 需求获取的策略,需求获取时对问题的描述策略,一般情况下,不要指望一次或者几次需求碰头会就会将用户需求获取。实际情况是,前几次用户提出的问题比较少,后面越来越多,你会受不了。,故事(虚构,但在实际中真实存在):W是M公司对Y企业的信息系统项目派出的需求获取主管,在第1次需求获取碰头会上,W向用户们提出“请大家就XX方面的问题提出需求?”会场鸦雀无声。后来,Y企业主管就信息系统建设的意义和战略做了一些说明,用户们零零碎碎地提了一些需求。会后,W看着记录员记录的需求,感慨地对M公司老板A说,用户自己要做什么都说不清楚,在中国做需求真难哪!A笑笑说,你以为在米国做需求就不难吗?一周后的碰头会,W由于出差,没有赶上,回来看见记录员的需求记录,差点没把正在喝的水杯扔到地上。记录显示,有近200条各种类型的需求。并且注明,由于时间关系,有很多人未得到说话的机会。,2 需求获取的策略,需求获取时对问题的描述策略,故事(虚构,但在实际中真实存在,续1):W找到A,“说来奇怪,以前找用户说需求他们都说不出来什么,但现在他们的需求就像洪水一样滚滚而来。”A看看W,说:用户提不出需求,你郁闷,还感概在中国做需求难,现在你又嫌用户提出需求多,感到纠结了。其实原因在于(1)在需求碰头会开始前,你应该与企业信息主管沟通,让他去鼓动用户提需求(这事情我替你做了。这事在米国也一样啊,主管不发话,方向不明确,下面的用户谁愿意轻易提出需求呢?)(2)需求碰头会不需要将各个部门的人集中到一起开会,至少应该分领域、分部门展开,这样的需求会比较有重点,不会杂乱无章。(3)提出需求的方式或者需求获取对问题的描述要具有重点,要有章法,要有聚集性,不应该是发散性的。 W郁闷地回到办公室,经过思考,作出了以下决定(1)主动请Y企业老总秘书,请他安排项目组主要人员与老总见面,事先将大略的时间安排和进展计划通过秘书与老总沟通。请老总最好安排相关负责人也参与。时间确定后,项目组主要人员不得以任何理由缺席;(2)需求碰头会以后要以部门为单位,一次会议以1到2个相关部门为单位开展。(3)以后需求获取人员在请用户提出需求时不得以“你对该系统有什么需求?”提出,而要按照具体业务类型提出。,2 需求获取的策略,需求获取时对问题的描述策略,发散性提问和收敛性提问?,故事(虚构):需求项目组在税务系统开展需求获取工作。项目组负责需求获取的人员对税务稽查员进行需求调查。问:你认为在收到据举信后应该如何开展稽查工作?(发散性提问)用户考虑了半天答:我要有举报信内容,要有领导批示稽查的指示,去稽查,将结果返回并记录。我还要被举报单位历年纳税情况分析。要企业财务报表,要企业和负责人基本信息。如果有的话,还要关联企业信息。比较一下(收敛性提问),问:当收到举报信后,目前你们如何分派工作?工作分派后,一般采用何种程序开展工作。在此工作开展展时需要何种辅助需求?原来人工处理存在什么问题?你认为在此过程中最让你感觉难办的事情是什么?,2 需求获取的策略,主要讨论问题,2 需求获取的主动性策略,3 需求获取时对问题的描述策略,4 理解业务场景的重要性,1 需求获取概述,5 需求协商,2 需求获取的策略,理解业务场景的重要性,用户对需求的理解主要还是从自身业务出发,他们能够提出的需求是基本需求。如果仅仅停留在这一点上,会为系统开发带来许多问题。 如果能够深入用户工作的实际环境,感受实际场景,就可以大大减少需求变更的可能。实例:W公司为Y机关开发信息系统,在需求及设计完成后,编码人员开始开发业务模块时,发现代码表似乎不对。原来,Y机关有两套代码表,A套是其上级主管单位开发的代码表,B套是财政部门通用的代码表,负责需求的人员想当然地认为Y机关的业务一定是按照其上级主管部门制定的代码表开展业务。所以采用A套代码,实际情况是Y机关业务全部采用B套代码。于是,项目经理要求数据库管理员带领部分开发人员对100多个代码表进行重新录入工作,该工作历时1天半。要求设计人员对所有设计方案中涉及代码表的内容进行重新设计,该工作花掉设计人员3天时间,在此期间,所有涉及代码表的编码人员“休息”,并要求此事对Y机关保密。 增加的工作量Y机关是不会付账的。,2 需求获取的策略,主要讨论问题,2 需求获取的主动性策略,3 需求获取时对问题的描述策略,4 理解业务场景的重要性,1 需求获取概述,5 需求协商,2 需求获取的策略,需求协商,在需求获取的过程中,往往会遇到需要协商的问题。需要需求开发人员具有一定的技巧和沟通能力。,差异问题协调法则:不同的业务层面(有时即使是相同业务层面)的用户对同样的概念或者流程有不同的认识和理解,会出现一些差异,在需求整理时应该将这些差异明确标识出来,并展示给用户高层管理人员,由他们来确定如何消除这些差异,并将这些情况记录。消除变更问题协调法则:上面法则提到的问题,从消除变更的角度考虑仍然存在问题。仅仅将差异标识并展示给高层并不能消除变更的可能,应该考虑这些差异形成背后的问题,应该从开发角度考虑如何消除这些差异,并提供给高层管理人员。要有主动性。,2 需求获取的策略,需求协商,需求协商时机法则:不要在需求冻结前开展需求协商工作。需求协商应该在需求获取过程中不断开展,出现就考虑消除。如果都等到冻结前,将所有矛盾集中体现对工作是非常不利的。实例:W公司开发的信息系统到了需求冻结前夕,A建立拿出厚厚一本需求协商底稿,分为重点差异协调部分,一般差异协调部分,已协调差异列表。结果用户高层非常不满,认为这些工作需要大量时间难以短期完成。,主要讨论问题,2 需求获取的策略,3 需求获取的主要方法,4 需求获取的记录工具,1 需求定义,3 需求获取的主要方法,一般主要的需求获取的方法包括 用户访谈 用户调查 文档分析 原型法(情节串联板) 模型驱动的方法,3 需求获取的主要方法,需求获取方法很多。大量的实践证明,每种方法各自有其优缺点,适用于不同的场合。需求获取人员需要了解各种方法的适用场景,各种方法的优缺点,以利于在不同的场合采用不同的方法开展需求获取工作。好比是木匠,箱子里有一堆工具,他们总是会根据具体情况确定采用何种工具,而不会变为工具的奴隶。不要让自己犯“手里拿着个锯,就感觉所有的木料都需要截断”的错误。,一般主要的需求获取的方法包括 用户访谈 用户调查 文档分析 原型法(情节串联板) 模型驱动的方法,3 需求获取的主要方法,3 需求获取的主要方法,面对面的会见(face-to-face meeting)被认为是最具丰富内容的交流方法实践当中应用最为广泛的需求获取方法之一 可以获得的信息内容包括 事实和问题 被会见者的观点 被会见者的感受 组织和个人的目标,用户访谈,3 需求获取的主要方法,用户访谈,用户访谈的优缺点和应用的时机,用户访谈的优点是简单、直接、形式灵活、交流比较深入。主要缺点是:占用时间长;信息存在片面性。一般来说,不管要什么名称,用户访谈在所有的需求获取中都被开发者使用。但不同的情况下(应用时机)话题和被访谈者可能不同。,3 需求获取的主要方法,用户访谈,用户访谈的优缺点和应用的时机,注意:访谈的目标和话题根据用户的不同而有所侧重,3 需求获取的主要方法,用户访谈,用户访谈的话题类型,问题基本上可以分为两种类型:开放式话题和封闭式话题 开放式话题(Open-Ended)封闭式话题(Closed),3 需求获取的主要方法,被会见者对答复的选择可以是开放和不受限制的,他们可能答复两个词,也可能答复两段话。在希望得到丰富(具有一定深度和广度)信息时,开放式问题比较合适例如:“你觉得把所有的经理都置于一个内联网内怎么样?”“请解释你是如何做进度决策的?”“对公司中企业对企业电子商务的当前状态有何看法?”,用户访谈,用户访谈的话题类型-开放式话题,3 需求获取的主要方法,用户访谈,用户访谈的话题类型-开放式话题,优点:让被会见者感到自在;会见者可以收集被会见者使用的词汇,这能反应他的教育、价值标准、态度和信念;提供丰富的细节;对没采用的进一步的提问有启迪作用;让被会见者更感兴趣;容许更多的自发性;会见者可以在没有太多准备的情况下进行面谈。缺点:提此类问题可能会产生太多不相干的细节;面谈可能失控;开放式的回答会花费大量的时间才能获得有用的信息量;可能会使会见者看上去没有准备。,3 需求获取的主要方法,答案有基本的形式,被会见者的回答是受到限制的 例如:“项目存储库每个星期更新多少次?”“电话中心一个月平均收到多少个电话?”“下列信息中哪个对你最有用:(1)填好的客户投诉单;(2)访问web站点的客户的电子邮件投诉;(3)与客户面对面的交流;(4)退回的货物。”“列出头两项需要优先考虑的改善技术基础设施的事项。”,用户访谈,用户访谈的话题类型-封闭式话题,3 需求获取的主要方法,优点:节省时间;切中要点;保持对面谈的控制;快速探讨大范围问题;得到贴切的数据缺点:使得被会见者厌烦;得不到丰富的细节;出于上述原因,失去主要思想;不能建立和面谈者的友好关系。,用户访谈,用户访谈的话题类型-封闭式话题,3 需求获取的主要方法,用户访谈,用户访谈的话题类型比较,3 需求获取的主要方法,用户访谈,用户访谈的话题类型应用实践,探究式为什么?你能举个例子吗?你能详细描述一下吗? 诱导性 “你和其他经理一样,都同意把财产管理计算机化,是吗” 双筒 “每天你通常会做什么决策,你是怎样做的” 元问题 我的问题看起来相关吗?你的回答正式吗?你是回答这些问题的最佳人选吗?我问了太多的问题吗?我还应该见什么人?,3 需求获取的主要方法,用户访谈,3 需求获取的主要方法,用户访谈,用户访谈的时空安排,时间安排:一次用户访谈的时间一般不超过1小时。主要是专家 们总结说一个成年人一次聚精会神专注一件事情持续 的时间大约不超过50-70分钟。实际上,如果需要解决 的问题比较多,用户又不容易聚到一起,可以采取半 场休息的方法,两小时左右为宜。场地安排:尽量选择相对封闭的环境,不要在办公室或者业务环 境中。实际情况,如果能够将用户集中到封闭环境中, 为上策,哪怕多花点代价也值得。,3 需求获取的主要方法,用户访谈,用户访谈的时空安排,很多经典的书籍中为我们提出了一个可参考的时间安排:,3 需求获取的主要方法,用户访谈,用户访谈的记录工作,用户访谈期间将会产生大量的信息,免不了记录的工作。,很多经典的案例为我们提供了可参考的记录方式:,结合起来做,3 需求获取的主要方法,体会:从来不自己做笔记,但在准备时感觉重要的问题要先有准备材料。 针对自己准备的要点,用户的应答要简单记录一下。笔记由专职 人员做,专职人员如果有速记能力更好。另外录音和录像也可以 采用,但首先要征得用户的同意。一般用户在有录音和录像的场 景下发挥都不太自然。所以采用录音录像要谨慎。 另外,重要的问题要重复,让用户确认一下。这样一方面可以降 低信息不准确的可能性,另外一方面也强化了需求小组对该问题 的记忆和认识。,用户访谈的记录工作,用户访谈,3 需求获取的主要方法,用户访谈,用户访谈的沟通技巧,多数情况下,应该事先制作访谈问卷实现发给被访谈者。罗列出要问的主要问题,如果工作细致,可以将已有的答案和期望的答案都罗列出来。被访谈者事前有这样的问卷,他有可能进行一些思考,而不是在会上无话可谈或者无话不谈。把握访谈方向,应该注意在整个访谈过程中,信息应该是从被访谈者流向访谈者,而不是相反。有资料认为,被访谈者与访谈者说话时间的比例应该是2:1另外,不要问过长的问题,一个问题不要超过20个字。如果是比较长的问题应该将其拆分,采用递进的方法逐个解决。,3 需求获取的主要方法,用户访谈,用户访谈问题顺序的安排,在访谈时,各个问题的顺序应该根据业务逻辑组织。而面对每一组问题来说,应该注意借鉴归纳和演绎方式。具体来说,问题的组织可以采用三种方式: 金字塔结构 漏斗结构 菱形结构,3 需求获取的主要方法,用户访谈,用户访谈问题顺序的安排,在访谈时,各个问题的顺序应该根据业务逻辑组织。而面对每一组问题来说,应该注意借鉴归纳和演绎方式。具体来说,问题的组织可以采用三种方式: 金字塔结构 漏斗结构 菱形结构,如果会见者认为被会见者需要对话题进行预热,可以采用金字塔结构,通过逐步的引导来使得被会见者打开话匣子。如果会见者发现自己事先对事实的确认存在较大偏差或者被会见者看上去不情愿讨论这个话题,也可以采用金字塔结构。当想结束讨论这个话题的时候,使用金字塔结构的提问顺序也是有用的。,3 需求获取的主要方法,用户访谈,用户访谈问题顺序的安排,在访谈时,各个问题的顺序应该根据业务逻辑组织。而面对每一组问题来说,应该注意借鉴归纳和演绎方式。具体来说,问题的组织可以采用三种方式: 金字塔结构 漏斗结构 菱形结构,在库存管理方面存在什么问题?,此问题主要表现在什么方面?,你认为采用什么方法或者策略能够改善这些问题?,请您概括一下,你认为在库存管理方面怎样才能使其更加有效?,以特定问题开始,以通用问题结束,归纳,3 需求获取的主要方法,用户访谈,用户访谈问题顺序的安排,在访谈时,各个问题的顺序应该根据业务逻辑组织。而面对每一组问题来说,应该注意借鉴归纳和演绎方式。具体来说,问题的组织可以采用三种方式: 金字塔结构 漏斗结构 菱形结构,漏斗结构为开始一场面谈提供了一种容易而轻松的途径。当被会见者对这个话题有情绪,并且需要自由表达这些情绪的时候,需要采用漏斗型提问顺序。或者在会见者事先对事实了解不多时,也应该采用漏斗结构的问题组织方式。用这种方式组织面谈能得出很多的详细信息,以至于没有必要使用长序列的受限制问题和调查问题。,3 需求获取的主要方法,用户访谈,用户访谈问题顺序的安排,在访谈时,各个问题的顺序应该根据业务逻辑组织。而面对每一组问题来说,应该注意借鉴归纳和演绎方式。具体来说,问题的组织可以采用三种方式: 金字塔结构 漏斗结构 菱形结构,以特定问题结束,以通用问题开始,演绎,3 需求获取的主要方法,用户访谈,用户访谈问题顺序的安排,在访谈时,各个问题的顺序应该根据业务逻辑组织。而面对每一组问题来说,应该注意借鉴归纳和演绎方式。具体来说,问题的组织可以采用三种方式: 金字塔结构 漏斗结构 菱形结构,使用菱形结构的主要优点是通过各种各样的问题保持被会见者的兴趣和注意力。一旦掌握了如何在正确的时间问正确的问题,就可以多样地选择问题的顺序。,3 需求获取的主要方法,用户访谈,用户访谈问题顺序的安排,在访谈时,各个问题的顺序应该根据业务逻辑组织。而面对每一组问题来说,应该注意借鉴归纳和演绎方式。具体来说,问题的组织可以采用三种方式: 金字塔结构 漏斗结构 菱形结构,归纳,演绎,以特定问题开始,转向通用问题,以特定问题结束,3 需求获取的主要方法,用户访谈,用户访谈计划的安排,在用户访谈期间,需要有精心的计划安排。计划的内容包括:时间、人员、问题,3 需求获取的主要方法,用户访谈,用户访谈计划的安排,在用户访谈期间,需要有精心的计划安排。计划的内容包括:时间、人员、问题,在进行访谈时,不应该是随机进行的,比如看见谁有空就找谁谈,这样做缺乏目的性,造成访谈的针对性不强,完整性欠缺等。要根据需求获取所处的阶段确定访谈的时间和人员主题等,有用户方的联络人员安排。,用户访谈安排计划示例模板,3 需求获取的主要方法,用户访谈,用户访谈计划的安排,访谈前要做好计划,将访谈内容事前告知被访谈人, 避免访谈效率低的问题出现。针对不同的访谈人,要采用不同的方式和要点。,3 需求获取的主要方法,用户访谈,用户访谈计划案例,1、访谈内容概述(1)业务事件:涉税业务受理(2)理解涉税业务受理业务的整个过程,用户的特点,输入、处理、输出(IPO) 要点,数据量等。(3)了解该业务事件涉及的用户(纳税人)、操作层人员(窗口人员)、管理层 人员(税收业务审核人员)的主要关注点。2、访谈对象(1)职位:窗口工作人员(2)姓名:(3)联系方式:(4)其它相关信息:,3 需求获取的主要方法,用户访谈计划案例,3、访谈计划问题(1)基本情况 一个基层单位有多少个窗口,主要负责那些工作? 请受访谈者描述一下其工作流程(工作场景)(2)用户环境 电脑配置?一般使用那些程序? 以前使用的系统情况?系统中那些不好用,那些不错? (3)流程类问题 主要职责是什么?处理那些业务?这些业务是否分不同的类型? 在开始处理前,需要有什么启动条件? 在结束处理后,下一个环节由谁来负责?需要有那些交互? 交互的内容主要是什么?表现形式如何? 如何判断您的一项工作完成?有什么标志?,用户访谈,3 需求获取的主要方法,用户访谈计划案例,3、访谈计划问题(4)数据类问题 每种业务在处理时需要提交材料的类型? 受理过程中需要涉及那些表单证书?(5)非功能性问题 一般每天要处理多少笔业务? 最多的时候要处理多少笔业务? 除了法定节假日外,您感觉对业务的受理多少与特定的日期关系? 处理一笔业务大约需要多少时间? 当前系统的界面或者处理过程您觉得那些地方可以加以改进? (6)其它问题 工作中最大的困难是什么?,用户访谈,3 需求获取的主要方法,用户访谈过程小结,用户访谈过程主要包括:访谈准备、主持访谈、访谈结果处理。,访谈准备,阅读背景资料 确定面谈主题和目标 选择被会见者 准备被会见者 确定问题和类型,记得和被会见者联系并确认面谈的安排着装正式不要迟到表现出来你已经准备好参加面谈了,注意点,3 需求获取的主要方法,用户访谈过程小结,用户访谈过程主要包括:访谈准备、主持访谈、访谈结果处理。,主持访谈,开始建立一个理想的氛围和环境来促进会见者和被会见者之间的交流和沟通 主体通过提问和倾听来完成和被会见者的信息交流,按照计划控制面谈的进行,并在

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论