软件需求管理(新)

第三章软件需求管理3.1需求工程与需求管理的概念3.1.1需求的噩梦3.1.2需求与需求管理的概念3.1.3现代软件工程的需求工程3.1.4传统软件工程的局限性对大多数软件和系统开发团队来说，与过去自由的日子相比，20世纪90年代是一个强调流程的时代。评测和验证有效的软件开发流程的标准得到推广和普及。许多论述软件开发流程的书籍和文献以及关于业务建模和重构的相关材料纷纷出版。不断涌现出的软件工具已经帮助人们制定和应用有效的软件开发流程。在这十年内，全球经济对软件的依赖程度加深，它推动着开发流程的发展，提高了系统质量。既然如此，那么今天频频发生的软件项目失败的事件又如何解释呢？即使不是大多数，但为什么仍有那么多的项目受到延期、预算超支和质量问题的困扰呢？随着我们的业务、国家经济和日常活动越来越依赖于系统，如何才能提高系统的质量？3.1需求工程与需求管理的概念为什么要管理需求？简单地说，系统开发团队之所以管理需求，是因为他们想让项目获得成功。满足项目需求即为成功打下了基础。若无法管理需求，达到目标的几率就会降低。也就是说：好的需求管理是项目成功的第一位因素。采用需求管理可以给项目组带来很多的好处，直至项目取得成功。Brooks[1987]：不能得到完整、正确以及无二义性的软件需求仍然是如今导致软件开发失败的一个重大原因3.1.1需求的噩梦一组数字据StandishGroup(1994)的研究表明，在美国：每年大约花2500亿美元，开发17.5万个应用程序项目大公司开发项目的平均成本是232.2万美元中等公司的平均成本是133.1万美元小公司则是43.4万美元另一方面：大约31%的项目在完成之前被取消52.7%的项目成本是项目原来预算的189%因此，StandishGroup估计，美国公司和政府机构在被取消软件项目上的花费，每年大约是810亿美元同样，他们为超过交付时间而需要多支付590亿美元软件开发的问题分类0102030405060123456主要问题次要问题不是问题1、需求规格说明4、软件和测试2、管理客户需求5、项目管理3、建档6、编码问题的重要性依次降低ESPITI(欧洲软件过程改进培训倡议）（1995）所作的一个调查，3800个被调查者认为，软件开发的主要问题、次要问题和不是问题的问题如图。一半以上的人认为，软件的二个最大问题是：1、需求规格说明2、管理客户需求相对而言，编码不是问题项目失败的根本原因StandishGroup的研究表明，对软件项目的评价因素，可以归纳为：成功（大公司只占9%、小公司有16%）有异议（推迟且没有达到预期的目标）失败（取消）而有异议的三个主要原因是：1、缺乏用户的参与（占所有项目的13%）2、不完整的需求和规格说明（占所有项目的12%）3、不断改变的需求和规格说明（占所有项目的12%）而其他因素，则比例较小，例如：不合理的时间进度和时间分段（4%）人和资源不足（6%）技术技能不够（7%）结论：1/3的项目直接与需求的获取、建档和管理有关需求变化合理范围内的变化：用户不了解自己的需求需求本身易变，市场、技术、竞争因素不合理的变化：需求文档质量不高需求分析技能、技术和管理上的缺陷需求变化的原因：未受控制的需求变更遗漏需求用户交流不够需求规约质量差低效的需求分析为什么要管理需求？迭代开发模式下，需求在项目各阶段所占有的比例需要更好地适应需求变化、更好的进行范围控制和管理需求错误的代价修复的相对成本开发阶段需求阶段0.1-0.2设计0.5维护20验收测试5单元测试2编码13.1.2需求与需求管理的概念什么是需求？需求的基本概念宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。需求是对系统要做什么、如何工作、表现出来的特征、必须具备的质量、必须满足的约束的叙述需求的重要性需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。什么是软件需求？一般把需求定义为“（正在构建的）系统必须符合的条件或具备的功能或能力”。电气和电子工程师学会使用的定义与此类似。著名的需求工程设计师MerlinDorfman和RichardH.Thayer提出了一个包容且更为精练的定义，它特指软件方面-但不仅仅限于软件：1、软件需求可定义为：用户需解决某一问题或达到某一目标所需的软件功能。2、系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。需求全部是来自用户吗？需求的分解问题领域需要用户需求软件系统需要系统需求应用系统需要系统特性什么是需求管理？由于需求是正在构建的系统必须符合的事务，而且符合某些需求决定了项目的成功或失败，因此找出需求是什么，将它们记下来，进行组织，并在发生变化时对它们进行追踪，这些活动过程，就是需求管理。换句话说，需求管理就是：一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。这个定义与Dorfman与Thayer以及IEEE的“软件需求工程”的定义相似。需求工程包括获取、分析、规定、验证和管理软件需求，而“软件需求管理”则是对所有相关活动的规划和控制。所以，需求管理包括软件需求过程的整个过程软件项目和软件过程的需求管理PMBOK的范围管理按照PMBOK的定义，范围是指产生项目产品所包括的所有工作及产生这些产品的过程。范围管理是指对项目包括什么和不包括什么的定义与控制过程。项目范围管理的核心是：为了顺利地完成项目而设置了一些过程，这些过程的目的是确保项目包括且仅仅包括所要求的工作（交付成果）。这一控制过程的含义同时还指：确保项目组和用户（或称为项目利益关系人）对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解。从软件项目的需求管理，理解项目管理的范围管理CMM2的需求管理软件过程能力成熟度模型（CMM）对需求管理作了明确的要求，为达到CMM2级，组织就必须具备满足软件开发与管理的六个关键过程域（keyProcessAreas，KPA）的能力。而需求管理就是这六个关键过程域中的第一个，是其他五个域实施的前提。CMM2指出，需求管理的目的是在客户和遵循客户需求的软件项目之间建立一种共同的理解。因此，需求管理活动的内容应包括就软件的需求同客户达成一种共识并加以管理。该共识就是“指定给软件的系统需求”。CMM2需求管理的目标是：（1）控制指定给软件的系统需求，为软件工程和管理应用建立基线；（2）保持软件计划、产品和活动与指定给软件的系统需求一致。CMM2的需求管理CMM对需求管理的定义是：对需求分配进行管理，既要在用户和实现用户需求的项目组之间达成共识；控制系统需求，为研发过程和项目管理建立基线；保持项目计划、产品和活动与系统需求的一致性。从定义出发，需求管理涉及三个方面的内容：需求定义的管理、需求实现的管理、需求变更的管理。一般认为，需求管理并不包括需求的收集和分析，而是假定组织已收集了软件需求或已经明确地给出了需求的定义。或者说，广义的需求管理还应包括用户需求的收集、处理、分析和验证等内容。我们从广义需求管理的概念出发，可以也归纳出需求管理活动的范围主要有需求的开发和需求的管理二个部分的内容。CMM2的需求管理需求的开发包括：（1）需求获取；（2）需求分析；（3）编写需求规格说明书；（4）需求验证。需求的管理包括：（1）确定需求变更控制的过程；（2）组织变更控制委员会；（3）进行需求变更波及分析；（4）跟踪所有受需求变更影响的工作产品；（5）建立需求基准版本和需求控制版本文档；（6）维护需求变更的历史记录；（7）追踪每项需求的状态并建立数据库；（8）衡量需求的稳定性；（9）使用需求管理工具进行需求管理。从CMM2对需求管理的要求、目标和管理过程中可以看出，CMM2的侧重点在于需求获取以后，如何建立需求基准线，并依据需求基准线，对项目的需求进行的控制和管理。面对软件工程过程中存在的需求不确定性问题，软件工程进一步获得发展，其中一个具体体现，就是发展出“需求工程”的概念。需求工程是提供一种适当的机制，以了解用户想要什么、分析需求、评估可行性、协商合理的解决方案、无歧义地规约解决方案、确认规约以及在开发过程中管理这些被确认的需求规约的过程。因此，需求工程的活动也可分为两大过程域，一个过程域是需求开发，另一过程域是需求管理。需求工程的两大过程域现代软件工程的需求工程需求开发过程需求管理过程需求获取需求分析需求处理需求确认需求实现需求跟踪需求变更控制3.1.3现代软件工程的需求工程需求开发过程域需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。需求获取的目的是通过各种途径获取用户的需求信息，产生《用户需求说明书》或《产品远景文件》。需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。需求处理的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。需求管理过程域需求管理的目的是在客户与开发方之间建立对需求的共同理解的基础上，实现需求并在实现的过程中，维护需求与其它工作成果的一致性，并控制需求的变更。需求实现是指在系统概要分析、详细分析和系统编码、测试等开发过程中，实现系统的需求。需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。产品工程的层次图：3.1.4传统软件工程的局限性1、从过程看：现代软件工程的需求过程要求参与整个产品生命周期的需求管理，注重整个产品过程的全部而不是一个阶段完整产品硬件软件数据功能行为需求工程（全局视图）业务和系统建模分析和设计建模构造和集成实现传统软件工程的局限性——需求管理是全过程的需求处理过程产品使用维护系统构建实施产品规划设计系统分析规约需求分析理解目标环境需求描述需求确认规格说明需求分析规范说明设计规范说明产品用户反馈构建反馈设计反馈分析反馈需求工程的结构图：传统软件工程的局限性2、从功能看：现代软件工程的需求过程扩大了对需求管理的功能范围传统软件工程的需求分析，仅仅是对“用户需求”的计算机术语化“描述”转换。（1）确定对系统的综合要求（2）分析系统的数据要求：（3）抽象出并确立目标系统的逻辑模型；（4）编写需求规格说明书。我们可以回忆一下，在软件工程中，需求分析花了很大的时间和篇幅，介绍具体的需求分析的方法，比如：早期面向结构化的分析方法（SA）、数据流图（DFD）等。现代软件工程的需求工程需求开发过程需求管理过程需求获取需求分析需求处理需求确认需求实现需求跟踪需求变更控制3、从思想方法上看：我们从传统软件工程的定义和计划阶段的工作内容，可以看出，软件工程认定：“问题”已经是一个明确的、固定的、可获得的；如果通过可行性分析，认为项目可行，则此“问题”也是可“求解”的。因此，根据这个假设，可以确定工作内容、产品与成果、验收标准等技术指标，也可以制订工作进度、任务分解，以至可以进行成本预算等，确定了任务的目标。在这个假设下，软件工程的需求分析，是一个“纯”技术性的“转换”。既把用户的需求，准确地描述为“软件需求”的过程。传统软件工程的局限性传统软件工程的假象前提：（1）软件工程假定：用户需求在需求分析开始之前，是一个基本明确的、固定的、可获得的。（2）需求分析阶段的目的，是“描述”这个已经存在，但还没有用开发者自己的方式“描述”出来的需