第三章需求工程-Read.docVIP

PAGE 3 第3章 需求工程 需求工程无疑是当前软件工程中的关键问题。在1987年发表的那篇经典文章“没有银弹：软件工程本与末”中，Frederick Brooks指出了需求在软件项目中的重要地位：软件系统开发过程中最难的部分是对要开发什么做出准确的判断。所有概念性工作中最难的是建立详细的技术需求，包括所有与用户、机器和其他软件系统的接口。这部分工作的错误对最终系统的破坏最大，也最难纠正。 美国于1995年开始的一项调查结果也显示出了这一点。在这项调查中，他们对全国范围内的8000个软件项目进行跟踪调查，结果表明，有1/3的项目没能完成，而在完成的2/3的项目中，又有1/2的项目没有成功实施。他们仔细分析失败的原因后发现，与需求过程相关的原因占了45%，而其中缺乏最终用户的参与以及不完整的需求又是两大首要原因，各占13%和12%。 本章主要介绍需求工程概念、主要任务以及需求工程基本过程中的若干环节，包括需求获取、需求分析与建模、需求规约、需求验证及需求管理。 3.1需求工程概述 软件需求既是软件开发的依据，又是软件工程各项活动的基础。所以，在软件开发的初期，快速并准确地确定软件的需求是软件开发人员、软件管理人员以及用户都十分关心的问题。只有明确了软件的需求，软件开发人员才能明确自己需要做哪些开发工作，考虑如何去实现这些需求；软件管理人员才能较为准确地估计开发工作量、进度以及计划成本和价格；用户才能预计能够获得什么样功能和性能的软件产品。 3.1.1 需求工程定义 软件行业存在这样一个问题，用于描述需求工作的术语没有统一的定义。对同一项需求，不同的人会有不同的描述，称其为用户需求、软件需求、功能需求、系统需求、技术需求、业务需求或产品需求。客户对需求的定义，在开发人员看来可能只是高级别的产品概念；而开发人员的需求概念对用户来说也许就是详细的用户界面设计。定义的多样性导致了令人迷惑和沮丧的沟通问题。 咨询专家Brian Lawrence提出，需求是“任何促成设计决策的因素”。很多信息都属于这一范围。IEEE软件工程标准词汇表(1997年)则将需求定义为： 用户解决问题或达到目标所需的条件或权能(Capability)。 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 一种反映上面(1)或(2)所描述的条件或权能的文档说明。 这一定义既体现了用户对需求的看法（系统的外部行为），也代表了开发人员的观点（一些深层的特性）。通俗一些的说，软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通过对应问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化，最终形成需求规格说明，这一系列的活动即构成软件开发生命周期的需求分析阶段。 需求分析是介于系统分析和软件设计阶段之间的桥梁。一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。通俗的说，需求分析要解决的是，表明要开发的软件要“做什么”，“做成怎样”的问题，而不是“怎么做”的问题。 需求工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。80年代中期，形成了软件工程的子领域——需求工程。需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。进入90年代后，需求工程成为软件界研究的重点之一。 需求工程的目的是通过与用户广泛地交流确定应用系统的目标。需求活动以“工程化”的方法被提出、分析和组织，它鼓励用户以一种积极的方式参与需求分析活动中，并在整个软件生命周期强调用户参与和领域专家的指导作用，促使目标系统最大地满足用户需求。 当人们提到需求工程时，总是自然的将它与需求分析员联系起来，但是需求工程所涉及的人，决不仅仅于此。它而包含了客户、用户、需求分析员、开发人员、测试人员、文档编写人员、项目经理、法律人员、生产人员、市场营销、技术支持及其他与产品和客户打交道的人员。他们的角色分别为： 客户：为达到其公司的业务目标