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

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