《软件需求管理》ppt课件

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

1、软件需求管理,目录,需求管理的概念3.1 需求开发的管理3.2 需求实现的管理3.3 需求变更的管理3.4 软件需求管理工具介绍3.5 案例分析：一个项目需求分析和处理的案例3.6,3.1 需求管理的概念, 3.1 软件需求管理的概念,3.1.1 需求与需求管理的概念 3.1.2 软件工程的软件定义与需求分析 3.1.3 CMM2的需求管理 3.1.4 PMBOK的范围管理,对大多数软件和系统开发团队来说，与过去自由的日子相比，20 世纪 90 年代是一个强调流程的时代。评测和验证有效的软件开发流程的标准得到推广和普及。许多论述软件开发流程的书籍和文献以及关于业务建模和重建的相关材料纷纷出版。

2、不断涌现出的软件工具已经帮助人们制定和应用有效的软件开发流程。在这十年内，全球经济对软件的依赖程度加深，它推动着开发流程的发展，提高了系统质量。 既然如此，那么今天频频发生的软件项目失败的事件又如何解释呢？ 即使不是大多数，但为什么仍有那么多的项目受到延期、预算超支和质量问题的困扰呢？随着我们的业务、国家经济和日常活动越来越依赖于系统，如何才能提高系统的质量？ 本章介绍针对有效需求管理过程的需求元素，如何成功实施对需求元素的管理。,为什么要管理需求,为什么要管理需求？ 简单地说，系统开发团队之所以管理需求，是因为他们想让项目获得成功。满足项目需求即为成功打下了基础。若无法管理需求，达到目标的几

3、率就会降低。 也就是说：好的需求管理是项目成功的第一位因素。采用需求管理可以给项目组带来很多的好处，直至项目取得成功。,3.1.1 需求与需求管理的概念,为什么要管理需求？,这是Rational 的标准开发流程图，从图中，我们可以看出，需求分析在启动和计划阶段，占有相当大的比例。,什么是需求？,Rational 把需求定义为“（正在构建的）系统必须符合的条件或具备的功能”。电气和电子工程师学会使用的定义与此类似。 著名的需求工程设计师 Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更为精练的定义，它特指软件方面 - 但不仅仅限于软件： “软件需求可定义为

4、： 用户解决某一问题或达到某一目标所需的软件功能。 系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。”,什么是需求管理？,由于需求是正在构建的系统必须符合的事务，而且符合某些需求决定了项目的成功或失败，因此找出需求是什么，将它们记下来，进行组织，并在发生变化时对它们进行追踪，这些活动都是有意义的。 换句话说，需求管理就是： 一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。 这个定义与 Dorfman 与 Thayer 以及 IEEE 的“软件需求工程”的定义相似。需求工程包括获取、分析、规定、验证

5、和管理软件需求，而“软件需求管理”则是对所有相关活动的规划和控制。,现代软件工程对需求工程的定义,面对软件工程过程中存在的需求不确定性问题，软件工程进一步获得发展，其中一个具体体现，就是发展出“需求工程”的概念。需求工程是提供一种适当的机制，以了解用户想要什么、分析需求、评估可行性、协商合理的解决方案、无歧义地规约解决方案、确认规约以及在开发过程中管理这些被确认的需求规约。 现代需求工程一般被描述为6个步骤，包括： 获取（需求诱导） 分析（需求分析和谈判） 规定（规约） 系统建模 验证（需求确认） 需求管理（控制与变更管理） “诱导”的含义是：项目团队用来获取或发现用户请求，确定请求后面所隐藏

6、的真正需要，以及为满足这些需要对系统提出的一组适当需求。第6个步骤的“需求管理”，主要是对针对所有相关活动的规划、控制和变更管理。因此，整个管理构成了软件需求管理的主要内容。,需求管理存在的问题,1、需求不总是显而易见的，而且它可来自各个方面。 2、需求并不总是容易用文字明白无误地表达。 3、存在不同种类的需求，其详细程度各不相同。 4、如果不加以控制，需求的数量将难以管理。 5、需求相互之间以及与流程的其他可交付工件之间以多种方式相关联。 6、需求既非同等重要，处理的难度也不同。 7、需求涉及众多相关利益责任方，这意味着需求要由跨职能的各组人员来管理。 8、需求发生变更。 9、需求可能对时间

7、敏感。,3.1.2 软件工程的软件定义与需求分析,软件工程定义的6个软件生命周期阶段： 软件定义与计划、需求分析、软件设计、编码、测试、运行与维护等。 软件定义是指系统分析员通过对系统实际用户、使用管理部门、相关部门及人员进行的实际调查，搞清楚“问题”的背景、目的是什么？然后，据此提出关于“问题”的性质、工程目标、规模、相关联系等项目的基本情况。一般这些情况，反映在项目定义报告中。项目定义报告包括：工程项目名称、使用方、开发方、对问题的概括定义、项目目标、项目规模等。这个定义是需要用户认可的，因为这是双方对“问题”最基础的共识。 根据Rational ROSE核心工作流的定义，在这个阶段，就是

