软件工程之 需求获取.pptVIP

第5章 需求获取 第五章 需求获取 5.1软件需求的定义 5.2软件需求的类型 5.3需求获取 5.4需求规格说明书 5.5需求验证 5.6需求变更 教学目的与要求： ⒈掌握需求的基本概念及类型; ⒉掌握如何进行获取需求; ⒊掌握需求规格说明书； 4.掌握需求验证； ⒋理解软件需求变更管理。 引言 团队和管理对项目开发很重要，但项目开发的成败取决于是否正确的进行需求获取。 注：从前有一个人，从魏国到楚国去。他带上很多的盘缠，雇了上好的车，驾上骏马，请了驾车技术精湛的车夫，就上路了。楚国在魏国的南面，可这个人不问青红皂白让驾车人赶着马车一直向北走去。路上有人问他的车是要往哪儿去，他大声回答说：“去楚国！”路人告诉他说：“到楚国去应往南方走，你这是在往北走，方向不对。”那人满不在乎地说：“没关系，我的马快着呢！”路人替他着急，拉住他的马，阻止他说：“方向错了，你的马再快，也到不了楚国呀！”那人依然毫不醒悟地说：“不打紧，我带的路费多着呢！”路人极力劝阻他说：“虽说你路费多，可是你走的不是那个方向，你路费多也只能白花呀！”那个一心只想着要到楚国去的人有些不耐烦地说：“这有什么难的，我的车夫赶车的本领高着呢！”路人无奈，只好松开了拉住车把子的手，眼睁睁看着那个盲目上路的魏人走了。寓言告诉我们，无论做什么事，都要首先看准方向，才能充分发挥自己的有利条件；如果方向错了，条件再有利也达不到目的。同样在项目开发中有再好的团队，再好的技术，如果没有正确的进行需求获取，那么项目不可能成功！ 5.1需求的定义 不同背景的人对需求会有不同的看法，像瞎子摸象一样大家会站在自己的立场去理解需求，因此需求在软件工程中没有统一的定义，IEEE对需求的定义为： 　 1、用户为解决某个问题或达到某个目标而需具备的条件或能力。 2、系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。 IEEE的定义中同时包括了用户的观点（第一条）和开发者的观点（第二条）。 关于需求还有其他不同的定义，产生这些不同的原因有两点：一是需求工程的发展过程还不太长，人们的认识还不够；二是真正的需求实际上是人们的想法，很难给予准确的定义。 5.2需求的类型 1、功能需求（Functional Requirement）：和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。 2、性能需求（Performance Requirement）：系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。 3、质量属性（Quality Attribute）：系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求。 4、对外接口（External Interface）：系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等。 5、约束（Constraint）：进行系统构造时需要遵守的约束，例如编程语言、硬件设施等。 5.2需求的类型 5.2需求的类型 1.2.1功能需求 业务需求（Business Requirement）表示组织或客户高层次的目标。它描述了组织为什么要开发系统，即组织希望达到的目标。例如实现车辆的有效管理和利用。业务需求通常来自项目的投资人、购买产品的客户、实际用户的管理者。 用户需求（User Requirement）就是执行实际工作的用户对系统所能完成的具体任务的期望。业务需求是由组织的专门部门提出，但普通用户才是组织中任务的实际执行者，只有通过具体并且合理的业务流程才能真正的实现目标。也就是说用户需求描述了用户能使用系统来做些什么。 系统需求（System Requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求，行为需求描述的是开发人员需要实现什么。 5.2需求的类型 1.2.2非功能性需求 除了功能需求外，软件需求还包含非功能需求，包括性能需求、质量属性、对外接口和约束。非功能需求是衡量软件能否良好运行的定性指标。因此，非功能需求也是非常重要的。在非功能需求中，质量属性对系统的影响极大，因此在某些情况下，非功能需求又被用来特指质量属性。 1、可靠性：指在给定的时间内以及规定的环境条件下，软件系统能完成所要求功能的概率。其定量指标通常用平均无故障时间和平均修复时间来衡量。 2、可用性：指用户学习和使用软件系统功能的简易程度，也包括对系统的输出结果易于理解的程度。 3、可维护性：指在软件系统中发现并纠正一个故障或进行一次更改的简易