第3章需求分析 3.1需求分析的任务 3,2与用户沟通获取需求的方法 33分析建模与规格说明 34实体联系图 3.5数据规范化 3.6状态转换图 3.7其他图形工具 3.8验证软件需求
3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明 3.4 实体-联系图 3.5 数据规范化 3.6 状态转换图 3.7 其他图形工具 3.8 验证软件需求 第3章 需求分析
第3章需求分析 需求分析的任务: ■需求分析是软件定义时期的最后一个阶段,它的 基本任务是准确地回答“系统必须做什么?”这个 问题。 ■确定系统必须完成哪些工作,也就是对目标系统 提出完整、准确、清晰、具体的要求。 ■系统分析员应该写出软件需求规格说明书,以书 面形式准确地描述软件需求
第3章 需求分析 需求分析的任务： ◼ 需求分析是软件定义时期的最后一个阶段，它的 基本任务是准确地回答“系统必须做什么?”这个 问题。 ◼ 确定系统必须完成哪些工作，也就是对目标系统 提出完整、准确、清晰、具体的要求。 ◼ 系统分析员应该写出软件需求规格说明书，以书 面形式准确地描述软件需求
■需求:正在构建的系统必须符合的事务。 ■需求管理:是一种获取、组织并记录系统 需求的系统化方案以及一个使客户与项目 团队不断变更的系统需求达成并保持一致 的过程。 ■传统需求分析:强调需求的记录,以一成 不变的观点对待需求,不重视需求实现与 维护。 ■现代需求过程:包括需求的获取、分析 处理、验证、实现和全过程的需求管理 需求管理覆盖软件工程的整个过程
◼ 需求：正在构建的系统必须符合的事务。 ◼ 需求管理：是一种获取、组织并记录系统 需求的系统化方案以及一个使客户与项目 团队不断变更的系统需求达成并保持一致 的过程。 ◼ 传统需求分析：强调需求的记录，以一成 不变的观点对待需求，不重视需求实现与 维护。 ◼ 现代需求过程：包括需求的获取、分析、 处理、验证、实现和全过程的需求管理。 需求管理覆盖软件工程的整个过程
传统与现代需求方法的比较: 需求管理过程需求管理功能/需求管理思想方 法 成不变的观点 传统局限于需求分注重具体的需注重“描述”的 析这一个阶段求分析方法方法和过程,是 纯技术性的转换 功能范围更广 全过程的,注 包括获取、分注重需求实现与 现代重整个产品过/析、处理、验维护过程,处理 程的全部 证、实现和全不断变更的系统 过程的需求管需求 理
传统与现代需求方法的比较： 需求管理过程 需求管理功能 需求管理思想方 法 传统 局限于需求分 析这一个阶段 注重具体的需 求分析方法 一成不变的观点， 注重“描述”的 方法和过程，是 纯技术性的转换 现代 全过程的，注 重整个产品过 程的全部 功能范围更广， 包括获取、分 析、处理、验 证、实现和全 过程的需求管 理 注重需求实现与 维护过程，处理 不断变更的系统 需求
需求管理存在的问题: ■范围问题:系统目标、边界未被良好定义, 用户和开发团队理解不一致 ■理解问题:用户不能完全了解自己需要什 么,对系统能力、局限更加不清楚;工程 师不理解用户的问题域和应用环境。 ■易变问题:需求随时间发生变化
需求管理存在的问题： ◼ 范围问题：系统目标、边界未被良好定义， 用户和开发团队理解不一致。 ◼ 理解问题：用户不能完全了解自己需要什 么，对系统能力、局限更加不清楚；工程 师不理解用户的问题域和应用环境。 ◼ 易变问题：需求随时间发生变化
需求工程: ■20世纪80年代中期,形成了软件工程的子 领域需求工程。 ■进入20世纪90年代后,需求工程称为软件 界研究的重点之一。 Alan davis把需求工程定义为“直到(但 不包括)把软件分解为实际架构构件之前 的所有活动
需求工程： ◼ 20世纪80年代中期，形成了软件工程的子 领域——需求工程。 ◼ 进入20世纪90年代后，需求工程称为软件 界研究的重点之一。 ◼ Alan Davis 把需求工程定义为“直到（但 不包括）把软件分解为实际架构构件之前 的所有活动
需求工程的阶段划分: 现代软件工程的需求工程 匚需求开发过程 需求管理过程 需求获取 需求实现 需求分析 需求跟踪 需求处理 需求变更控制 需求确认
需求工程的阶段划分： 现代软件工程的需求工程 需求开发过程 需求管理过程 需求获取 需求分析 需求处理 需求确认 需求实现 需求跟踪 需求变更控制
31需求分析的任务 ■确定对系统的综合要求 ■分析系统的数据要求 ■导出系统的逻辑模型 修正系统开发计划
3.1 需求分析的任务 ◼ 确定对系统的综合要求 ◼ 分析系统的数据要求 ◼ 导出系统的逻辑模型 ◼ 修正系统开发计划
311确定对系统的综合要求 1.功能需求 功能 外部功能 内部功能 这方面的需求指定系统必须名称 提供的服务。通过需求分析应 通过应用界面功能按钮通过对查找条件的过滤与 该划分出系统必须完成的所有 用户菜单栏及终端、键盘完数据库互动,从数据库中 功能。 成输入、输出、查找提取相应有关的数据 功能。 2.性能需求 性能需求指定系统必须满足的定时约束或容量约束,通常包括速度 (响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求
1. 功能需求 这方面的需求指定系统必须 提供的服务。通过需求分析应 该划分出系统必须完成的所有 功能。 3.1.1 确定对系统的综合要求 2. 性能需求 性能需求指定系统必须满足的定时约束或容量约束，通常包括速度 (响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求
3.可靠性和可用性需求 可靠性需求定量地指定系统的可靠性。在装载总程序时, 正常就运行,异常就停止,可用性与可靠性密切相关,它量化 了用户可以使用系统的程度。 4.出错处理需求 这类需求说明系统对环境错误应该怎样响应。例如,如果它接收到从 另一个系统发来的违反协议格式的消息,应该做什么?注意,上述这类错 误并不是由该应用系统本身造成的。 在某些情况下,“出错处理”指的是当应用系统发现它自己犯下一个 错误时所采取的行动。但是,应该有选择地提出这类出错处理需求。我们 的目的是开发出正确的系统,而不是用无休止的出错处理代码掩盖自己的 错误。总之,对应用系统本身错误的检测应该仅限于系统的关键部分,而 且应该尽可能少
这类需求说明系统对环境错误应该怎样响应。例如，如果它接收到从 另一个系统发来的违反协议格式的消息，应该做什么?注意，上述这类错 误并不是由该应用系统本身造成的。 在某些情况下，“出错处理”指的是当应用系统发现它自己犯下一个 错误时所采取的行动。但是，应该有选择地提出这类出错处理需求。我们 的目的是开发出正确的系统，而不是用无休止的出错处理代码掩盖自己的 错误。总之，对应用系统本身错误的检测应该仅限于系统的关键部分，而 且应该尽可能少。 3. 可靠性和可用性需求 可靠性需求定量地指定系统的可靠性。在装载总程序时， 正常就运行，异常就停止，可用性与可靠性密切相关，它量化 了用户可以使用系统的程度。 4. 出错处理需求
