第03章软件需求管理新课件

《第03章软件需求管理新课件》由会员分享，可在线阅读，更多相关《第03章软件需求管理新课件（92页珍藏版）》请在金锄头文库上搜索。

1、第三章 软件需求管理,第三章目录,需求工程与需求管理的概念-3.1 需求开发阶段的需求管理-3.2 需求实现阶段的需求管理-3.3 需求变更控制管理-3.4,3.1 需求工程与需求管理的概念,3.1.1 需求的噩梦 3.1.2 需求与需求管理的概念 3.1.3 现代软件工程的需求工程 3.1.4 传统软件工程的局限性,对大多数软件和系统开发团队来说，与过去自由的日子相比，20 世纪 90 年代是一个强调流程的时代。评测和验证有效的软件开发流程的标准得到推广和普及。许多论述软件开发流程的书籍和文献以及关于业务建模和重构的相关材料纷纷出版。不断涌现出的软件工具已经帮助人们制定和应用有效的软件开发流

2、程。在这十年内，全球经济对软件的依赖程度加深，它推动着开发流程的发展，提高了系统质量。 既然如此，那么今天频频发生的软件项目失败的事件又如何解释呢？ 即使不是大多数，但为什么仍有那么多的项目受到延期、预算超支和质量问题的困扰呢？随着我们的业务、国家经济和日常活动越来越依赖于系统，如何才能提高系统的质量？,3.1 需求工程与需求管理的概念,为什么要管理需求？ 简单地说，系统开发团队之所以管理需求，是因为他们想让项目获得成功。满足项目需求即为成功打下了基础。若无法管理需求，达到目标的几率就会降低。 也就是说：好的需求管理是项目成功的第一位因素。采用需求管理可以给项目组带来很多的好处，直至项目取得成

3、功。 Brooks1987：不能得到完整、正确以及无二义性的软件需求仍然是如今导致软件开发失败的一个重大原因,3.1.1 需求的噩梦,一组数字,据Standish Group(1994)的研究表明，在美国： 每年大约花2500亿美元，开发17.5万个应用程序项目 大公司开发项目的平均成本是232.2万美元 中等公司的平均成本是133.1万美元 小公司则是43.4万美元 另一方面： 大约31%的项目在完成之前被取消 52.7%的项目成本是项目原来预算的189% 因此， Standish Group估计，美国公司和政府机构 在被取消软件项目上的花费，每年大约是810亿美元 同样，他们为超过交付时间

