需求分析.pptVIP

第三章 需求分析 本章主要内容 3.1 需求分析的概念与任务 3.2 获取需求的方法 3.3 结构化分析方法 3.4 原型法 3.1 需求分析的概念与任务 需求分析虽处于软件开发过程的开始阶段，但它对于整个软件开发过程以及软件产品质量至关重要。 在需求分析阶段，要对经过可行性分析所确定的系统目标和功能作进一步的详细论述，确定系统“做什么”的问题。 3.1 需求分析的概念与任务 3.1.1 需求的概念 对用户来讲，需求是对软件产品的解释，是对目标软件在功能、行为、性能、设计和约束等方面的期望。 对开发人员而言，他们的需求对用户而言像是详细设计。 IEEE软件工程标准词汇表的需求定义： 用户解决问题或达到目标所需的条件或权能(Capability)； 系统或系统部件要满足合同、标准、规范或其他正是规定文档所需要具有的条件或权能； 反映上面描述的条件或权能的文档说明。 需求及反映了系统的外部行为，也反映了内部特征，反映的方式是需求文档。用规范的格式表达出来的文档说明称为需求规格说明书，或者简称为“需求说明”。 3.1 需求分析的概念与任务 3.1.2 需求的层次 软件需求包括四个不同的层次——业务需求、用户需求和功能需求、非功能需求。 业务需求（Business Requirement） 反映了组织机构或客户对系统、产品高层次的目标要求，确定了系统的目标、规模和范围，是用户需求和功能需求的依据，通常在项目定义与范围文档中予以说明。 用户需求（User Requirement） 用户使用该软件要完成的任务。要弄清这部分需求，应充分调研具体业务部门，详细了解最终用户的工作过程、涉及信息、当前系统的工作状况、与其他系统的接口等。 用户需求是最重要、也是最容易出问题的需求。 3.1 需求分析的概念与任务 功能需求（Functional Requirement） 定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 用户出于完成任务的角度对软件的需求，通常是凌乱、非系统化、冗余的，分析人员必须在充分理解用户需求的基础上，将其整理成满足特定功能需求的软件功能需求。 软件分析人员应该是计算机方面的专家，架起用户与开发人员之间的桥梁。 非功能需求 非功能需求是对功能需求的补充，可分为两类。 用户关心的重要属性：有效性、效率、灵活性、完整性、互操作性、可靠性、健壮性、可用性等等。 开发者关心的属性：可维护性、可移植性、可复用性、可测试性等等。 非功能需求 3.1 需求分析的概念与任务 软件需求各组成部分关系图 3.1 需求分析的概念与任务 3.1.3 需求分析的任务 基本任务：准确地定义新系统的目标，为了满足用户需求，回答系统必须“做什么”的问题，获得需求规格说明书。 为了更加准确地描述需求分析的任务，Boehm给出软件需求的定义： 研究一种无二义性的表达工具，它能为用户和软件人员双方都接受，并能够把“需求”严格地、形式地表达出来。 随着软件系统规模的扩大，需求分析预定义在整个软件开发与维护过程中 越来越重要，直接关系到软件的成功与否。人们逐渐认识到，需求分析阶段不只限于软件开发的最初阶段，而是贯穿于系统开发的整个生命周期，并将需求工作分为需求开发和需求管理两部分，并统称为“需求工程”（Requirement Engineering，RE）。 需求分析阶段的任务就是实现需求工程。 需求工程 需求工程结构图 需求工程——需求开发 需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。 1 需求获取 进行用户需求调查，获取需求、识别问题。 分析员与用户充分交流，准确、完整的获取用户需求，确定软件系统的总和要求。系统软件的综合要求通常包括以下几部分： 功能要求：最主要的需求，确定系统必须完成的所有功能及其必要性和相容性。 性能要求：确定目标系统必须达到的性能指标。如联机系统的响应时间、可靠性、存储容量、计算精度与效率等。 需求工程——需求开发 运行和扩充要求： 运行要求通常包括系统运行的物理环境、支持的软件系统、数据通信方式、系统界面、与其他系统的数据交换格式、用户终端类型、用户操作的易接受程度等。 可扩充要求主要由是否要求可移植、未来扩充或升级的要求、扩充的范围、方式、接口等等。 维护要求 系统出错后可允许的最大恢复时间、对错误修改的回溯测试要求、系统运行日志规格、是否允许对系统修改、系统变化如何反映到设计中等等。 文档规格要求 系统编制的文档类型、规范以及预期的使用对象等等 。 需求工程——需求开发 2 分析建模（导出系统逻辑模型） 软件系统本质上是信息处理系统，应通过分析系统信息流的构成和相互之间的关系，确定： 数据（需要哪些数据、数据间联系、数据来源、性质、结构、存储方式） 数据处理（处理的类型、处理的逻