第5章 结构化分析.ppt

第5章 需 求 分 析 软件工程教研室 主 要 内 容 需求及需求原因 需求分析的任务和目标 需求分析的途径 需求分析的活动 目的: 明确“做什么” 准确、完整和规范化的软件 需求是软件开发成功的关键 一般问题的解决过程 5.1 需求及需求原因 问题领域 什么是问题(question)? Gause和Weinberg(1989)观点: “我们所感觉到的和所得到的事物之间的区别“ 问题领域:问题范围 问题分析:理解真实世界中的问题和用户的 需要,并提出满足这些需要的解决 方案的过程. 1) 什么是需求？ 从系统的外部发现系统所具有满足用户 的特点、功能、属性等(Alan Davis 93)。 用户所需要的并能触发一个程序或系统 开发工作的说明 (Jones 94)。 用户解决问题达到目标所需要的条件或权能，系统或系统部件要满足合同、标准、 规范或其他正式规定文档所具有的途径或 权能 (IEEE97)。 例如： (1)系统必须有能力支持100个以上的并发用户，每 个用户可以处理附录A中操作任务的任选组合， 平均响应时间应该小于1秒，最大响应时间应 小于5秒。 (2) 必须在对话窗口的中间显示错误警告，其中使 用红色的、 14点加粗Arial字体。 (3)系统必须有能力存储平均操作连续100天所产生 的事务。 (4) 通讯接口必须符合ISO七层架构。 1979年美国财政部对美国联邦政府开发的 9个工程规模不大的软件项目进行了调查，结果为： 投资后未能交付的软件占20-21%， 交付后不能使用的软件占47%， 需要经过修改才能使用的占29%， 交付后可以使用的只占3-4%。 原因:需求没有做好 3) 需求中常用的术语 5.2 需求的任务和目标 1) 任务 定义系统需要“做什么” 软件的功能需求 软件的质量需求 用户界面需求 环境需求 资源使用需求 制定需求规格说明 需求的时序或优先程度。 功能之间的互斥规则。 系统内部状态的假定。 为了该功能的执行，所需要的输入和输出次序。 用于转换或内部计算所需要的公式。 正确性(correctness): 一个程序满足需求规约和实现客户 任务目标程度(每KLOC行代码缺陷数). 高效性(efficiency)即效率 一个程序完成其功能所需的资源 和代码数量. 注意:在预计的高峰负载条件下,必 须留出10%处理器能力和15%系 统可用内存,以备用 在定义性能、能力、效率目标 时,考虑硬件的最小配置. 灵活性(flexibility) 在产品增加新功能时或修改一个程序 时,所需工作量的大小. 互操作性 ( interoperability ): 产品与其系统交换数据和服务的难 易程度。 健壮性 ( robustness) 软件可以从发生问题的环境中完好 地恢复并且可容忍用户的错误. 可移植性( portability)： 把软件从一种运行环境转移到另一 种运行环境所花费的工作量。 注意： 通常，不能把一个接口需求做成需求规格中一 个完全自包含的需求。 如上两个实例，通常需要引用其它描述外部系统的 文档。其中，应避免出现信息重复问题。然而，如 果对当前需求规格所需要的信息并没有给出，那么 就应建立这些信息. 硬件接口(Hardware interfaces)： 如果软件系统必须与硬件设备进行交互，那么就应该说明所要求的支持和协议类型。如果必要的话，应该开发或引用一个文档。 通讯接口(Communications interfaces)： 规约待开发系统与通讯设施(如，局域网)之 间的交互。如果通讯需求包含了系统必须使用 的网络类型（TCP/IP，WindowsNT,Novell）， 那么有关类型的信息就应包含在需求规格说明 书中。 系统必须用C++或其他面向对象语言编写。 系统用户接口需要菜单。 任取10秒，一个特定应用所消耗的可用计算能 力平均不超过50%。 针对产品开发，为确定其相关的设计约束， 一般需要考虑以下几