软件工程概论需求分析PPT课件

1 软件工程概论SoftwareEngineering 贾恒彬E mail jiahengbin 李恒E mail liheng 2 第3章需求分析 软件工程师所解决的问题往往十分复杂 尤其是开发全新的系统时 了解问题的性质可能是非常困难的 因此 搞清楚系统应该做什么也是困难的 对系统应提供的服务和所受到的约束的描述就是系统需求关心的内容 对服务和约束的发现 分析 建立文档 检验的过程叫做需求工程 软件需求分析是软件生存周期中最关键一步 3 第3章需求分析 3 1软件需求分析的基本概念3 2软件需求3 3需求工程3 4图形工具3 5验证软件需求 4 3 1软件需求分析的基本概念 3 1 1需求分析定义百度百科的定义所谓 需求分析 是指对要解决的问题进行详细的分析 弄清楚问题的要求 包括需要输入什么数据 要得到什么结果 最后应输出什么 可以说 在软件工程当中的 需求分析 就是确定要计算机 做什么 通俗的定义在软件工程中 需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的 范围和定义时所要做的所有的工作 需求分析是软件工程中的一个关键过程 在这个过程中 系统分析员和软件工程师确定顾客的需要 只有在确定了这些需要后 他们才能够分析和寻求新系统的解决方法 在软件工程的历史中 很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤 但在过去十年中越来越多的人认识到它是整个过程中最关键的一个过程 假如在需求分析时分析者们未能正确地认识到顾客的需要的话 那么最后的软件实际上不可能达到顾客的真正需要 或者软件无法在规定的时间里完工 5 3 1 2软件需求分析概述 软件需求分析的任务软件需求分析的任务是准确地定义未来系统的目标 确定为了满足用户的需求 系统必须做什么 用 需求规格说明书 规范的形式准确地表达用户的需求 以及对需求进行审查 需求分析的具体内容包括深入描述软件的功能和性能确定软件设计的约束确定软件同其他系统元素的接口细节定义软件的其他有效性需求需求分析阶段的产品 需求规格说明书 6 3 1 3软件需求分析的任务 由于需求分析方法不同 描述形式不同 其实现步骤如下图所示 7 3 1 3软件需求分析的任务 8 3 1 3软件需求分析的任务 根据上述分析得知 需求分析的具体任务是 1 确定系统的综合要求 确定系统功能要求 这是最主要的需求 确定系统必须完成的所有功能 确定系统性能要求 应而就具体系统定 例如可靠性 联机系统的响应时间 存储容量 安全性能等 确定系统运行要求 主要是对系统运行时的环境要求 如系统软件 数据库管理系统 外存和数据通信接口等 将来可能提出的要求 对将来可能提出的扩充及修改作预准备 9 3 1 3软件需求分析的任务 2 分析系统的数据要求软件系统本质上是信息处理系统 因此 必须考虑 数据 需要哪些数据 数据间联系 数据性质 结构 数据处理 处理的类型 处理的逻辑功能 3 导出系统的逻辑模型 通常系统的逻辑模型用DFD图来描述 4 修正系统的开发计划 通过需求对系统的成本及进度有了更精确的估算 可进一步修改开发计划 10 3 1 4需求分析原则 近几年来已提出许多软件需求分析与说明的方法 每一种分析方法都有独特的观点和表示方法 但都适用下面的基本原则 1 能够表达和理解问题的信息域和功能域对于计算机程序处理的数据 其信息域包括信息流 如下图 即数据通过一个系统时的变化方式 信息内容和信息结构 而功能域反映上述三方面的控制信息 11 3 1 4需求分析原则 2 建立描述系统信息 功能和行为的模型建立模型的过程是 逐步精化 的综合分析的过程 通过对模型的不断深化认识 来达到对实际问题的深刻认识 3 能够对问题进行分解和不断细化 建立问题的层次结构 分解是为了降低问题的复杂性 增加问题的可解性和可描述性 分解可以在同一个层次上进行 横向分解 也可以在多层次上进行 纵向分解 12 3 1 4需求分析原则 4 需要给出系统的逻辑视图和物理视图软件需求的逻辑视图给出的是软件要达到的功能和要处理信息之间的关系 而不是实现的细节 软件需求的物理视图给出的是处理功能和信息结构的实际表现形式 这往往是由设备本身决定的 请同学们特别注意 需求分析只研究软件系统 做什么 而不考虑 怎样做 13 3 1 5需求分析方法 不同的开发方法 需求分析的方法也有所不同 常见的分析方法有 功能分析方法将系统看作若干功能模块的集合 每个功能又可以分解为若干子功能 子功能还可继续分解 分解的结果已经是系统的雏形 结构化分析方法是一种以数据 数据的封闭性为基础 从问题空间到某种表示的映射方法 由数据流图 DFD图 表示 14 3 1 5需求分析方法 信息建模法是从数据的角度对现实世界建立模型的 基本工具是E R图 面向对象的分析方法面向对象的分析方法 OOA 的关键是识别问题域内的对象 分析它们之间的关系 并建立起模型 15 3 1 5需求分析工作流程 16 3 2软件需求 3 2 1需求定义权威的定义 IEEE软件工程标准词汇表中的定义 用户解决问题或达到目标所需要的条件或权能系统或系统部件要满足合同 标准 规范或其他正式规定文档所要具有的条件或权能反映上面两条的文档说明IEEE公布的需求定义分别从用户和开发者的角度阐明了什么是需求 需求一方面反映了系统的外部行为 另一方面反映了系统的内部特性 反映的方式是需求文档 通俗的定义需求是指明系统必须实现什么的规格说明 他描述了系统的行为 特性或属性 是在开发过程中对系统的约束 17 3 2 1需求分类 软件需求一般包括功能需求和非功能需求 1 功能需求包括对系统应该提供的服务 如何对输入做出反映以及系统在特定条件下的行为的描述 在某些情况下 功能需求可能还需要声明系统不应该做什么 18 3 2 1需求分类 2 非功能需求非功能需求是对系统提供的服务或功能给出的约束 包括时间约束 开发过程约束 标准等 非功能需求比功能需求更关键许多非功能需求关心的是系统的整体特性而不是个别的系统特性 一个功能需求没有满足可能会降低系统的能力 而一个非功能需求没有满足则可能使整个系统无法使用例如 如果一个飞机系统不符合可靠性要求 它将不会被批准飞行 如果一个实时控制系统无法满足其性能需求 控制功能可能根本无法使用 19 3 2 1需求分类 2 非功能需求性能需求软件开发的技术性能指标 包括对存储容量 运行时间的限制 安全保密性要求等 例如 系统的最大客户容量 运行的峰值速度 平均速率 充分运行时最少需要多少内存 同步问题等环境需求对软件系统运行时所处环境的要求 包括硬件方面 软件方面 使用方面等可用性需求人机界面友好 使用舒适 可理解性好 可修改性好 20 3 2 1需求分类 2 非功能需求可移植性需求可靠性需求在一定的环境下以用户能够接受的方式运行时所表现出来的始终如一的能力 硬件方面 系统的平均失效时间 系统的平均故障间隔时间 失效率软件方面 出错保障能力 健壮性 内部信息的一致性 错误识别能力资源使用需求 件运行时所需的数据 软件 内存空间等资源软件成本消耗与开发进度需求等 21 3 2 2高质量的软件需求应该具备的特征 完整性不能遗漏任何必要的需求每一项需求要完成的任务必须要描述清楚 以便开发人员明白实现这项需求的所有信息 用户能够审查这项需求描述的正确性 22 3 2 2高质量的软件需求应该具备的特征 需求描述举例 如果电话A呼叫电话B并且电话B空闲 那么电话B应该响铃 改进1 如果A呼叫B并且B空闲 那么除B响铃外 其他所有电话都不响铃 改进2 在需求规格说明书的开头加上 系统只做需求规格说明书中要求做的事 而不做别的 测试中出现问题 A呼叫空闲的B时 所有的铃都响了 测试中又出现问题 与此同时 C也有正当的响铃理由 23 3 2 2高质量的软件需求应该具备的特征 无二义性不同的人员对需求的理解应该是一致的 一般情况下 描述需求都使用自然语言 因此容易引起需求理解的二义性 24 3 2 2高质量的软件需求应该具备的特征 需求描述举例 发现任何不友好且带有未知任务的或者有可能在5分钟内飞入空中禁区的飞行物时 要拉响警报 上述需求描述的是 说明针对军事系统中空中禁区受到入侵时的报警事件讨论 以下情况是否拉警报有明确任务的不友好飞行物无明确任务的不友好飞行物 25 3 2 2高质量的软件需求应该具备的特征 正确性每项需求都必须准确地反映用户要完成的任务可行性每一个成功的软件系统其解决方案都应该是可行的 可行性体现在技术 经济 操作可行性必要性每项需求都应该是客户所需要的 开发人员不要自作主张添加需求划分优先级为每项需求按重要程度分配一个优先级 有助于项目管理者决冲突 安排阶段性交付 在必要时作出功能取舍 以最小的费用获得产品最大的功能 26 3 2 2高质量的软件需求应该具备的特征 可验证性例 系统目标 系统很好用 即使对于一个没有经验的用户 而且应该使用户错误降到最少 可验证的非功能需求 对一个没有经验的用户来说 经过2小时的培训应该能够使用系统的所有功能 在这样的培训之后 一个有经验的用户每天的出错平均数不应超过2次 27 3 2 2高质量的软件需求应该具备的特征 指定非功能需求的度量理论上 非功能需求能够量化 从而使其验证更为可观 在实际过程中 对需求描述的量化通常是很困难的 28 3 2 3获取需求的方法 访谈 访谈是最早开始使用的获取用户需求的技术 也是迄今为止仍然广泛使用的需求分析技术 访谈有两种基本形式 分别是正式的和非正式的访谈 正式访谈时 系统分析员将提出一些事先准备好的具体问题 在非正式访谈中 分析员将提出一些用户可以自由回答的开放性问题 以鼓励被访问人员说出自己的想法 29 3 2 3获取需求的方法 面向数据流自顶向下求精数据决定了需要的处理和算法 数据显然是需求分析的出发点 结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法 把一个复杂的问题划分成若干小问题 然后再分别解决 将问题的复杂性降低到人可以掌握的程度 分解的方法可分层进行 方法原理是先考虑问题最本质的方面 忽略细节 形成问题的高层概念 然后再逐层添加细节 即在分层过程中采用不同程度的 抽象 级别 最高层的问题最抽象 而低层的较为具体 30 3 2 3获取需求的方法 面向数据流自顶向下求精 31 3 2 3获取需求的方法 面向数据流自顶向下求精当认为某一层比较复杂时到底应该划分为多少个子系统 针对不同的系统的处理不同 划分的原则可以根据业务工作的范围 功能性质 被处理数据对象的特点 一般情况下上面一些层的划分往往按照业务类型划分的比较多 下面一些层往往按照功能的划分比较多 依照这个策略 对于任何复杂的系统 分析工作都可以有计划 有步骤及有条不紊地进行 32 3 3需求工程 问题识别 分析与综合 编写文档 分析评审 双方确定问题的综合需求 这些需求包括功能需求 最主要的需求 性能需求 环境需求和用户界面需求 另外还有可靠性 安全性 保密性 可移植性和可维护性等方面的需求 33 3 3需求工程 问题识别 分析与综合 编写文档 分析评审 导出软件的逻辑模型 34 3 3需求工程 问题识别 分析与综合 编写文档 分析评审 编写 需求说明书 把双方共同的理解与分析结果用规范的方式描述出来 编写初步用户使用手册 编写确认测试计划 修改完善项目开发计划 35 3 3需求工程 问题识别 分析与综合 编写文档 分析评审 作为需求分析阶段工作的复查手段 应该对功能的正确性 完整性和清晰性 以及其他需求给予评价 36 3 3 1需求工程的定义 需求工程是指系统分析人员通过细致的调研分析 准确地理解用户的需求 将不规范的需求陈述转化成完整的需求定义 再将需求定义写成需求规格说明书以及需求审查的过程 37 3 3 2需求工程的重要性 事实需求工程处于或接近于软件工程过程的开始阶段 它提供了软件项目其余部分得以构建的根基 如果你在开发的后期阶段出错 受到影响的仅仅是那些与后期阶段相关的工作 而修正错误通常也是相对简单的事情 然而 如果错误出现在接近开始的阶段 而且并未立即予以纠正 那么所有后续阶段的工作都是在错误的基础上进行的 修正错误的代价将飞速增加 通常情况下重新开发也许更为经济 需求问题是造成软件工程项目失败的主要原因 这已经是一个不争的事实 38 3 3 2需求工程的重要性 需求错误放大示意图 一个错误的需求纠正成本100元 X10纠正成本1 000元 X10纠正成本10 000元 X5纠正成本50 000元 39 3 3 2需求工程的重要性 有关软件错误的一些事实在软件生命周期中 一个错误发现的越晚 修复错误的费用越高许多错误是潜伏的 并且在错误产生后很长一段时间才被检查出来在需求过程中产生很多的错误在需求阶段 代表性的错误为疏忽 不一致和二义性需求错误是可以被检查出来规模的大小是问题的关键 拿建筑作类比 花园棚发生倾斜 塞几块砖即可扶正 几乎不需费用 房屋因地基不牢发生倾斜 打桩止陷 相当可观的费用 高层建筑发生倾斜 最好不要让它发生 40 3 3 3需求工程的主要活动内容 软件需求工程的主要活动内容包括 需求获取需求分析编写需求规格说明书需求审查还有需求管理 包括需求变更控制 需求跟踪等 41 3 3 3 1需求获取 需求获取需要考虑的三个问题 应当收集什么信息 能从什么来源中来收集 可能通过什么机制或技术来收集问题1 需求获取的信息问题的描述要求解决问题的列表用户对系统的行为或结构施加的任何约束 42 3 3 3 1需求获取 问题2 信息的主要来源客户 实际的和潜在的 客户的规格说明书任何原有的系统及其文档原有系统的用户新系统的潜在用户原有产品 开发者的其他产品 执行与可能要开发的产品相似的功能竞争对手的产品应用领域专家相关的技术标准和法规 43 3 3 3 1需求获取 问题3 需求获取的技术背景资料阅读面谈调查表文档检查任务观察讨论分析头脑风暴用例和场景 44 3 3 3 1需求获取 系统分析人员应该在调研前做充分的准备 针对具体项目的特点设计一些问题和表格 在实际项目中应该根据项目的规模 涉及的业务领域 有针对性的设计一些特别的问题 下面给出一组比较通用的调研问题供参考 45 3 3 3 1需求获取 调研的基本问题部门的名称 人员数量和结构部门发展或变化简单介绍部门的主要任务业务处理流程业务处理流程中涉及那些专业领域的知识工作需要的审批流程是什么 主要算法描述那些业务需要实时处理那些业务需要交互操作部门各岗位的职责 46 3 3 3 1需求获取 部门接收哪些部门或外界的信息 信息内容和格式要求是什么 部门产生哪些信息 部门产生的信息送到哪些其他部门 格式要求是什么 对信息的输入和输出方式有要求吗 输入输出设备是什么数据要求实时备份吗 备份的设备是什么 时间策略 业务处理有高峰期吗 高峰时间是什么时候 业务量有多少 现有的哪些设备要继续使用 对产品的运行环境有要求吗 47 3 3 3 1需求获取 对界面风格和操作方式有要求吗 在系统运行过程中允许停机吗 操作方式要根据操作环境和使用人员素质分类吗需要的操作权限有哪些 需要记录系统操作运行日志吗 用户有能力进行系统维护吗 需要分布式处理吗 需要什么方式的用户操作培训 需要制作联机帮助吗 48 3 3 3 1需求获取 某出版社系统调查表 49 3 3 3 2需求分析 需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型 解决目标系统的 做什么 的问题 需求分析的具体任务获得当前系统的物理模型抽象出当前系统的逻辑模型建立目标系统的逻辑模型 需求分析建立模型的过程示意图 50 3 3 3 2需求分析 需求分析建立建模的过程 示例 通过对现实环境的调查 获得当前系统的物理模型 如下图是学生购买教材软件系统的实际建立模型过程分析 学生购买教材的实际处理流程 当前系统物理模型 51 3 3 3 2需求分析 需求分析建立建模的过程 示例 续 去掉具体模型中的非本质因素 抽取现实系统的实质 抽象出当前系统的逻辑模型 学生购买教材的逻辑模型 52 3 3 3 2需求分析 需求分析建立建模的过程 示例 续 分析当前系统与目标系统的差别 建立目标系统的逻辑模型对目标系统的逻辑模型进行改进与优化 需求分析的验证 计算机教材管理系统的逻辑模型 53 3 3 3 2需求分析 需求分析建模方法 软件系统的本质示意图 现实世界与计算机世界对比 软件开发过程实质是 人通过抽象 归纳把客观系统变换到软件系统 并保证软件系统的解等价客观系统的解 由于客观系统与软件系统差异很大 所以变换过程必须通过一个中间过渡系统 不同的软件开发模型采用不同的过渡系统完成变换过程 54 3 3 3 2需求分析 结构化分析模型结构分析方法也就是面向数据流的分析方法 它是最基本的图形模型是数据流图和数据字典 在表示复杂数据模型时 一般要求建立实体关系图 ER模型 另外也可建立状态迁移图 ER模型是对数据对象的说明 而数据流图是对加工说明 也就是对数据对象的加工说明 状态变迁图是对控制信息的说明 数据字典就是对系统的数据结构进行模型化的描述 55 3 3 3 2需求分析 结构化分析模型 结构化分析方法是抽象模型的概念 按照软件内部数据传递 变换的关系 自顶向下逐层分解 直到找到满足功能要求的所有可实现的软件为止 抽象和分解是这个方法的主要手段 由于数据传递与变换而形成的数据流 是这个方法的主要依据 56 1 2更新库存清单 仓库管理员 事务 定货报表 2产生报表 D2定货信息 D1库存清单 库存清单 定货信息 定货信息 1 1接受事务 1 3处理定货 事务 库存信息 定货系统数据流图 57 3 3 3 2需求分析 面向对象分析模型面向对象分析建模型方法是当前使用最多的方法 主要由现在都是采用面向对象语言编程 目前采用UML模型来建立其分析模型结构 UML综合其他几种面向对象分析模型 采用很多种模型方法从不同视角也描述软件逻辑模型 比如 它包括用例图 类图 顺序图 状态图 协作图 其分化为类模型 行为模型 关系模型 还有协作等模型 所以它有很多模型方法来描述软件结构 58 支持需求分析的原型化方法 原型是指模拟某种产品的原始模型 在软件开发中 原型是软件的一个早期可运行的版本 它反映最终系统的部分重要特性 如果在获得一组基本需求说明后 通过快速分析构造出一个小型的软件系统 满足用户的基本要求 使得用户可在试用原型系统的过程中得到亲身感受和受到启发 做出反应和评价 然后开发者根据用户的意见对原型加以改进 随着不断试验 纠错 使用 评价和修改 获得新的原型版本 如此周而复始 逐步减少分析和通信中的误解 弥补不足之处 进一步确定各种需求细节 适应需求的变更 从而提高了最终产品的质量 59 支持需求分析的原型化方法 1 开发原型系统原因把建立原型系统作为一种可能采取的策略的主要理由 人类受认识能力局限 不能预先指定所有要求 在用户和系统分析员之间存在固有的通信鸿沟 用户需要 活的 系统模型 以便获得实践经验 在开发过程中重复和反复是必要和不可避免的 目前有快速建立原型系统的工具可供选用 RationalRose 60 支持需求分析的原型化方法 1 开发原型系统原因在开发初期 要想得到一个完整准确的规格说明不是一件容易的事 特别是对一些大型的软件项目 用户往往对系统只有一个模糊的想法 很难完全准确地表达对系统的全面要求 软件开发者对于所要解决的应用问题认识更是模糊不清 61 支持需求分析的原型化方法 1 开发原型系统原因随着开发工作向前推进 用户可能会产生新的要求 或因环境变化 要求系统也能随之变化 开发者又可能在设计与实现的过程中遇到些没有预料到的实际困难 需要以改变需求来解脱困境 因此规格说明难以完善 需求的变更 以及通信中的模糊和误解 都会成为软件开发顺利推进的障碍 为解决这些问题 逐渐形成了软件系统的快速原型的概念 62 支持需求分析的原型化方法 2 原型的分类废弃型 先构造一个功能简单而且质量要求不高的模型系统 针对这个模型系统反复进行分析修改 形成比较好的设计思想 据此设计出更加完整 准确 一致 可靠的最终系统 系统构造完成后 原来的模型系统就废弃不用 探索型 目的是要弄清对目标系统的要求 确定所希望的特性 并探讨多种方案的可行性 它主要针对开发目标模糊 用户和开发者对项目都缺乏经验的情况实验型 用于大规模开发和实现之前 考核方案是否合适 规格说明是否可靠追加型或演化型 先构造一个功能简单而且质量要求不高的模型系统 作为最终系统的核心 然后通过不断地扩充修改 逐步追加新要求 最后发展成为最终系统 63 支持需求分析的原型化方法 3 原型类型的选择系统结构 联机事务处理系统 相互关联的应用系统适合于用原型化方法 而批处理 批修改等结构不适宜用原型化方法逻辑结构 有结构的系统 如操作支持系统 管理信息系统 记录管理系统等适合于用原型化方法 而基于大量算法的系统不宜用原型化方法 用户特征 不满足于预先做系统定义说明 愿意为定义和修改原型投资 不易肯定详细需求 愿意承担决策的责任 准备积极参与的用户是适合于使用原型的用户 64 支持需求分析的原型化方法 3 原型类型的选择 续 应用约束 对已经运行系统的补充 不能用原型化方法 项目管理 项目负责人愿意使用原型化方法 才适合于用原型化的方法 项目环境 需求说明技术应当根据每个项目的实际环境来选择 当系统规模很大 要求复杂 系统服务不清晰的时候 在需求分析阶段先开发一个系统原型是很值得的 特别是当性能要求比较高时 在系统原型上先做一些试验也是很必要的 65 支持需求分析的原型化方法 4 原型化分析的好处 增进软件者和用户对系统服务需求的理解 使比较含糊的具有不确定性的软件需求 主要是功能 明确化 软件原型化方法提供了一种有力的学习手段 66 支持需求分析的原型化方法 4 原型化分析的好处 使用原型化方法 可以容易地确定系统的性能 确认各项主要系统服务的可应用性 确认系统设计的可行性 确认系统作为产品的结果 软件原型的最终版本 有的可以原封不动地成为产品 有的略加修改就可以成为最终系统的一个组成部分 这样有利于建成最终系统 67 支持需求分析的原型化方法 5 原型开发技术可执行规格说明基于场景的设计自动程序设计专用语言软件复用技术简化假设 68 3 3 3 3编写需求规格说明书 需求规格说明书需求工程最大的成果是得到需求规格说明书 需求规格说明书是软件产品开发过程中唯一与用户共同协商 共同起草的一个文件 它包含了用户方和开发方两方面的意见 需求规格说明书作为系统开发各方的共识 是对系统进行设计 实现 测试和验收的基本依据项目经理根据它制定开发计划设计人员根据它进行系统设计测试人员根据它编写测试计划 设计测试用例维护人员根据它理解系统及其中的各个部分间的关系用户根据它进行系统的验收 检查系统是否符合要求 69 3 3 3 3编写需求规格说明书 制定软件需求规格说明的原则原则1 功能与实现分离 即描述要 做什么 而不是 怎样实现 原则2 要求使用面向处理的规格说明语言 讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应 来定义一个行为模型 从而得到 做什么 的规格说明 原则3 如果目标软件只是一个大系统中的一个元素 那么整个大系统也包括在规格说明的描述之中 描述该目标软件与系统的其他系统元素交互的方式 原则4 规格说明必须包括系统运行的环境 原则5 系统规格说明必须是一个认识的模型 而不是设计或实现的模型 70 3 3 3 3编写需求规格说明书 制定软件需求规格说明的原则原则6 规格说明必须是可操作的 规格说明必须是充分完全和形式的 以便能够利用它决定对于任意给定的测试用例 已提出的实现方案是否都能满足规格说明 原则7 规格说明必须容许不完备性并允许扩充 原则8 规格说明必须局部化和松散的耦合 它所包括的信息必须局部化 这样当信息被修改时 只要修改某个单个的段落 理想情况 同时 规格说明应被松散地构造 即耦合 以便能够很容易地加入和删去一些段落 71 3 3 3 3编写需求规格说明书 需求规格说明书框架 1引言2任务描述3数据描述4功能需求5性能需求6运行需求7其他需求 72 3 3 3 4需求审查 需求审查的主要内容系统定义的目标是否与用户的要求一致系统需求分析阶段提供的文档资料是否齐全文档中的所有描述是否完整 清晰 准确反映用户要求与所有其他系统成分的重要接口是否都已经描述被开发项目的数据流与数据结构是否足够 确定所有图表是否清楚 在不补充说明时能否理解主要功能是否已包括在规定的软件范围之内 是否都已充分说明软件的行为和它必须处理的信息 必须完成的功能是否一致 73 3 3 3 4需求审查 需求审查的主要内容设计的约束条件或限制条件是否符合实际是否考虑了开发的技术风险是否考虑过软件需求的其他方案是否考虑过将来可能会提出的软件需求是否详细制定了检验标准 它们能否对系统定义是否成功进行确认有没有遗漏 重复或不一致的地方用户是否审查了初步的用户手册或原型软件开发计划中的估算是否受到了影响 74 3 4图形工具 在描绘复杂关系时 图形比文字叙述优越得多 它形象直观 本节简要介绍需求分析阶段可能用到的三种图形工具 75 3 4 1层次方框图 层次方框图用树形结构的一系列多层次的矩形框描述数据的层次结构 树形结构的顶层是一个单独的矩形框 它代表完整的数据结构 下面的各层矩形框代表这个数据的子集 最底层的各个框代表组成这个数据的实际数据元素 不能再分割的元素 76 3 4 1层次方框图 随着结构的精细化 层次方框图对数据结构的描绘也越来越详细 这种模式非常适合于需求分析阶段的需要 系统分析员从对顶层信息的分类开始 沿图中每条路径反复细化 直到确定了数据结构的全部细节为止 例如 描绘一家计算机公司全部产品的数据结构可以用层次方框图表示 77 3 4 1层次方框图 定货报表 零件编号 零件名称 定货数量 目前价格 定货报表的层次方框图 78 3 4 2Warnier图 法国计算机科学家Warnier提出了表示信息层次结构的另一种图形工具 比层次方框图提供了更丰富的手段 用Warnier图可以表明信息的逻辑组织 也就是说 它可以指出一类信息或一个信息量是重复出现的 也可以表示特定信息在某一类信息中是有条件地出现的 79 3 4 2Warnier图 花括号 区分数据结构的层次 在一个花括号内的所有名字都属于同一类信息 异或符号 表明一类信息或一个数据元素在一定条件下才出现 而且在这个符号上 下方的两个名字所代表的数据只能出现一个 圆括号 中间的数字指明了这个名字代表的信息类 或元素 在这个数据结构中重复出现的次数 80 定货报表 零件编号 字符 8 零件名称 字符 1 20 定货数量 整数 1 5 目前价格 实数 主要供应商 供应商编号 字符 8 供应商名称 字符 1 20 供应商地址 字符 1 50 次要供应商 供应商编号 字符 8 供应商名称 字符 1 20 供应商地址 字符 1 50 定货报表的Warnier图 81 3 4 3IPO图 IPO图是输入 处理 输出图的简称 它是美国IBM公司发展完善起来的一种图形工具 能够方便地描绘输入数据 数据处理和输出数据之间的关系 左框 列出输入数据 中框 列出主要的处理 次序暗示了执行的顺序 右框 列出输出数据粗大箭头 指出数据通信的情况 82 3 4 3IPO图 83 3 4 3IPO图 84 3 4 3IPO图 在需求分析阶段可以使用IPO图简略地描述系统的主要算法 即数据流图中各个处理的基本算法 当然 在需求分析阶段 IPO图中的许多附加信息暂时还不具备 但是在软件设计阶段可以进一步补充修正这些图 作为设计阶段的文档 85 3 5软件需求验证 3 5 1从哪些方面验证软件需求的正确性软件系统中15 的错误起源于错误的需求 因此 应该从下述4个方面进行验证 1 一致性 需求不能和其他需求互相矛盾 2 完整性 规格说明书应该包括用户需要的每一个功能或性能 3 现实性 指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的 4 有效性 必须证明需求是正确有效的 确实能解决用户面对的问题 86 3 5 2软件需求验证方法 1 验证需求的一致性自然语言书写的需求 除了靠人工技术审查验证软件系统规格说明书的正确性之外 目前还没有其他更好的 测试 方法 由于人工审查的效果是没有保证的 冗余 遗漏和不一致等问题可能没被发现而继续保留下来 以致软件开发不能在正确的基础上顺利进行 形式化的描述软件需求的方法较好地弥补了上述缺点 87 3 5 2软件需求验证方法 2 验证需求的现实性为了验证需求的现实性 分析员应该参照以往开发类似系统的经验 分析用现有的软 硬件技术实现目标系统的可能性 必要的时候应该采用仿真或性能模拟技术 辅助分析软件需求规格说明书的现实性 88 3 5 2软件需求验证方法 3 验证需求的完整性和有效性只有目标系统的用户才真正知道软件需求规格说明书是否完整 准确地描述了他们的需求 然而许多用户只有当他们有某种工作着的软件系统可以实际使用和评价时 才能完整确切地提出他们的需要 使用原型系统是一个比较现实的方法 89 3 5 3需求评审 90 附1需求管理 需求管理是一组用于帮助项目组在项目进展中的任何时候去标识 控制和跟踪需求的活动需求跟踪有两种方式 正向跟踪与逆向跟踪正向跟踪 以用户需求为切入点 检查 需求规约 中的每个需求是否都能在后继工作产品中找到对应点逆向跟踪 检查设计文档 代码 测试用况等工作产品是否都能在 需求规约 中找到出处 91 需求管理 92 附2实体 联系图 E R图 1 两个实体型之间的联系用图形来表示两个实体型之间的这三类联系 93 实体 联系图 E R图 一对一联系 1 1 实例一个班级只有一个正班长一个班长只在一个班中任职定义 如果对于实体集A中的每一个实体 实体集B中至多有一个 也可以没有 实体与之联系 反之亦然 则称实体集A与实体集B具有一对一联系 记为1 1 94 实体 联系图 E R图 一对多联系 1 n 实例一个班级中有若干名学生 每个学生只在一个班级中学习定义 如果对于实体集A中的每一个实体 实体集B中有n个实体 n 0 与之联系 反之 对于实体集B中的每一个实体 实体集A中至多只有一个实体与之联系 则称实体集A与实体集B有一对多联系 记为1 n 95 实体 联系图 E R图 多对多联系 m n 实例课程与学生之间的联系 一门课程同时有若干个学生选修一个学生可以同时选修多门课程定义 如果对于实体集A中的每一个实体 实体集B中有n个实体 n 0 与之联系 反之 对于实体集B中的每一个实体 实体集A中也有m个实体 m 0 与之联系 则称实体集A与实体B具有多对多联系 记为m n 96 实体 联系图 E R图 2 两个以上实体型之间的联系两个以上实体型之间一对多联系若实体集E1 E2 En存在联系 对于实体集Ej j 1 2 i 1 i 1 n 中的给定实体 最多只和Ei中的一个实体相联系 则我们说Ei与E1 E2 Ei 1 Ei 1 En之间的联系是一对多的 97 实体 联系图 E R图 实例课程 教师与参考书三个实体型一门课程可以有若干个教师讲授 使用若干本参考书 每一个教师只讲授一门课程 每一本参考书只供一门课程使用 98 实体 联系图 E R图 多个实体型间的一对一联系一对夫妇一个孩两个以上实体型间的多对多联系供应商 项目 零件三个实体型一个供应商可以供给多个项目多种零件 每个项目可以使用多个供应商供应的零件每种零件可由不同供应商供给 99 实体 联系图 E R图 3 ER图 概念模型的一种表示方法实体 联系方法 E R方法 用E R图来描述现实世界的概念模型E R方法也称为E R模型 100 实体 联系图 E R图 实体型用矩形表示 矩形框内写明实体名 属性用椭圆形表示 并用无向边将其与相应的实体连接起来 学生 教师 101 实体 联系图 E R图 联系联系本身 用菱形表示 菱形框内写明联系名 并用无向边分别与有关实体连接起来 同时在无向边旁标上联系的类型 1 1 1 n或m n 102 实体 联系图 E R图 联系的表示方法 103 实体 联系图 E R图 联系的表示方法示例 104 实体 联系图 E R图 联系的属性 联系本身也是一种实体型 也可以有属性 如果一个联系具有属性 则这些属性也要用无向边与该联系连接起来 105 实体 联系图 E R图 4 一个实例 用E R图表示某个工厂物资管理的概念模型实体仓库 仓库号 面积 电话号码零件 零件号 名称 规格 单价 描述供应商 供应商号 姓名 地址 电话号码 帐号项目 项目号 预算 开工日期职工 职工号 姓名 年龄 职称 106 实体 联系图 E R图 实体之间的联系如下 1 一个仓库可存放多种零件 一种零件可以存放在多个仓库中 仓库和零件具有多对多的联系 用库存量来表示某种零件在某个仓库中的数量 2 一个仓库有多个职工当仓库保管员 一个职工只能在一个仓库工作 仓库和职工之间是一对多的联系 职工实体型中具有一对多的联系 107 实体 联系图 E R图 3 职工之间具有领导 被领导关系 即仓库主任领导若干保管员 4 供应商 项目和零件三者之间具有多对多的联系 108 实体 联系图 E R图 109 面向数据流的分析过程 任何信息处理系统的基本功能都是把输入数据转变成需要的输出信息 数据决定了需要的处理和算法 看来数据显然是分析的出发点 结构化分析方法 简称SA方法 就是面向数据流自顶向下逐步求精进行需求分析的方法 110 面向数据流的分析过程 通过可行性研究已经得出了目标系统的高层数据流图 需求分析的目的之一就是把数据流和数据存储定义到元素级 为了达到这个目的 通常从数据流图的输出端着手分析 这是因为系统的目标是产生这些输出 输出数据确定了系统必须具有的最基本的组成元素 111 1 沿数据流图回溯 输出数据是由哪些元素组成的呢 每个输出数据元素又是从哪里来的呢 沿数据流图从输出端往输入端回溯 应该能够确定每个数据元素的来源 与此同时也就初步定义了有关的算法 112 1 沿数据流图回溯 沿数据流图回溯时常常遇到下述问题 为了得到某个数据元素需要用到数据流图中目前还没有的数据元素 或者得出这个数据元素需要用的算法尚不完全清楚 113 1 沿数据流图回溯 为了解决这些问题 往往需要向用户和其他有关人员请教 他们的回答使分析员对目标系统的认识更深入更具体了 系统中更多的数据元素被划分出来了 更多的算法被搞清楚了 114 1 沿数据流图回溯 通常把分析过程中得到的有关数据元素的信息记录在数据字典中 把对算法的简明描述记录在IPO图中 通过分析而补充的数据流 数据存储和处理 应该添加到数据流图的适当位置上 115 2 用户复查 从输入端开始 分析员借助数据流图以及数据字典和简明的算法描述向用户解释输入数据是怎样一步一步地转变成输出数据的 用户应该注意倾听分析员的报告 并及时纠正和补充分析员的认识 复查过程验证了已知的元素 补充了未知的元素 填补了文档中的空白 116 2 用户复查 追踪数据流图和复查系统的逻辑模型这两个步骤实质上构成一个循环 在分析员对目标系统的认识螺旋式上升的过程中 用户及其他和系统有关的人员的参与是必不可少的 分析过程中产生的问题依靠他们来回答 分析员对系统的更深入的认识必须经过他们的检验和确认 117 3 细化数据流图 通过功能分解可以完成数据流图的细化 在数据流图中选出一个功能比较复杂的处理 并把它的功能分解成若干个子功能 这些较低层的子功能成为一张新数据流图上的处理 在这张新数据流图上还应该包括自己的数据存储和数据流 118 3 细化数据流图 分层细化的两条原则 第一 在分层细化时必须保持信息连续性 也就是说细化前后对应功能的输入 输出数据必须相同 第二 当进一步细化将涉及如何具体地实现一个功能时 就不应该再分解了 119 3 细化数据流图 下图粗略地概括了上述分析过程 120 3 1 分层数据流图的画法 画系统的输入和输出把整个软件系统看作一个大的加工 然后根据系统从外界的哪些源点接受哪些数据流 以及系统的哪些数据流送到外界的哪些终点 就可画出系统的输入和输出图 这张图称为顶层图 121 3 1 分层数据流图的画法 画系统的内部将顶层图中的加工分解成若干个加工 并用数据流将这些加工连接起来 使得顶层图中的输入数据流经一连串的加工处理后变换成顶层图的输出数据流 这张图称为0层图 从一个加工画出一张