4、而需要多支付590亿美元,软件开发的问题分类,1、需求规格说明4、软件和测试 2、管理客户需求5、项目管理 3、建档6、编码 问题的重要性依次降低,ESPITI(欧洲软件过程改进培训倡议）（1995）所作的一个调查，3800个被调查者认为，软件开发的主要问题、次要问题和不是问题的问题如图。 一半以上的人认为，软件的二个最大问题是： 1、需求规格说明 2、管理客户需求 相对而言，编码不是问题,项目失败的根本原因,Standish Group的研究表明，对软件项目的评价因素，可以归纳为： 成功（大公司只占9%、小公司有16%） 有异议（推迟且没有达到预期的目标） 失败（取消） 而有异议的三个主要原

5、因是： 1、缺乏用户的参与（占所有项目的13%） 2、不完整的需求和规格说明（占所有项目的12%） 3、不断改变的需求和规格说明（占所有项目的12%） 而其他因素，则比例较小，例如： 不合理的时间进度和时间分段（4%） 人和资源不足（6%） 技术技能不够（7%） 结论：1/3的项目直接与需求的获取、建档和管理有关,需求变化,合理范围内的变化： 用户不了解自己的需求 需求本身易变，市场、技术、竞争因素 不合理的变化： 需求文档质量不高 需求分析技能、技术和管理上的缺陷 需求变化的原因： 未受控制的需求变更 遗漏需求 用户交流不够 需求规约质量差 低效的需求分析,为什么要管理需求？,迭代开发模式下

6、，需求在项目各阶段所占有的比例,需要更好地适应需求变化、更好的进行范围控制和管理,需求错误的代价,修复的相对成本,开发阶段,设计,0.5,维护,20,验收测试,5,单元测试,2,编码,1,3.1.2 需求与需求管理的概念,什么是需求？ 需求的基本概念 宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。 需求是对系统要做什么、如何工作、表现出来的特征、必须具备的质量、必须满足的约束的叙述 需求的重要性 需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。 国内软件业的

7、痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。,什么是软件需求？,一般把需求定义为“（正在构建的）系统必须符合的条件或具备的功能或能力”。电气和电子工程师学会使用的定义与此类似。 著名的需求工程设计师 Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更为精练的定义，它特指软件方面 - 但不仅仅限于软件： 1、软件需求可定义为： 用户需解决某一问题或达到某一目标所需的软件功能。 2、系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。,需求全部是来自用户吗？,需求的分解,问题领域需要,用户需求,软件系统需要,系统需

8、求,应用系统需要,系统特性,什么是需求管理？,由于需求是正在构建的系统必须符合的事务，而且符合某些需求决定了项目的成功或失败，因此找出需求是什么，将它们记下来，进行组织，并在发生变化时对它们进行追踪，这些活动过程，就是需求管理。 换句话说，需求管理就是： 一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。 这个定义与 Dorfman 与 Thayer 以及 IEEE 的“软件需求工程”的定义相似。需求工程包括获取、分析、规定、验证和管理软件需求，而“软件需求管理”则是对所有相关活动的规划和控制。 所以，需求管理包括软件需求过程的整个过程

9、,软件项目和软件过程的需求管理,PMBOK的范围管理 按照PMBOK的定义，范围是指产生项目产品所包括的所有工作及产生这些产品的过程。范围管理是指对项目包括什么和不包括什么的定义与控制过程。 项目范围管理的核心是：为了顺利地完成项目而设置了一些过程，这些过程的目的是确保项目包括且仅仅包括所要求的工作（交付成果）。这一控制过程的含义同时还指：确保项目组和用户（或称为项目利益关系人）对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解。 从软件项目的需求管理，理解项目管理的范围管理,CMM2的需求管理,软件过程能力成熟度模型（CMM）对需求管理作了明确的要求，为达到CMM2级，组织

10、就必须具备满足软件开发与管理的六个关键过程域（key Process Areas，KPA）的能力。而需求管理就是这六个关键过程域中的第一个，是其他五个域实施的前提。 CMM2指出，需求管理的目的是在客户和遵循客户需求的软件项目之间建立一种共同的理解。因此，需求管理活动的内容应包括就软件的需求同客户达成一种共识并加以管理。该共识就是“指定给软件的系统需求”。 CMM2需求管理的目标是： （1）控制指定给软件的系统需求，为软件工程和管理应用建立基线； （2）保持软件计划、产品和活动与指定给软件的系统需求一致。,CMM2的需求管理,CMM对需求管理的定义是： 对需求分配进行管理，既要在用户和实现用户

11、需求的项目组之间达成共识；控制系统需求，为研发过程和项目管理建立基线；保持项目计划、产品和活动与系统需求的一致性。 从定义出发，需求管理涉及三个方面的内容： 需求定义的管理、需求实现的管理、需求变更的管理。 一般认为，需求管理并不包括需求的收集和分析，而是假定组织已收集了软件需求或已经明确地给出了需求的定义。或者说，广义的需求管理还应包括用户需求的收集、处理、分析和验证等内容。 我们从广义需求管理的概念出发，可以也归纳出需求管理活动的范围主要有需求的开发和需求的管理二个部分的内容。,CMM2的需求管理,需求的开发包括： （1） 需求获取； （2） 需求分析； （3） 编写需求规格说明书； （4

12、） 需求验证。,需求的管理包括： （1） 确定需求变更控制的过程； （2） 组织变更控制委员会； （3） 进行需求变更波及分析； （4） 跟踪所有受需求变更影响的工作产品； （5） 建立需求基准版本和需求控制版本文档； （6） 维护需求变更的历史记录； （7） 追踪每项需求的状态并建立数据库； （8） 衡量需求的稳定性； （9） 使用需求管理工具进行需求管理。,从CMM2对需求管理的要求、目标和管理过程中可以看出，CMM2的侧重点在于需求获取以后，如何建立需求基准线，并依据需求基准线，对项目的需求进行的控制和管理。,面对软件工程过程中存在的需求不确定性问题，软件工程进一步获得发展，其中一个具体

13、体现，就是发展出“需求工程”的概念。 需求工程是提供一种适当的机制，以了解用户想要什么、分析需求、评估可行性、协商合理的解决方案、无歧义地规约解决方案、确认规约以及在开发过程中管理这些被确认的需求规约的过程。 因此，需求工程的活动也可分为两大过程域，一个过程域是需求开发，另一过程域是需求管理。,需求工程的 两大过程域,3.1.3 现代软件工程的需求工程,需求开发过程域 需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。 需求获取的目的是通过各种途径获取用户的需求信息，产生用户需求说明书或产品远景文件。 需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有

14、“问答分析法”和“建模分析法”两类。 需求处理的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生产品需求规格说明书。系统设计人员将依据产品需求规格说明书开展系统设计工作。 需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。,需求管理过程域 需求管理的目的是在客户与开发方之间建立对需求的共同理解的基础上，实现需求并在实现的过程中，维护需求与其它工作成果的一致性，并控制需求的变更。 需求实现是指在系统概要分析、详细分析和系统编码、测试等开发过程中，实现系统的需求。 需求跟踪是指通过比较需求文档与后续工作成果之间的对应

15、关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。 需求变更控制是指依据“变更申请审批更改重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。,产品工程的层次图：,3.1.4 传统软件工程的局限性,1、从过程看： 现代软件工程的需求过程要求参与整个产品生命周期的需求管理，注重整个产品过程的全部而不是一个阶段,需求工程 （全局视图）,业务和系统建模,分析和设计建模,构造和集成实现,传统软件工程的局限性 需求管理是全过程的,需求工程 的结构图：,传统软件工程的局限性,2、从功能看： 现代软件工程的需求过程扩大了对需求管理的功能范围,传统软件工程的需求分析，仅仅是对

16、“用户需求”的计算机术语化“描述”转换。 （1） 确定对系统的综合要求 （2） 分析系统的数据要求： （3） 抽象出并确立目标系统的逻辑模型； （4） 编写需求规格说明书。,我们可以回忆一下，在软件工程中，需求分析花了很大的时间和篇幅，介绍具体的需求分析的方法，比如：早期面向结构化的分析方法（SA）、数据流图（DFD）等。,3、从思想方法上看： 我们从传统软件工程的定义和计划阶段的工作内容，可以看出，软件工程认定： “问题”已经是一个明确的、固定的、可获得的； 如果通过可行性分析，认为项目可行，则此“问题”也是可“求解”的。 因此，根据这个假设，可以确定工作内容、产品与成果、验收标准等技术指标，也可以制订工作进度、任务分解，以至可以进行成本预算等，确定了任务的目标。 在这个假设下，软件工程的需求分析，是一个“纯”技术性的“转换”。既把用户的需求，准确地描述为“软件需求”的过程。,传统软件工程的局限性,传统软件工程的假象前提： （1）软件工程假定：用户需求在需求分析开始之前，是一个基本明确的、固定的