需求分析.pptVIP

第3章 需求分析 3.1 需求分析的任务 3.2 信息收集技术 3.3 数据模型 3.4 功能模型 3.5 行为模型 3.6 其他图形工具 3.7 验证软件需求 目标 列举信息收集技术技巧 设计项目的E-R图 设计项目的数据流图 设计项目的状态转换图 了解其他图形工具 第三章 需求分析(I) 需求分析的基本任务是准确地回答“系统必须做什么?”这个问题。 确定系统必须完成哪些工作，对目标系统提出完整、准确、清晰、具体的要求。 在需求分析阶段结束之前，系统分析员应该写出软件需求规格说明书（Software Requirement Specification ），以书面形式准确地描述软件需求。 所有这些分析方法都遵守下述准则： (1) 必须理解并描述问题的信息域，根据这条准则应该建立数据模型。 (2) 必须定义软件应完成的功能，这条准则要求建立功能模型。 (3) 必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。 3.1 需求分析的任务 需求内容 逻辑模型 修正系统开发计划 需求内容(I) 功能需求 性能需求 环境需求 可靠性需求 安全保密要求 用户界面需求 需求内容(II) 1. 功能需求 这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。 2. 性能需求 软件开发的技术性指标。 例如： 存储容量限制 执行速度、响应时间 吞吐量 需求内容(III) 3. 环境需求 硬件设备：机型、外设、接口、地点、分布、温度、 湿度、磁场干扰等 软件：操作系统、网络、数据库 4. 接口需求 接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。 需求内容(IV) 5. 用户或人的因素 用户类型？ 各种用户熟练程度？ 需受何种训练？ 用户理解、使用系统的难度？ 用户错误操作系统的可能性？ 需求内容(V) 6. 数据需求 输入、输出数据的格式？ 接收、发送数据的频率？ 数据的准确性和精度？ 数据流量？ 数据需保持的时间？ 需求内容(VI) 7. 安全保密需求 需对访问系统或系统信息加以控制吗？ 用户程序如何与其它程序和数据库系统隔离？ 系统备份要求？ 8. 质量保证 系统的可靠性要求？ 规定系统平均出错时间？ 出错后，重启系统允许的时间？ 维护是否包括对系统的改进？ 系统的可移植性？ 逻辑模型 数据模型（ERD） 功能模型（DFD） 行为模型（状态转换图） 修正系统开发计划 根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。 3.2 信息收集技术 主要问题 复查现有报表、表格和过程描述 访谈 观察并记录商业过程 建立原型 分发收集调查表 主持联合应用程序设计会议 面向数据流分析 简易规格说明书 1 主要问题 表 信息收集中的主要问题 2 复查报表、表格和过程描述 商业文档和过程描述是了解过程的一个好方法。 表格和报表可以为面谈提供可视化的帮助、也可以提供工作文档。 复查现有过程文档将有助于识别面谈中不会提及的商业规则。 有助于发现商业过程中的不一致和冗余。 3 面谈 面谈之前 确立面谈目的 确定要包括的相关用户 确定参加会议的项目小组成员 建立要讨论的问题和要点列表 复查有关文档和资料 确立时间和地点 通知所有参加者有关会议的目的、时间和地点 4 观察并记录商业过程(I) 观察 使用活动图来进行记录 4 观察并记录商业过程(II) 学生购买教材的实际处理流程—当前系统物理模型 5 建立原型6 分发和收集调查表 7 主持联合应用程序设计会议 JAD的目的是把所有这些活动压缩为用户和项目小组成员一起参加得更短的JAD会议。 参加人员： JAD会议领导者 用户 技术人员 项目组成员 8 面向数据流自顶向下求精 数据流图是帮助复查的极好工具。 从输入端开始，分析员借助数据流图、数据字典和IPO图向用户解释输入数据是怎样一步一步地转变成输出数据的。 这些认识正确吗?有没有遗漏?用户应该注意倾听分析员的报告，并及时纠正和补充分析员的认识。复查过程验证了已知的元素，补充了未知的元素，填补了文档中的空白。 9 简易的应用规格说明技术(I) 典型过程如下： 通过初步访谈确定待解决的问题的范围和解决方案。 然后开发者和用户分别写出“产品需求”。选定会议的时间和地点，并选举一个负责主持会议的协调人。 审查产品需求，列出系统环境组成部分的对象、系统将产生的对象以及系统为了完成自己的功能将使用的对象。 列出操作这些对象或与这些