第3章 需求分析requirements analysis.pptVIP

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