软件工程之第3章_需求(第6版)(张海潘编著)试题.pptx

第3章 需求分析 需求分析的任务 与用户沟通获取需求的方法 分析建模与规格说明 实体-联系图 数据规范化 状态转换图 其他图形工具 验证软件需求 需求分析的意义 软件需求的深入理解是软件开发工作获得成功的前提条件 离开需求的设计和编码只会令用户失望，给开发带来烦恼。 需求分析的任务 软件定义的最后一个阶段，回答“系统必须做什么?” 。 确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。 系统分析员应该写出软件需求规格说明书，以书面形式准确地描述软件需求。 需求与需求管理 需求：正在构建的系统必须符合的事务。 需求管理：是一种获取、组织并记录系统需求的系统化方案以及一个使客户与项目团队不断变更的系统需求达成并保持一致的过程。 传统需求分析：强调需求的记录，以一成不变的观点对待需求，不重视需求实现与维护。 现代需求过程：包括需求的获取、分析、处理、验证、实现和全过程的需求管理。需求管理覆盖软件工程的整个过程。 需求过程比较 需求管理过程 需求管理功能 需求管理思想方法 传统 局限于需求分析这一个阶段 注重具体的需求分析方法 一成不变的观点，注重“描述”的方法和过程，是纯技术性的转换 现代 全过程的，注重整个产品过程的全部 功能范围更广，包括获取、分析、处理、验证、实现和全过程的需求管理 注重需求实现与维护过程，处理不断变更的系统需求 需求管理的问题 范围问题： 系统目标、边界未被良好定义，用户和开发团队理解不一致。 理解问题： 用户不能完全了解自己需要什么，对系统能力、局限更加不清楚；工程师不理解用户的问题域和应用环境。 易变问题： 需求随时间发生变化。 可行性研究的意义 分析员应该为每个可行的解法制定一个粗略的实现进度。 可行性不高，分析员应该建议停止这项开发工程；否则应推荐一个较好的解决方案制定一个初步的计划。 可行性研究需要的时间长短取决于工程的规模。一般说来，可行性研究的成本只是预期的工程总成本的5%～10%。 可行性研究过程 复查系统规模和目标 对问题定义阶段书写的关于规模和目标的报告书进一步复查确认。 研究目前正在使用的系统 新的目标系统必须也能完成旧系统的基本功能；另一方面，新系统必须能解决旧系统中存在的问题。 获取需求难！ 需求工程 20世纪80年代中期，形成了软件工程的子领域——需求工程。 进入20世纪90年代后，需求工程称为软件界研究的重点之一。 Alan Davis 把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动”。 需求工程的阶段划分 基本原则 必须理解并描述问题的信息域，建立数据模型。 必须定义软件应完成的功能，建立功能模型。 必须描述作为外部事件结果的软件行为，建立行为模型。 必须对描述信息、功能和行为的建模进行分解，用层次的方法展示细节。 需求分析的任务 确定对系统的综合要求 功能需求 性能需求 可靠性和可用性需求 出错处理需求 接口需求 约束 逆向需求 将来可能提出的要求 需求分析的任务 分析系统的数据要求 建立数据模型—ER图 描绘数据结构—层次方框图和Warnier图 数据结构规范化 导出系统的逻辑模型 导出系统的逻辑模型 通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。 修正系统开发计划 根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。 需求分析的难处 项目相关人员通常并不真正知道希望计算机做什么。 项目相关人员表达需求使用很多工作中的专业术语和知识。系统分析员必须了解这些需求。 要发现需求潜在相容或冲突之处。 需求是动态的，会发生变更。 需求诱导的方法 与用户沟通获取需求的方法 访谈 面向数据流自顶向下求精 简易的应用规格说明技术 快速建立软件原型 与用户沟通获取需求的方法 访谈 正式访谈 提出一些事先准备好的具体问题。 非正式访谈 提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。 调查表 书面回答，通常比口头回答更准确。 与用户沟通获取需求的方法 访谈 情景分析技术 对使用系统解决具体问题的方法和结果进行分析。 好处： 能在某种程度上演示目标系统的行为，便于用户理解，可能进一步推理用户需求。 让用户在需求分析过程中扮演一个积极主动的角色，更易获得真实需求。 与用户沟通获取需求的方法 面向数据流自顶向下求精 分析追踪数据流图 把数据流和数据存储定义到元素级，通常从数据流图的输出端着手分析，再进行回溯 用户复查 验证已知的元素，补充未知的元素，填补文档空白。 分析员越来越深入具体地定义目标系统，最终得到对系统数据和功能要求的满意了解。 与用户沟通获取需求的方法 面向数据流自顶向下求精 与用户沟