8、建立业务模型。业务模型可以比较明显地反映项目组在这个阶段所感兴趣的问题和所做的工作。 所以，软件定义、业务建模，都还不是需求分析。,软件工程的需求分析,软件工程的需求分析，通过问题识别、分析与综合、制订规格说明和评审等阶段，达到以下一些需求分析阶段的目标，它们都是对“用户需求”进行更专业化的“描述”转换。 （1） 确定对系统的综合要求 （2） 分析系统的数据要求： （3） 抽象出并确立目标系统的逻辑模型； （4） 编写需求规格说明书。 我们可以回忆一下，在软件工程中，需求分析部分接着就会花很大的时间和篇幅，介绍具体的需求分析的方法，比如：早期面向结构化的分析方法（Structured anal

9、ysis ,SA）、数据流图（Data flow diagram ,DFD）等。后期面向对象的分析方法。,软件工程的软件定义,软件定义/业务建模与软件需求分析到底有什么区别？ 举一个例子： 到银行取钱这一业务，19世纪没有计算机之前同样要做，那时的咨询公司肯定也为银行提供一套业务解决方案，当然是由人手工完成，并且把算盘、打卡机等可以提高工效的工具全部用上；今天呢，取钱业务本质上并无太大变化，只不过咨询公司会引入IT技术来支持业务的运作，更进一步提高人的工效，IT技术在此仍然是与算盘、打卡机类似的工具而已（当然从技术上来讲要先进得多）。 由此可见，业务建模和重组是针对企业的业务目标而作的业务解决

10、方案；软件需求则实际上是对业务解决方案所设计的业务流程中被使用的工具达到功能和实现的定义。,软件工程的软件定义,我们还没有介绍软件工程中要求的需求分析的内容，但是从定义和计划阶段的工作内容，我们可以看出，软件工程认定： “问题”已经是一个明确的、固定的、可获得的，如果通过可行性分析，认为项目可行，则此“问题”也是可“求解”的。因此，可以根据这个假设，可以确定工作内容、产品与成果、验收标准等技术指标，也可以制订工作进度、任务分解，以至可以进行成本预算等，确定了任务的目标。,软件工程的需求分析,在这个假设下，软件工程对需求分析，是一个“纯”技术性的“转换”。既把用户的需求，准确地描述为“软件需求”

11、的过程。 确切地讲，软件工程的需求分析，通过问题识别、分析与综合、制订规格说明和评审等阶段，达到以下一些需求分析阶段的目标，它们都是对“用户需求”进行更专业化的“描述”转换。 归纳软件工程的需求分析阶段的任务是：,软件工程的需求分析,（1）确定对系统的综合要求： 对系统的综合要求，一般包括：功能要求、性能要求、运行要求、其他要求等。 功能要求包括系统应该实现的功能； 性能要求包括系统的相应时间、资源限制、数据精确性、系统适应性等； 运行要求包括系统硬件环境、网络环境、系统软件、接口等的具体要求； 其他要求包括：安全保密、可靠性、可维护性、可移植性、可扩展性等等。,软件工程的需求分析,（2）分析

12、系统的数据要求： 数据要求重要指系统分析师根据用户的信息流抽象、归纳出系统所要求的数据定义、数据逻辑关系、输入/出数据定义、数据采集方式等。 （3）抽象出并确立目标系统的逻辑模型； 根据以上二部分的工作，系统分析师可以导出目标系统的详细逻辑模型。在Rational ROSE中，这样的逻辑模型可以体现在用况模型、设计模型、实施模型和实现模型四类模型结构中。 （4）编写需求规格说明书。 我们可以回忆一下，在软件工程中，需求分析部分接着就会花很大的时间和篇幅，介绍具体的需求分析的方法，比如：早期面向结构化的分析方法（Structured analisys ,SA）、数据流图（Data flow di

13、agram ,DFD）等。 后期面向对象的分析方法等等。,软件工程的需求分析,简单的回顾和归纳中，我们暂且可以得出这样一个印象： （1）软件工程假定：用户需求在需求分析开始之前，是一个基本明确的、固定的、可获得的。 （2）需求分析阶段的目的，是“描述”这个已经存在，但还没有用开发者自己的方式“描述”出来的需求。 （3）软件工程把这个“描述”工作，做了定义，就是需求分析的四个任务。通过这个任务的完成，获得数据字典、系统的数据流定义、处理逻辑定义等手段，实现对“用户需求”的描述。 （4）软件工程更关注这种：“描述”的方法和过程（需求分析方法）。,3.1.3 CMM2的需求管理,过程能力成熟度模型（

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

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

16、 （2） 需求分析； （3） 编写需求规格说明书； （4） 需求验证。,需求的管理包括： （1） 确定需求变更控制的过程； （2） 组织变更控制委员会； （3） 进行需求变更波及分析； （4） 跟踪所有受需求变更影响的工作产品； （5） 建立需求基准版本和需求控制版本文档； （6） 维护需求变更的历史记录； （7） 追踪每项需求的状态并建立数据库； （8） 衡量需求的稳定性； （9） 使用需求管理工具进行需求管理。,从CMM2对需求管理的要求、目标和管理过程中可以看出，CMM2的侧重点在于需求获取以后，如何建立需求基准线，并依据需求基准线，对项目的需求进行 的控制和管理。,3.1.4 PMBOK的范围管理,PMI的项目管理知识体系包括了了九大知识领域（集成、范围、时间、成本、质量、人力资源、沟通、风险和采购），每个知识领域中，又定义了相应的项目管理过程。,按照PMBOK的定义，范围是指产生项目产品所包括的所有工作及产生这些产品的过程。项目范围