业务需求讲解PPT

第四章需求的获取需求获取需求获取也称需求捕获，是需求开发中的第一个活动。需求捕获的过程是人与人打交道的过程，其成功与否与需求分析人员的沟通能力关系极大。需求捕获的策略1、需求捕获应该是主动的。需求捕获是一个主动动词，强调了需求分析人员在整个过程中应该充分发挥出主动性，要善于把握主动权，要随时根据每次调研的对象和调研的内容制定相应的计划。需求捕获是撒网打鱼（主动寻找鱼群），不是休闲钓鱼（愿者上钩）。需求捕获的策略2、需求捕获应该是聚焦的。需求捕获时应该针对问题，步步深入，一次集中一个问题进行深入交流。如当监控中心收到一个告警时，希望以什么形式体现？收到后一般会进行什么样的处理？在这个过程中需要做一些什么配套工作？原来处理时存在什么困难？有哪些问题是比较辣手的？善于聚焦访谈话题是需求捕获人员成功地关键。不要当提问者和听话筒。需求捕获的策略3、破解需求的冰上模型用户的需求是一座冰山，这座冰山可以分为三个层次：意识到的需求：经常困扰用户的问题使用户自己能够设想到的功能。需求分析人员能够很容易捕获到。无意识的需求：与用户的实际工作场景有关。这样的需求只有到实际场景中去“亲身感受”才能了解到，而且只有这样才能设计出更加合理的解决方案。一个合格的需求分析人员都应该做到，其具体方法就是加强业务知识的捕获。未梦想的需求：需求分析人员在充分理解问题的基础上，选择合适的技术方案，用简单的功能解决原来很繁琐的处理过程，即创造出用户未梦想到的功能。能够做到这一点就可以成为优秀需求分远人员。尝试理解业务场景是合格需求人员的良好习惯。善于利用技术为用户创造全新体验是优秀需求人员的特质。需求捕获的策略4、破解阻碍需求捕获的心理障碍言过其实心理：用户把流程说得很理想、很规范，但与实际情况差距很大，难以实施。可以访谈多个用户，找到不同用户对需求描述的差异，并展现给上层管理人员来达成共识。越俎代苞心理：由不懂需求的人代替懂需求的人凭自己的理解、想象对需求进行肯定的描述，所描述的需求与实际不符。解决该问题的最有效方法是识别正确的被访谈者。非正事心理：被访谈者没有把访谈作为一件很重要的工作来对待，访谈在办公室进行并不断被其他事情打断。解决办法是离开办公室，对访谈进行计划并得到被访谈者认可。抗拒心理：信息系统建设有时反而增加操作层人员的负担，从而造成对此类工作的抵触情绪。化敌为友是缓减抗拒心理的主要方法。推卸责任心理：被访谈人员相互推卸，认为自己无需求，可能是其他人有需求。突破推卸责任心理的简单手段是让被访谈者介绍工作场景。需求捕获的策略5、不要忽视对变更可能的捕获需求捕获时不要忽视对变更可能的了解。如与税收相关的税率经常发生变动、贷款利率经常发生变动、保险费率经常发生变动、企业营销策略经常发生变动等。一个企业/组织的业务流程、业务规则有的相对比较固定，有的则比较灵活。对于比较灵活的业务，实际上隐含着发生变更的可能，不能根据访谈或调研时的情况来确定业务规则。需求捕获的策略6、需求协商需求捕获过程中，常常遇到比较模糊的问题需要协商解决。●探讨解决方案后面的问题用户“不直接说问题，而是说解决方案”，如“我希望系统实现…”，“我希望系统提供…”等。遇到这类问题，应该多问“为什么”，找到真正的需求。●共赢性谈判当分析人员发现两个不同部门或不同层次用户对需求出现不同意见并且相左时，就需要用共赢谈判的技巧来解决，即“抛开立场，寻找利益诉求”是需求协商的要点。需求捕获方法需求捕获的方法很多，每种方法各有优缺点，而且实用的时机也不相同。需求捕获的主要方法包括：●用户访谈●用户调查●文档研究●情节串联板●现场观摩●联合开发需求捕获方法—用户访谈用户访谈是最常见、最基本的需求捕获技术。访谈者是否善于访谈将直接影响最终的结果。用户访谈的优点是直接有效、形式灵活、交流深入。缺点：占用时间长，信息存在片面性。用户访谈类型被访谈者阶段话题中心目标高层管理人员需求定义问题/机会探讨系统的目标和范围中层管理人员需求捕获阶段一业务事件理清需求的脉络信息操作层需求捕获阶段二业务活动填充需求的细节技术团队需求捕获解决方案论证解决方案的可行性需求捕获方法—用户访谈用户访谈应制定好访谈计划，使被访谈人能够做好准备。针对不同访谈对象的计划要点访谈对象计划要点备注说明高层管理人员1.罗列出部分问题/机会点2.准备相关系统的经验方案3.列举一些潜在的解决方案确认已列出的问题/机会点，探讨潜在的问题/机会点中层管理人员1.列举出相关的业务事件列表2.收集与特定业务事件相关的资料3.准备一些业务事件的关键问题点4.准备一些相关的管理控制点确定每个业务事件的流程、相关实体、相关参与者，明确管理控制点操作层1.列举出相关的业务活动2.针对业务活动的问题点、需求点3.列举出相关的业务实体、规则应该从基本情况、功能、数据、非功能、用户环境等多个角度设计问题技术团队1.列举出要解决的问题；2.整理出预想的解决方案；3.标识关键的疑问点。分析每个解决方案，结合问题探讨方案的合理性和可行性需求捕获方法—用户调查用户调查技术是与用户访谈相关的一组技术。需求分析人员通过问卷的形式，将要了解的问题一一列出，并对每个问题列出不同的选择，让用户进行回答。用户调查的优点是调查面比较广，能够获得更多人的反馈，这是对用户访谈技术的有效补充，能够克服用户访谈的片面性。用户调查与用户访谈可以交替进行，组合的方式有：先调查后访谈：先设计通用问卷，从用问卷的结果中梳理出关键点，然后选取一些用户代表进行更有针对性的访谈。先访谈后调查：先筛选出一些典型的用户代表访谈，然后对访谈的结果进行整理，在此基础上设计相关的问卷在需求捕获过程中，先访谈再调查往往更合理。先通过访谈获得对用户需求的初步的认识，整理后再设计问卷调查进行系统地需求获取。需求捕获方法—用户调查用户调查的优点是调查面比较广，能够获得更多人的反馈，这是对用户访谈技术的有效补充，能够克服用户访谈的片面性。用户调查的缺点是：大家都认识到的问题往往不易深入，容易形而上学。用户调查对大样本用户（岗位从业人数多）、存在跨区域用户（用户分散），比较适合。需求捕获方法—文档研究文档研究也叫文档考古，基本要点是：收集文档、研究文档。收集文档主要收集业务活动中的大量单据、报表。研究文档：从文档资料中提取用户需求。优点：能详细、直观地对数据流细节进行了解和分析，是研究、分析、细化数据需求的主要手段。缺点：文档量大，容易使需求捕获陷入文山文海之中。收集文档时，应该尽可能让用户提供带有真实数据的样本。空白表单无法反映表单的真实使用过程，以便业务流程分析时，标识出各个业务活动所要处理、传递的表单。分析文档资料时应思考新流程对其的影响。新流程应真实反映原业务流程的本质，但不是原流程的快照。分析人员要善于根据流程分析的结果主动收集相关文档。需求捕获方法—情节串联板情节串联板经常被称为原型法，情节串联板更强调借助原型来加快需求捕获过程。需求捕获过程的重点在于理解业务、分析业务、了解潜在的问题，但仍不可避免地涉及到一些解决方案的探讨，即功能应该提供一个什么样的处理过程才能使用户满意。情节就是剧本，实践就是用户的使用场景。情节应该以业务工作场景为主线索，如说明用户下订单怎么做、用户修改订单怎么做、用户要查询订单执行情况是怎么做？先把这些业务步骤列出来作为“情节”，然后让用户带着这样的线索来审视系统的操作过程，看看是否合理、是否满足需求。即情节串联板应该以业务场景作为展示的主线索。串联体现了原型的动态性、交互性。用户不仅仅关心用户界面的样子，更关心用户界面的流转过程和交互过程。即交互才是情节串联板的本质，不要只关注界面静态效果。需求捕获方法—现场观摩现场观摩就是亲自到业务现场去看一看，以便对业务场景建立更加感性的认识。开发团队毕竟不是业务专家。开发人员经常需要开发不同领域的业务系统，对业务知识、业务场景不熟悉是自然的事。所以现场观摩是消除开发团队认识盲区的有效手段。现场观摩的优点是：百闻不如一见，能够实现对业务场景“感同身受”，对需求和业务流程建立直观的认识。这种方法适用于用户无法详细解释清楚他们在做什么的业务，因为“人们正在做一件事时，最能解释他们在做什么，为什么要这样做”。缺点：消耗时间长，有时会使“观摩”失真。不要刻意地告诉现场人员要来观摩，防止现场人员作表明文章。需求捕获方法—联合开发联合开发技术就是用户代表、需求分析人员、开发人员代表齐聚一堂，以头脑风暴的形式进行需求探讨。这是最理想的需求捕获方式。优点：联合开发是突破双方需求盲区的有效手段。客户、开发人员直接的头脑风暴能突破需求盲点。缺点：成本高。如果组织不好会变成闲扯大会。适用情况：1、项目启动初期：大家对项目的目标和范围比较模糊的时候，通过大家一起讨论，使得目标和范围更加明确，为需求和开发工作指明方向。2、关键主题域、功能块的专题讨论：系统中的某些关键部分是整个系统的核心价值所在，组织此类活动可以有效地提高需求质量。需求捕获的记录工具在需企业捕获时，采用合适的需求记录工具对于清晰地描述捕获的需求和相互理解记录的需求很有必要。选择记录工具的关键思想是：沟通决定内容，内容决定格式。首先要确定在不同团队的沟通过程中需要解决什么问题，针对不同团队的关注点罗列要收集的内容。然后再根据内容决定组织的形式，确定记录工具的格式。需求捕获的记录工具—任务卡任务：入住目的：为旅客分配客房，将其标为“占有”，并开始记帐。触发：前提：客人抵达频率：平均0.5次/每房/每天关键情况：50人的旅游团子任务：1.查找客房2.将客房标注为“已住入”3.提供钥匙任务变体1a.客户已预订1b.无合适客房2a.客人数据已在预订的记录中2b.常客需求捕获的记录工具—任务卡的要点项目内容说明任务对该业务活动命名一定要使用业务术语目的以业务活动的工作意义进行概述说明的是意图而不是工作触发进行该业务活动系统要判断的前置条件前提触发本业务活动的时机、场景说明了业务前提频率任务发生的频率这是一个非功能要求关键情况一些十分特殊的业务场景系统需要专门进行处理子任务该业务活动的具体业务步骤相当于用例的基本事件流任务变体该业务活动的变体与异常情况相当于用例的扩展事件流