需求分析的任务-Read.ppt

第3章 需求分析requirements analysis;需求分析的任务: 　　需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么?”这个问题。 　　对目标系统提出完整、准确、清晰、具体的要求。 　　在需求分析阶段结束之前，系统分析员应该写出软件需求规格说明书，以书面形式准确地描述软件需求。 　　用户与分析员之间需要沟通，避免误解或遗漏和二义性。 ;1. 功能需求 这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。 2. 性能需求 性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。;3.运行要求 　　系统运行环境 ４. 　其它需求 如：接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。;６. 将来可能提出的要求 应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。;　　综合上述分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、数据字典和主要的处理算法描述这个逻辑模型。 ; 根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。 3.1.５　开发原型系统 ·反映主要功能 ·第四代语言 ;3.1.６　写需求规格说明书; 功能描述 约束条件 有效性准则 初步用户使用手册 ３．１．７　审查与复审 ;３．２　分析过程(Requirements Process) 　　结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。 　　通过可行性研究已经得出了目标系统的高层数据流图，需求分析的目标之一就是把数据流和数据存储定义到元素级。为了达到这个目标，通常从数据流图的输出端着手分析，这是因为系统的基本功能是产生这些输出，输出数据决定了系统必须具有的最基本的组成元素。; 图3.1 面向数据流自顶向下求精过程; 用户的数据要求----需要哪些数据，数据之间有哪些联系，数据本身有哪些性质，数据的结构 等）。 用户的处理要求---对数据进行哪些处理，每个处理的逻辑功能。 概念性模型（信息模型）---一种面向问题的数据模型，是按照用户的观点来对数据和信息建模。表示概念性数据模型的最常用方法是实体-联系方法，采用实体-联系(ER)图的方式，这种表示又称为ER模型。; 数据对象彼此之间相互连接的方式称为联系，也称为关系。联系可分为以下3种类型： (1) 一对一联系(1∶1) 例如，一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。 (2) 一对多联系(1∶N) 例如，某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教(见图3.2)。;(3) 多对多联系(M∶N) 例如，图3.2表示学生与课程间的联系(“学”)是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。 联系也可能有属性。例如，学生“学”某门课程所取得的成绩，既不是学生的属性也不是课程的属性。由于“成绩”既依赖于某名特定的学生又依赖于某门特定的课程，所以它是学生与课程之间的联系“学”的属性(见图3.2)。; 图3.2 某校教学管理ER图; 软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。;　　通常用“范式(normal forms)”定义消除数据冗余的程度。 　　第一范式(1 NF)数据冗余程度最大，第五范式(5 NF)数据冗余程度最小。但是，范式级别越高，存储同样数据就需要分解成更多张表，因此，“存储自身”的过程也就越复杂。 　　第二，随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差。 　　第三，范式级别提高则需要访问的表增多，因此性能(速度)将下降。从实用角度看来，在大多数场合选用第三范式都比较恰当。;　　通常按照属性间的依赖情况区分规范化的程度。 　　第一、第二和第三范式的定义： (1) 第一范式每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。 (2) 第二范式满