需求分析方法 调研方法、用例分析、类图分析.pptVIP

需求分析方法 引言 需求调研方法 需求调研方法 需求调研是需求分析过程中与客户交往最多一段时间，这阶段存在问题如下： 绝大部分客户不知道如何全面而又准确无误表达自己的需求 关注核心客户还是大多数客户 沉默的大多数与骑墙的大多数 需求调研方法 需求调研方法横向比较： 客户访谈—最基本、最常见的技术 利：直接有效、形式灵活且交流深入，应该作为主要的需求捕获技术。 弊：占用时间长（特别当客户忙时更显出其不足）、面窄且易造成信息的片面性。 要点：一是要有准备，通常包括说明对流程的理解并征得客户的意见。预先根据流程中的不明确点设计要询问的问题，并将客户的反馈记录下来。应留有一些即兴发挥的空间，根据实际情况应变，以确保信息完善。 二是要有计划性，计划好时间、人员及策略。 需求调研方法 需求调研方法横向比较： 现场观摩—最生动技术 利：百闻不如一见，能够对需求与业务流程建立直观的认识。 弊：消耗时间长，而且由于被观摩的微妙心理变化，会使得观摩失真。 适用性：对复杂流程的深入的理解时。 要点：悄悄地进行，明确要强化理解的具体流程。 需求调研方法 需求调研方法横向比较： 联合开发—最理想技术 利：客户及开发人员直接的头脑风暴是击破需求盲点的关键手段。 弊：成本高，如果缺乏控制，则会变成一次闲扯大会。 要点：需要有一个经验丰富并能把控大局的主持人。 需求获取及分析 需求获取经典三个问题: 用例分析 用例:标识互动关系与角色或物件的联系,描述系统具体可以做哪些事情。描述系统的功能需求 ,系统功能需求可视化的表示。 用例以参与者为中心（区别于以计算机系统为中心），从参与者的角度来描述要做的业务工作（区别于以业务流程描述的方式），并分析这些业务工作之间是如何交互的（区别于数据流的描述方式）。换句话说，用例分析的首要目标不是要弄清楚某项业务是如何一步一步完成的，而是要弄清楚有多少参与者？每个参与者都做什么？ 用例分析:用例图 用例图:UML中要求的关键点：方框代表系统边界，每个角色（小人图形）通过线条 和与之交互的用例（椭圆）相连。 用例分析:用例描述 概念： 用例描述：描述用例内部的事务，用例内部不一定是单个用例内部，也可能有用 例之间的关系。 场景（用例实例）-用例中步骤的一个特定顺序，一个用例可以有几个不同场景。 用例分析:用例描述元素 描述每个用例，基本元素有: 用例的唯一标识: 用例名称:动宾结构 行为者:调用系统，使之交付服务的角色 用例的简述:简要介绍该用例的作用和目的； 级别:高层、用户目标级、子功能 前置条件:激发该用例所应该满足的条件。 后置条件:用例完成将执行什么动作。 流程:分主干和分支，描述共前置条件到后置条件的过程中，系统与用户之间有 何种交互步骤； 其他内容:比如限制条件、业务规则的描述；界面描述（对界面的描述经常占用 例分析的很大篇幅，甚至配上demo）；额外的一些针对项目特定的需求。 类图 类图 类图 结 束,谢谢！ * * 用例分析 类图 说明:需求分析说明书：系统概要信息＋用例描述功能需求＋类图描述数据需求＋ 非功能需求描述（性能等）组成。 需求分析过程如右图所示： 需求分析方法： 系统分析师须掌握调研方法，恰当引导客户表达自己的需求，以便为项目的成功提供良好的基础。 心得： 客户怎么说和怎么做是不同的，其实客户的语言不如行为更能反应出他的真实需求 试图满足所有客户的需求是一个灾难 客户调查—调查面最广的技术 利：面广，能够获得更多的人反馈，是对客户访谈技术不足之处的最好补充。 弊：不够深入，容易形而上学，而这点是客户访谈技术所能够解决的。 要点：结合客户访谈技术使用，具体来说，首先设计问题，制作成为客户调查表。下发填写完后，进行仔细分组、整理并分析，以获得基础信息。然后针对这个结果进行小范围的客户访谈，作为补充。 文档考古—最贴近实现的技术 利：能够详细并直观地对数据流细节进行了解与分析。 弊：易陷入文山书海之中不可自拔,甚至常引起误导。 要点：应该让客户提供写有真实数据的文档。 构建可行性发现原型:主要目的是为了更好理解用户的需求。 原型是模型、样品的意思,原型法会应用软件开发过程的各个阶段。分析阶段是发现 原型用来明确并完善需求。设计阶段建立原型来测评各种设计和界面设计。编码阶段建立原型测试各种编程技术的效果和效率。 发现原型是一个仅显示外观而不是提供执行能力的界面。发现原型不是为了实现所有功能，而是