软件工程课件第五章.ppt

软件需求工程需求分析与建模需求获取的常用方法需求模型软件需求描述需求管理需求建模示例 第五章需求工程与需求分析 5 1软件需求工程 顾客 用户 开发人员 支持系统开发 用户系统 构建系统 资金 签约 需求 软件系统 图2 4三类软件开发人员之间的关系 软件需求的层次 3个不同的层次 业务需求 用户需求和功能需求业务需求 businessrequirement 反映了组织机构或客户对系统 产品高层次的目标要求 它们在项目视图与范围文档中予以说明 用户需求 userrequirement 文档描述了用户使用产品必须要完成的任务 这使用实例 usecase 文档或方案脚步 scenario 说明中予以说明 功能需求 functionalrequirement 定义了开发者必须实现的软件功能 使得用户能完成他们的任务 从而满足了业务需求 项目愿景与范围 用例模型文档 软件需求规格说明书 软件需求的层次关系 软件需求的特性 功能性 普通功能和全局性功能可用性 用户使用软件的方便程度可靠性 正常运行率 平均无故障时间 平均恢复时间 精确度 最高错误或缺陷率性能 响应时间 吞吐量 容量 资源利用情况可支持性 编码标准 类库 维护工具等设计约束 开发流程 开发工具 系统架构 第三方构件库等 需求分析的步骤 需求获取获取用户对软件功能和界面的需求考虑对质量的要求 包括性能 有效性 可靠性等需求提炼 分析建模建立分析模型 常用的有 数据流图 实体关系图 控制流图 状态转换图 用例图 类对象关系及其行为图等需求描述 编写SRS编写软件规格说明书SRS SoftwareRequirementSpecification 需求验证通过验证完善SRS 确保作为软件设计和最终系统验收的依据 需求获取的困难 误解交流障碍缺乏共同语言完整性问题需求永远不会稳定用户意见不统一错误的需求认识混淆用户的抵触情绪 需求获取技术 建立联合分析小组 考察现场了解用户实际的操作环境 操作过程和操作要求 对照用户提交的问题陈述 对用户需求可以有更全面 更细致的认识 调查研究方式有 发调查表 召开调查会 向用户领域的专家个别咨询 实地考察 跟踪现场业务流程 查阅与待开发系统有关的资料 使用各种调查工具等 市场调查了解市场对待开发软件有什么样的要求 了解市场上有无与待开发软件类似的系统 访问用户和用户领域的专家把从用户那里得到的信息作为重要的原始资料进行分析 访问用户领域的专家所得到的信息将有助于对用户需求的理解 原型化方法 在开发初期 要想得到一个完整准确的规格说明不是一件容易的事 特别是对一些大型的软件项目 用户往往对系统只有一个模糊的想法 很难完全准确地表达对系统的全面要求 软件开发者对于所要解决的应用问题认识更是模糊不清 随着开发工作向前推进 用户可能会产生新的要求 或因环境变化 要求系统也能随之变化 开发者又可能在设计与实现的过程中遇到些没有预料到的实际困难 需要以改变需求来解脱困境 因此规格说明难以完善 需求的变更 以及通信中的模糊和误解 都会成为软件开发顺利推进的障碍 为解决这些问题 逐渐形成了软件系统的快速原型的概念 软件原型的分类 在软件开发中 原型是软件的一个早期可运行的版本 它反映最终系统的部分重要特性 探索型 目的是要弄清对目标系统的要求 确定所希望的特性 并探讨多种方案的可行性 实验型 这种原型用于大规模开发和实现之前 考核方案是否合适 规格说明是否可靠 进化型 这种原型的目的不在于改进规格说明 而是将系统建造得易于变化 在改进原型的过程中 逐步将原型进化成最终系统 原型使用策略 废弃策略演化策略 结构化分析方法 结构化分析方法是一种建模技术在模型的核心是数据词典 它描述了所有的在目标系统中使用的和生成的数据对象 围绕着这个核心的有三种图 实体 关系图 ERD 描述数据对象及数据对象之间的关系 数据流图 DFD 描述数据在系统中如何被传送或变换 以及描述如何对数据流进行变换的功能 子功能 状态 迁移图 STD 描述系统对外部事件如何响应 如何动作 ERD用于数据建模 DFD用于功能建模 STD用于行为建模 结构化分析的分析模型 面向对象分析模型 12 1需求分析与用例建模 12 1 1用例建模概述用例建模的步骤 确定系统的范围和边界确定系统的用例和参与者描述用例对用例分类 并确定用例之间的关系建立用例图 并定义用例图的层次结构 12 1 2确定系统的边界系统范围是指系统问题域的目标 任务 规模以及系统所提供的功能和服务 系统边界是指一个系统内部所有元素与系统外部事物之间的分界线 12 1 3确定系统的参与者系统参与者是指系统的外部事物 包括与系统进行交互的人和其他系统 参与者可以向系统发送消息 也可以从系统中接收消息 确定系统参与者 1 哪些人员使用系统的主要功能 2 哪些人员对系统进行日常的维护和管理 3 哪些人员对系统信息直接进行读写与修改操作 4 哪些人员需要系统的运行结果 5 系统需要哪些硬件设备 6 系统与哪些外部软件系统进行交互 12 1 4确定系统的用例用例表示系统所提供的一项功能 在一个系统中 可以包含多个用例 用例由参与者启动 描述了参与者与系统交互的完整过程 用例分为业务用例和系统用例 业务用例是在确定用户需求时产生 系统分析员通过与用户进行交流 根据业务模型生成业务用例 系统用例是在系统构造阶段产生的 系统分析员与系统设计员在进行系统分析与设计时 根据系统需要建立系统用例 12 1 5描述用例只需描述系统 做什么 不必描述系统 怎么做 例 选课管理子系统 中 选课注册 用例的描述 用例编号 0101用例名称 选课注册执行者 学生功能 实现学生选课注册的过程类型 主要用例 基本用例级别 一级 12 1 5描述用例过程描述 a 学生输入系统帐号和密码 系统进行校验 b 查询课程信息 c 查询个人选课信息 d 若可以选课 则进行选课注册 并将选课信息写入数据库 e 返回选课注册是否成功的信息 异常事件流处理a 学生的帐号和密码错误 允许重新输入 最多3次 b 学生未按时交纳学费 不可选课 c 学生人数以达到最大选课人数 不可选课 12 1 6用例分类 确定用例之间的关系用例之间具有泛化 扩展 包含 关联等各种关系 12 1 7定义用例图的层次结构对于复杂的系统 一般按功能分解为若干子系统 当用例模型描述系统功能时 可将用例图分层 这样可以更加清晰 完整地描述系统功能和层次关系 选课系统 学生 教师 系统管理员 成绩系统 课程系统 教务管理系统 评教系统 选课查询 选课管理 选课注册 选课管理子系统 选课汇总 网上评教 评教汇总 评教管理 评教管理子系统 评教查询 成绩登录 成绩汇总 成绩管理 成绩管理子系统 成绩查询 课程登录 课程汇总 课程管理 课程管理子系统 课程查询 12 1 8软件需求分析规格说明书1引言1 1编写目的及阅读对象1 2项目背景1 3术语定义及概念1 4参考资料2软件项目概述2 1软件运行环境及配置2 2软件的功能2 3用户特征2 4限制与约束 12 1 8软件需求分析规格说明书5系统运行需求5 1用户界面5 2硬件界面5 3软件界面6其他6 1可使用性6 2安全保密性6 3可维护性6 4可移植性 软件需求说明 引言信息描述功能描述行为描述质量保证接口描述其他描述 引言确定软件的目标与范围 简要介绍系统背景 概貌 软件项目约束和参考资料等信息描述给出软件系统所含的详细描述 包括信息的内容 关系 数据流向 控制流向和结构等 功能描述软件功能要求的说明 包括系统功能的划分 每个功能的处理说明 限制和控制描述等 行为描述包括对系统状态变化以及事件和动作的叙述 据此可以检查外部事件和软件内部的控制特征 质量保证阐明在软件交付使用前需要进行的功能测试和性能测试 并规定源程序和文档应该遵守的标准 接口描述包括系统的用户界面 硬件接口 软件接口和通信接口 其他描述系统设计和实现上的限制 系统的假设和依赖等其他需要说明的内容 需求管理 需求应该具有弹性的结构 使之能适应可能的变更 一旦其中有某些需求发生变化 就能确定它可能带来的影响 进而制定出相应的策略 需求管理的内容 需求管理的管理流程 需求确认需求评审和需求承诺需求跟踪建立与维护 需求 设计 编程 测试 之间的一致性 确保所有的工作成果都符合用户的要求 需求变更 需求变更控制 需求变更的利弊需求变更是不可避免的 有些是为了修正缺陷 有些是属于增强功能 为避免出现失控等风险 对纳入基线以前的需求文档 可通过正常的check in和check out进行更改 而纳入基线以后的需求文档 更需按照预定的变更控制规程 确保快速 顺利和有序地进行变更 需求变更的流程 变更申请 审批 更改 重新确认变更申请1 变更源类型2 变更优先级3 变更标注4 变更影响分析5 可能影响的工作产品 需求变更的流程 变更申请 审批 更改 重新确认变更审批1 影响小由项目经理审批 2 影响大提交软件变更控制委员会 SoftwareChangeControlBoard SCCB 审批 3 SCCB无法决定的变更 提交更高层决定 需求变更的流程 变更申请 审批 更改 重新确认变更修改1 及时更新需求大纲 需求分析说明2 修改项目计划3 更新概要设计 详细设计文档 源代码和程序 测试计划和测试用例 用户手册等4 进行回归测试5 注明修改人 修改时间及修改原因6 原文件修改过大 可重新组织评审7 代码修改要重新编译和测试 需求变更的流程 变更申请 审批 更改 重新确认变更修改1 及时更新需求大纲 需求分析说明2 修改项目计划3 更新概要设计 详细设计文档 源代码和程序 测试计划和测试用例 用户手册等4 进行回归测试5 注明修改人 修改时间及修改原因6 原文件修改过大 可重新组织评审7 代码修改要重新编译和测试 需求变更的流程 变更申请 审批 更改 重新确认变更关闭1 如果测试未通过 返回修改者继续修改2 所有工作产品全部修改完成 测试通过 关闭该变更 记录需求变更的数据项见P128页 类似与软件配置管理 需求管理工具 手工维护的局限性1 维护大量文档困难2 很难保持文档和程序的一致性3 通知受影