[软件工程]CH03-需求分析课件.ppt

软件工程 刘迎春 第三章 需求分析 主要内容 3.1 需求分析概述 3.2 数据流图 3.3 数据字典 3.4 加工逻辑描述工具 3.5 结构化分析方法 3.6 需求规格说明书 3.1 需求分析概述 1.任务 2.类型 3.特性 4.获取、描述与分析技术 5.步骤 3.1.1 需求分析的任务 【可行性研究】 粗略了解用户的需求。 用较少的成本，在较短的时间内确定是否存在一些可行的解法。 许多细节被忽略了。 【需求分析】 准确地回答“系统必须做什么？”这个问题。 3.1.1 需求分析的任务 【依据】 《可行性研究报告》 【任务】 ⑴建立目标系统的逻辑模型 调查分析用户的确切需求，认真搞清、并细化到底“系统必须做什么”？ 反复与用户交流； 建立原型系统； 确定目标系统的功能、性能、运行 ⑵形成《软件需求规格说明书》 Software Requirement Specification 3.1.2需求类型 1.按内容分类 软件需求代表系统的综合要求，包括以下几种类型： ① 系统功能需求 系统功能需求指根据系统所能实现的功能要求，对于每一类功能或者有时对于每一个功能，需要弄清输入、加工和输出等需求。 ② 系统性能需求 按照系统的性能要求分类。例如联机系统的响应时间、系统需要的存储容量、后援存储器、重新启动、安全性和可靠性等方面的要求。 3.1.2需求类型(2) ③ 系统运行需求 这类要求集中表现为对系统运行时所处的环境、使用的资源、安全保密和用户界面的要求。如支持系统运行的硬件和软件是什么，采取哪种数据库管理系统，需要什么样的外存储器和数据通信接口。 ④ 未来可能出现的问题 就是把不属于当前系统开发范围的问题都明确地列出来，因为将来很可能会提出这些问题。这些问题主要是为了系统将来的扩充和修改做准备，当以后需要时就可以很容易地进行扩展和修改了。 3.1.2需求类型(3) 2.按用户的期望分类 ① 正常需求 用户陈述的针对系统的目标。 ② 期望需求 隐式的需求，可能由于是非常基础的而用户没有显示的陈述，如人机交互的容易性、整体的操作正确性和可靠性，以及软件安装的容易性。 ③ 兴奋需求 在用户的期望范围之外，如果实现将令人愉快和出乎意料。 3.1.2需求类型(4) 3.按必要性分类 ① 强制的需求 是指除非软件与这些需求一致，则该软件是不可接受的 ② 希望的需求 是指这些需求将增进软件产品功能，但是如果缺乏的话也不是不可接受 ③ 任选的需求 是指这个功能可有可无 需求分析工具 Requisite Pro Clear Quest Trac 3.1.3 需求特性 (1) 正确性 需求规格说明书中的功能、行为、性能描述必须与用户对目标软件产品的期望相吻合。 (2) 完整性 需求规格说明书不能遗漏任何用户需求 (3) 可验证性 需求规格说明书中的每一个需求，均应存在技术和经济上可行的手段进行验证和确认。 3.1.3 需求特性(2) (4) 无歧义性 需求规格说明书中使用标准化术语， 用户、分析人员、设计人员和测试人员对需求规格说明书中的任何语法单位只能有唯一的语义解释。 (5)一致性 需求规格说明书的各部分之间不能相互矛盾。这些矛盾可以表现为术语使用方面的冲突，功能和行为方面的冲突，以及时序方面的前后不一致。 (6) 可理解性 不宜在说明书中使用太多的专业化词汇。 3.1.3 需求特性(2) (7) 可追踪性 需求规格说明书必须将分析后获得的每项需求与用户的原始需求项清晰地联系起来，并为后续开发和其他文档引用这些需求项提供便利。 (8) 可修改性 需求规格说明书的格式和组织方式应保证能够比较容易地接纳后续的增删和修改; 使修改后的说明书能够较好地保持其他各项属性。 3.1.4 需求获取、描述和分析技术 调查研究 问题分解 抽象 建模 多视点分析 1. 需求获取技术 用户和开发人员共同组成联合小组 加强联系 促进交流 增进合作 访谈和会议 观察用户工作流程或者实践 2.问题分解 什么是问题分解? 将大问题分解为小问题，通过小问题解决来实现大问题的解决 问题分解有助于降低解决问题的复杂度; 获取和分析问题本身所固有的整体-部分关系; 图书馆系统 读者管理 图书管理 借阅管理 3.问题抽象(1/2) 什么是抽象? 抽象有助于控制问题复杂度，抓住问题的本质; 获取一般和特殊关系; 3.问题抽象(2/2) 读者抽象(提取成份) 名字 性别 单位 类别 照片 Email 电话 读者抽象(抛弃成份) 身高 年龄 …… 4. 需求建模 什么是需求模型 模型是对现实的简化，包含有主要影响的要素，忽略不相关的次要因素 需求模型详细、准确地描述了用户对目标软件系统的功能、行为、性能、 设计约束等方面的要求 为什么需要建模 从多个视点、多个不同的抽