武汉理工_软件工程导论ppt_第3章 需求分析.pptVIP

第三章 需 求 分 析 3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明 3.4 实体－关系图 3.5 状态转换图 3.6 其他图形工具 3.7 验证软件需求 第3章 需求分析 意义： 软件需求的深入理解是软件开发工作获得成功的前提条件，不论我们把设计和编码做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发带来烦恼。 需求分析是软件定义时期的最后一个阶段，它的基本任务不是确定系统怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。并在需求分析阶段结束之前，由系统分析员写出软件需求规格说明书，以书面形式准确地描述软件需求。即： ---- 准确地回答“系统必须做什么?”。 在分析软件需求和书写软件需求规格说明书的过程中，分析员和用户都起着关键的、必不可少的作用。 只有用户才真正知道自己需要什么，但是他们并不知道怎样用软件实现自己的需求，用户必须把他们对软件的需求尽量准确、具体地描述出来；分析员知道怎样用软件实现人们的需求，但是在需求分析开始时他们对用户的需求并不十分清楚，必须通过与用户沟通获取用户对软件的需求。 需求分析和规格说明是一项十分艰巨复杂的工作。用户与分析员之间需要沟通的内容非常多，在双方交流信息的过程中很容易出现误解或遗漏，也可能存在二义性。因此，不仅在整个需求分析过程中应该采用行之有效的通信技术，集中精力过细地工作，而且必须严格审查验证需求分析的结果。 3.1 需求分析的任务 需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。 3.2 与用户沟通获取需求的方法 访谈 面向数据流自顶向下求精 简易的应用规格说明技术 快速建立软件原型 (1). 访 谈 (2). 面向数据流自顶向下求精 问题： 使用传统的访谈或面向数据流自顶向下求精方法定义需求时，用户处于被动地位而且往往有意无意地与开发者区分“彼此”。由于不能像同一个团队的人那样齐心协力地识别和精化需求，这两种方法的效果有时并不理想。 这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。 使用简易的应用规格说明技术分析需求的典型过程 (4). 快速建立软件原型 正如第1章已经讲过的，快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。 快速建立软件原型是最准确、最有效、最强大的需求分析技术。 快速原型应具备的特性是“快速”、 “容易修改”。 需求分析的结构化方法都遵守下述准则： (3) 必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。 3.3 分析建模与规格说明 1). 分析建模 模型----就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，由一组图形符号和组织这些符号的规则组成。 需求分析过程应该建立3种模型: 数据模型 ---- 实体-关系图 功能模型 ---- 数据流图 行为模型 ----状态转换图 3.3 分析建模与规格说明 实体-联系图(ER) Entity Relationship Diagram 举 例 3.5 状态转换图 状态转换图(简称为状态图) 通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果系统将做哪些动作(例如，处理数据)。 1). 状 态 状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。系统对事件的响应，既可以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。 初态 (即初始状态) 状态 终态 (即最终状态) 中间状态 2). 事 件 事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。 例如，内部时钟表明某个规定的时间段已经过去，用户移动或点击鼠标等都是事件。 简而言之，事件就是引起系统做动作或(和)转换状态的控制信息。 初态用实心圆表示，终态用一对同心圆(内圆为实心圆)表示。 中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下3个部分。上面部分为状态的名称，这部分是必须有的；中间部分为状态变量的名字和值，这部分是可选的；下面部分是活动表，这部分也是可选的。 活动表的语法格式