吉林大学软件工程Chap3剖析.ppt

软件工程 - 2015 - 第三章 软件需求 “建造一个软件系统的最困难的部分是决定要建造什么……没有别的工作在做错时会如此影响最终系统，没有别的工作比以后矫正更困难。” Fred Brooks 必须理解并描述问题的信息域，根据这条准则应该建立数据模型；必须定义软件应完成的功能，这条准则要求建立功能模型；必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型；必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节 误解 交流障碍 “完整性”问题 需求永远不会稳定 用户意见不统一 错误的要求 认识混淆 “我知道你相信你已经理解了你认为我所说的内容，但是我并不能肯定你已经认识到你所听到的并不是我所想要的。” 不完整的需求（13.1%） 缺少用户的参与（12.4%） 缺乏资源（10.6%） 不切实际的期望（9.9%） 缺乏行政支持（9.3%） 改动需求和说明（8.7%） 缺少计划（8.1%） 不再需要该系统（7.5%） 事实1 在软件生命周期中，一个错误发现得越晚，修复错误的费用越高 事实2 许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来 事实3 在需求过程中会产生很多错误 事实4 在需求阶段，代表性的错误为疏忽、不一致和二义性 事实5 需求错误是可以被检查出来的 由上面这些事实，能得出如下四点结论： 在需求过程中会产生很多错误（事实3和4） 许多错误并没有在早期被发现（事实2） 这样的错误是能够在产生的初期被检查出来的（事实5） 如果没有及时检查出来这些错误，软件费用会直线上升（事实1） 需求过程不仅是可能的而且也是值得的 确定对系统的综合要求 功能需求 性能需求 可靠性和可用性需求 出错处理需求 接口需求--用户接口需求；硬件接口需求；软件接口需求；通信接口需求 约束--精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台 逆向需求 将来可能提出的要求 分析系统的数据要求 建立数据模型 E-R图 复杂数据结构的描述 ： 数据字典 层次方框图 Warnier图 数据库 数据规范化 导出系统的逻辑模型 软件系统详细的逻辑模型通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述 修正系统的开发计划 可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。 访谈 面向数据流自顶向下求精 简易的应用规格说明技术 快速建立软件原型 正式访谈 非正式访谈 分发调查表 情景分析技术 情景分析——对用户将来使用目标系统解决某个具体问题的方法和结果进行分析 用处：它能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求；由于情景分析较易为用户所理解，使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色。 一种面向团队的需求收集法。这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。 初步访谈，通过用户对基本问题的回答，初步确定待解决的问题的范围和解决方案 开发者和用户分别写出“产品需求”，组织会议 会议前准备，每位与会者会议前几天列出对象、服务、约束条件（例如，成本、规模、完成日期）和性能标准（例如，速度、容量） 是否需要这个新产品？每位与会者把他们在会前准备好的列表展示出来讨论 针对某个议题创建一张组合列表 由协调人主持讨论这些列表，目标是，针对每个议题(对象、服务、约束和性能)都创建出一张意见一致的列表 一旦得出了意见一致的列表，就把与会者分成更小的小组，每个小组的工作目标是为每张列表中的项目制定小型规格说明，并讨论 每个与会者都制定出产品的一整套确认标准，并把自己制定的标准提交会议讨论，以创建出意见一致的确认标准 由一名或多名与会者根据会议成果起草完整的软件需求规格说明书 快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。 快速原型应具备的特性 快速 容易修改 构建和修改原型的方法和工具 第四代技术 可重用的软件构件 形式化规格说明和原型环境 R. Ross于1981年提出，在大型数据库管理程序基础上发展起来的程序设计语言 独立于具体的处理机 面向结果的非过程式语言 有丰富的软件工具的支持 能统一利用和管理各种资源，适应不同水平用户的需要 以4GL为核心的软件开发技术称为四代技术（4GT） 支持4GT的软件开发工具有：数据库查询语言、报表生成器、图表生成器、人机交互的屏幕设计与代码生成系统等 分析建模 模型就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通