软件工程-第03章.doc

第040页 第3章 需求分析 需求问题是造成软件工程项目失败的主要原因，能否开发出高质量的软件，很大程度上取决于对要解决的问题的认识以及如何准确地表达出用户的需求。通过需求分析使得分析者深刻地理解和认识系统，并将其完全、准确地表达，其结果不仅起到沟通（用户和开发者）作用，还是后续工作的依据。本章介绍需求分析的一些基本概念，分别对需求获取技术、需求规格说明书、如何进行需求分析以及需求分析方法进行讨论，重点讨论结构化的需求分析方法。 3.1.1 需求的概念和任务 什么是需求？到目前为止还没有公认的定义。对用户来讲需求是对软件产品的解释，是用户对目标软件系统在功能、行为、性能、设计和约束等方面的期望；而开发人员所讲的需求对用户来说又像是详细设计。比较权威的定义是IEEE软件工程标准词汇表中的需求定义： (1)用户解决问题或达到目标所需的条件或权能(Capability)。 (2)系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。 (3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。 由定义可知，需求一方面反映了系统的外部行为，另一方面反映了系统的内部特性，反映的方式是需求文档。用规范的格式表达出来的文档说明称为需求规格说明书，或者简称为“需求说明”。 3.1.2 需求的层次 需求可分解为4个层次：业务需求、用户需求、功能需求和非功能需求。 (1)业务需求(Business Requirement)：业务需求是反映组织机构或客户对软件高层次的目标要求。这项需求是用户高层领导机构决定的，它确定了系统的目标、规模和范围。业务需求是需求分析阶段制定需求调研计划、确定用户核心需求和软件功能需求的依据，应在进行需求分析之前确定，通常在项目定义与范围文档中予以说明。 (2)用户需求（User Requirement）：用户需求是用户使用该软件要完成的任务。要弄清这部分需求，应该充分调研具体的业务部门，详细了解最终用户的工作过程、所涉及的信息、当前系统的工作情况、与其他系统的接口等。用户需求是最重要的需求，也是最容易出现问题的部分。 (3)功能需求(Functional Requirement)：功能需求定义了软件必须实现的功能。由于用户是从完成任务的角度对软件提出需求的，通常是凌乱的、非系统化的、冗余的，开发人员无法据此编写程序。分析人员必须在充分理解用户需求的基础上，将用户需求整理成满足特定业务需求的软件功能需求。 (4)非功能需求：非功能需求是对功能需求的补充。可以分为两类：一类是用户关心的一些重要属性，如有效性、效率、灵活性、完整性、互操作性、可靠性、健壮性、可用性；另一类是对开发者来说很重要的质量属性，如可维护性、可移植性、可复用性、可测试性。 第041页 软件需求各组成部分之间的关系如图3-1所示。 图3-1 软件需求各组成部分之间的关系 3.1.3 需求分析的任务 软件需求分析是在软件计划的基础上进行的。需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，确定目标系统“做什么”的问题。需求分析的结果应该反映的是系统必须做什么，而不是怎么做。具体地讲，该阶段的工作是在对问题进行调查了解的基础上，确定系统的目标和范围，将用户的需求变为软件的功能和性能描述。为了将软件的功能和性能描述清楚，系统分析人员需要用一定的方法和手段对问题进行分析，建立反映问题所涉及的信息、功能及系统行为的模型，用文字、图形符号来详细说明软件必须要做什么以及配合运行的环境应该是什么，形成需求规格说明。 需求分析是介于系统分析和软件设计阶段之间的桥梁。一方面，需求分析以系统规格说明和项目计划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又为用户和开发人员提供一起协商讨论的基础，作为软件设计、实现、测试和维护的依据。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。 随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需求分析活动不仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期，并将需求工作分为需求开发和需求管理两部分，将这两部分统称为“需求工程”（Requirement Engineering，RE）0 20世纪80年代中期，需求工程成为软件工程的子领域，进入90年代以来，需求工程成为研究的热点之一。需求工程结构图如图3-2所示。 第042页 图3-2 需求工程结构图 由此，需求分析阶段的任务就是实现需求工程，具体内