软件工程课件之第3章_需求(第五版)(张海潘编著)讲述.ppt

3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明 3.4 实体-联系图 3.5 数据规范化 3.6 状态转换图 3.7 其他图形工具 3.8 验证软件需求 第3章 需求分析 第3章 需求分析 需求分析的任务： 需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么?”这个问题。 确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。 系统分析员应该写出软件需求规格说明书，以书面形式准确地描述软件需求。 需求：正在构建的系统必须符合的事务。 需求管理：是一种获取、组织并记录系统需求的系统化方案以及一个使客户与项目团队不断变更的系统需求达成并保持一致的过程。 传统需求分析：强调需求的记录，以一成不变的观点对待需求，不重视需求实现与维护。 现代需求过程：包括需求的获取、分析、处理、验证、实现和全过程的需求管理。需求管理覆盖软件工程的整个过程。 传统与现代需求方法的比较： 需求管理过程 需求管理功能 需求管理思想方法 传统 局限于需求分析这一个阶段 注重具体的需求分析方法 一成不变的观点，注重“描述”的方法和过程，是纯技术性的转换 现代 全过程的，注重整个产品过程的全部 功能范围更广，包括获取、分析、处理、验证、实现和全过程的需求管理 注重需求实现与维护过程，处理不断变更的系统需求 需求管理存在的问题： 范围问题：系统目标、边界未被良好定义，用户和开发团队理解不一致。 理解问题：用户不能完全了解自己需要什么，对系统能力、局限更加不清楚；工程师不理解用户的问题域和应用环境。 易变问题：需求随时间发生变化。 需求工程： 20世纪80年代中期，形成了软件工程的子领域——需求工程。 进入20世纪90年代后，需求工程称为软件界研究的重点之一。 Alan Davis 把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动”。 需求工程的阶段划分： 3.1 需求分析的任务 确定对系统的综合要求 分析系统的数据要求 导出系统的逻辑模型 修正系统开发计划 3.1.1 确定对系统的综合要求 1. 功能需求 2. 性能需求 3. 可靠性和可用性需求 4. 出错处理需求 5. 接口需求 6. 约束 7. 逆向需求 8. 将来可能提出的要求 3.1.2 分析系统的数据要求 建立数据模型——ER图 描绘数据结构——层次方框图和Warnier图 数据结构规范化 3.1.3 导出系统的逻辑模型 综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。 根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。 3.1.4 修正系统开发计划 3.2 与用户沟通获取需求的方法 访谈 面向数据流自顶向下求精 简易的应用规格说明技术 快速建立软件原型 需求分析综合症 解决方案 需求诱导的方法： 3.2.1 访谈 1. 正式访谈 系统分析员将提出一些事先准备好的具体问题。 2. 非正式访谈 分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。 3. 调查表 经过仔细考虑写出的书面回答可能比被访者对问题的口头回答更准确。 4. 情景分析技术 对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。 情景分析技术的用处： 能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求。 能保证用户在需求分析过程中始终扮演一个积极主动的角色。让用户起积极主动的作用对需求分析工作获得成功是至关重要的。 3.2.2 面向数据流自顶向下求精 1. 分析追踪数据流图 需求分析的目标之一就是把数据流和数据存储定义到元素级，通常从数据流图的输出端着手分析。 2. 用户复查 必须请用户对上述分析过程中得出的结果仔细地复查。复查过程验证了已知的元素，补充了未知的元素，填补了文档中的空白。 随着分析过程的进展，经过问题和解答的反复循环，分析员越来越深入具体地定义了目标系统，最终得到对系统数据和功能要求的满意了解。 面向数据流自顶向下求精过程 3.2.3 简易的应用规格说明技术 简易的应用规格说明技术是一种面向团队的需求收集法。 这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。 分析需求的典型过程如下： 1. 初步访谈，准备会议 首先进行初步的访谈，初步确定待解决的问题的范围和解决方案。 然后开发者和用户分别写出“产品需求”。选定会议的时间和地点，并选举协调人。