沈阳农业大学信息与电气工程学院软件工程课件 第三章.ppt

* * * * * * * * * * * * * * * * * * * * * * 复旦大学计算机科学与工程系 软件工程课程 */42 需求协商 协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案 协商不是简单的逻辑或技术上的争论 要注意组织和行政方面的因素 ①不一致的目标 ②责任的丧失或转移 ③组织文化 ④组织管理态度和士气 ⑤部门差异 复旦大学计算机科学与工程系 软件工程课程 */42 通常会议是解决冲突最快的方式 参加者应该包括发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员 会议应该讨论那些非正式讨论不能解决的问题 通常会议分为三个阶段： 叙述阶段 讨论阶段 决策阶段 复旦大学计算机科学与工程系 软件工程课程 */42 需求建模 在软件需求分析阶段，所创建的模型，要着重于描述系统要做什么，而不是如何去做 目标软件的模型不应涉及软件实现细节 复旦大学计算机科学与工程系 软件工程课程 */42 常用的分析方法： 面向数据流的结构化分析方法 (SA) 面向数据结构的分析方法 面向对象的分析方法 (OOA) 复旦大学计算机科学与工程系 软件工程课程 */42 内容摘要 需求工程概述 需求获取 需求分析、协商与建模 需求规约与验证 需求管理 复旦大学计算机科学与工程系 软件工程课程 */42 需求规约的原则 1． 从现实中分离功能，即描述要“做什么”而不是“怎样实现”。 2． 要求使用面向处理的规约语言（或称系统定义语言），讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规约。 3． 如果被开发软件只是一个基于计算机的系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。 4． 规约必须包括系统运行环境。 复旦大学计算机科学与工程系 软件工程课程 */42 需求规约的原则 (续) 5． 规约必须是一个认识模型，而不是设计或实现的模型。 6． 规约必须是可操作的，以便能够利用它决定对于任意给定的测试用例，已提出的解决方案是否都能满足规约。 7． 规约必须允许不完备性并允许扩充。 8． 规约必须局部化和松散耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规约应被松散地构造（即松耦合），以便能够很容易地加入和删去一些段落。 复旦大学计算机科学与工程系 软件工程课程 */42 需求规约 Ⅰ. 引言 A.系统参考文献 B.整体描述 C.软件项目约束 Ⅱ. 信息描述 A.信息内容表示 B.信息流表示： ⅰ数据流 ⅱ控制流 Ⅲ. 功能描述 A.功能划分 B.功能描述： ⅰ处理说明 ⅱ限制∕局限 ⅲ 性能需求 ⅳ 设计约束 ⅴ 支撑图 C.控制描述 ⅰ控制规约 ⅱ 设计约束 Ⅳ. 行为描述 A.系统状态 B.事件和响应 Ⅴ. 检验标准 A.性能范围 B.测试种类 C.期望的软件响应 D.特殊的考虑 Ⅵ. 参考书目 Ⅶ. 附录 复旦大学计算机科学与工程系 软件工程课程 */42 引言：陈述软件目标，在基于计算机的系统语境内进行描述。 信息描述：给出软件必须解决问题的详细描述，记录信息内容和关系、流和结构。 功能描述：描述解决问题所需的每个功能。其中包括，为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。 行为描述：描述作为外部事件和内部产生的控制特征的软件操作。 检验标准：描述检验系统成功的标志。即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。它是“确认测试”的基础。 参考书目：包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。 附录：包含了规约的补充信息，表格数据、算法的详细描述、图表以及其他材料。 复旦大学计算机科学与工程系 软件工程课程 */42 需求验证 需求验证目的是要检验需求是否能够反映用户的意愿 评审人员评审时往往需要检查以下内容： 系统定义的目标是否与用户的要求一致； 系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求； 被开发项目的数据流与数据结构是否确定且充足； 主要功能是否已包括在规定的软件范围之内，是否都已充分说明； 设计的约束条件或限制条件是否符合实际； 开发的技术风险是什么； 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认。 复旦大学计算机科学与工程系 软件工程课程 */42 内容摘要 需求工程概述 需求获取 需求分析、协商与建模 需求规约与验证 需求管理 复旦大学计算机科学与