软件工程-第3章需求精编.ppt

软件工程与软件开发工具 第3章 需求分析 3.1需求分析概述 3.2数据流图 3.3数据字典 3.4加工逻辑描述工具 3.5结构化分析方法 3.6复审 3.7需求分析人员 3.1软件需求分析概述 3.1.1软件需求分析的任务 通过对要解决的问题、用户的要求及其目标环境的研究、分析和综合，建立抽象级的分析模型 准确地、完整地体现用户的功能和性能及其它要求，规范地通过“软件需求规格说明书” 表达出来。 3.1.2 需求类型 1. 按内容分类 软件需求代表系统的综合要求，包括以下几种类型： (1) 系统功能需求 系统功能需求指根据系统所能实现的功能要求，对于每一类功能或者有时对于每一个功能，需要弄清输入、加工和输出等需求。 (2) 系统性能需求 按照系统的性能要求分类。例如联机系统的响应时间、系统需要的存储容量、后援存储器、重新启动、安全性和可靠性等方面的要求。 3.1.2 需求类型(2) (3) 系统运行需求 这类要求集中表现为对系统运行时所处的环境、使用的资源、安全保密和用户界面的要求。如支持系统运行的硬件和软件是什么，采取哪种数据库管理系统，需要什么样的外存储器和数据通信接口。 (4) 未来可能出现的问题 就是把不属于当前系统开发范围的问题都明确地列出来，因为将来很可能会提出这些问题。这些问题主要是为了系统将来的扩充和修改做准备，当以后需要时就可以很容易地进行扩展和修改了。 3.1.2 需求类型(3) 2. 按用户的期望分类 (1) 正常需求 用户陈述的针对系统的目标。 (2) 期望需求 隐式的需求，可能由于是非常基础的而用户没有显示的陈述，如人机交互的容易性、整体的操作正确性和可靠性，以及软件安装的容易性。 (3) 兴奋需求 在用户的期望范围之外，如果实现将令人愉快和出乎意料。 3.1.2 需求类型(4) 3. 按必要性分类 (1) 强制的需求 是指除非软件与这些需求一致，则该软件是不可接受的 (2) 希望的需求 是指这些需求将增进软件产品功能，但是如果缺乏的话也不是不可接受 (3) 任选的需求 是指这个功能可有可无 3.1.3 需求特性 (1) 正确性 需求规格说明书中的功能、行为、性能描述必须与用户对目标软件产品的期望相吻合。 (2) 无歧义性 对于用户、分析人员、设计人员和测试人员而言，需求规格说明书中的任何语法单位只能有唯一的语义解释。确保无歧义性的一种有效措施是在需求规格说明书中使用标准化术语，并对术语的语义进行显式的、统一的解释。 (3) 完整性 需求规格说明书不能遗漏任何用户需求，具体地说，目标软件产品的所有功能、行为、行为约束以及它在所有可能情况下的预期行为，均应完整地包含在需求规格说明书中。 (4) 可验证性 对于规格说明书中的每一个需求，均应存在技术和经济上可行的手段进行验证和确认。 3.1.3 需求特性(2) (5) 一致性 需求规格说明书的各部分之间不能相互矛盾。这些矛盾可以表现为术语使用方面的冲突，功能和行为方面的冲突，以及时序方面的前后不一致。 (6) 可理解性 追求上述目标不应妨碍需求规格说明书对于用户、设计人员和测试人员的易理解性。特别是对于非计算机专业的用户而言，不宜在说明书中使用太多的专业化词汇。 (7) 可修改性 需求规格说明书的格式和组织方式应保证能够比较容易地接纳后续的增删和修改，并使修改后的说明书能够较好地保持其他各项属性。 (8) 可追踪性 需求规格说明书必须将分析后获得的每项需求与用户的原始需求项清晰地联系起来，并为后续开发和其他文档引用这些需求项提供便利。 关于需求分析 如何看待需求 理解需求和功能的区别 需求是需要分析的 需求一般不专一，是会变的 （要注意应变） （1）积极的沟通。及时了解变化，并进行变更控制管理。 ? （2）在系统的架构设计上，为变化做准备。面向对象也好、面向服务也好、三层也好、四层也好，我们为什么把代码分开层次，为什么提供那么多抽象的接口？都是为了应对变化，为了我们在这个需求像云彩一样变化的环境中能够适应。 保持沟通渠道的畅通 需求分析的一般性技术 为了克服困难，更有效地开展需求分析工作，软件系统分析人员必须掌握一些基本的需求分析技术，主要包括： 初步需求获取技术； 需求建模技术； 快速原型技术； 问题的分解与抽象； 多视点分析技术等。 初步需求获取技术 原因：在分析阶段的初期，由于分析人员和用户的共同知识领域可能不多，致使分析人员对问题往往知之不多，而用户对目标软件的要求及对要求的描述常常是零乱而模糊的，从而会造成相互交流和相