论第3章 需求分析.pptVIP

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