软件项目管理需求管理.ppt

软件件项目管理需求管理目管理需求管理软件项目管理软件项目管理什么什么什么什么是是是是项目项目项目项目？如何如何如何如何获得获得获得获得项目项目项目项目？如何如何如何如何管理管理管理管理项目项目项目项目？怎样怎样怎样怎样提交提交提交提交项目项目项目项目？结项后结项后结项后结项后应做应做应做应做什么什么什么什么？需求前延需求前延质量检验过程质量检验过程项目需求的实际验证项目需求的实际验证课程体系课程体系2 2如何管理项目？(how to manage a project)3 3需求管理基础知识需求管理基础知识4 4软件项目管理的关键技术软件项目管理的关键技术需求管理需求管理项目估算项目估算进度管理进度管理成本管理成本管理配置管理配置管理风险管理风险管理质量管理质量管理资源管理资源管理管 理配 置管 理风 险管 理质 量管 理资 源管 理需 求估 算项 目管 理进 度管 理成 本5 5需求管理的内容需求管理的内容l什么是需求工程什么是需求工程l什么是需求开发什么是需求开发l什么是需求管理什么是需求管理l需求管理所要完成的任务需求管理所要完成的任务l需求管理的问题需求管理的问题l如何进行需求管理如何进行需求管理6 6一、什么是需求工程一、什么是需求工程l在项目或产品开发过程中，一般地来讲，把在项目或产品开发过程中，一般地来讲，把与需求直与需求直接相关的活动统称为需求工程。接相关的活动统称为需求工程。l需求工程的目的是通过与用户广泛地交流确定应用系需求工程的目的是通过与用户广泛地交流确定应用系统的目标。统的目标。l需求活动以需求活动以“工程化工程化”的方法被提出、分析和组织，的方法被提出、分析和组织，它鼓励用户以一种积极的方式参与需求分析活动中，它鼓励用户以一种积极的方式参与需求分析活动中，并在整个软件生命周期强调用户参与和领域专家的指并在整个软件生命周期强调用户参与和领域专家的指导作用，促使目标系统最大地满足用户需求。导作用，促使目标系统最大地满足用户需求。7 7软件需求的定义软件需求的定义lRational Rational 把把需求需求定义为定义为“（正在构建的）系统必须符合（正在构建的）系统必须符合的条件或具备的功能的条件或具备的功能”。l软件需求软件需求：用户解决某一问题或达到某一目标所需的软用户解决某一问题或达到某一目标所需的软件功能。系统或系统构件为了满足合同、规约、标准或其件功能。系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。他正式实行的文档而必须满足或具备的软件功能。l简单的说，简单的说，软件需求软件需求就是确定系统需要做什么；严格意义就是确定系统需要做什么；严格意义上，软件需求是系统或软件必须达到的目标与能力。上，软件需求是系统或软件必须达到的目标与能力。8 8软件需求与其它软件过程的关系软件需求与其它软件过程的关系l项目计划过程项目计划过程：需求是制定项目计划的基础，开发资：需求是制定项目计划的基础，开发资源和进度安排的估计都要建立在对最终产品的真正理源和进度安排的估计都要建立在对最终产品的真正理解之上。解之上。l跟踪控制过程跟踪控制过程：监控每项需求的状态，以便项目管理：监控每项需求的状态，以便项目管理者能发现设计和验证是否达到了预期的要求。者能发现设计和验证是否达到了预期的要求。l变更控制过程变更控制过程：在需求编写成文档以后，所有接下来：在需求编写成文档以后，所有接下来的变更都应通过确定的变更控制过程来进行，以确保的变更都应通过确定的变更控制过程来进行，以确保变更的影响是可以接受的、受到变更影响的所有人都变更的影响是可以接受的、受到变更影响的所有人都接到通知并明白这一点、由合适的人选来做出接受变接到通知并明白这一点、由合适的人选来做出接受变更的正式决定、资源按需进行调整、保持需求文档是更的正式决定、资源按需进行调整、保持需求文档是最新版本并是准确的更新文档。最新版本并是准确的更新文档。9 9软件需求与其它软件过程的关系软件需求与其它软件过程的关系l系统测试过程系统测试过程：软件需求是系统测试的重要参考。系：软件需求是系统测试的重要参考。系统测试是一种方法，可以验证计划中所列的功能是否统测试是一种方法，可以验证计划中所列的功能是否按预期要求实现了。同时，也验证了用户任务是否能按预期要求实现了。同时，也验证了用户任务是否能正确地执行。正确地执行。l文档编制过程文档编制过程：产品的需求是编写文档的重要参考，：产品的需求是编写文档的重要参考，低质量和拖延的需求会给编写用户文档带来极大的困低质量和拖延的需求会给编写用户文档带来极大的困难。难。l系统构建过程系统构建过程：软件项目最终交付的主要是可执行软：软件项目最终交付的主要是可执行软件，而不是需求说明文档。但需求文档是所有设计、件，而不是需求说明文档。但需求文档是所有设计、实现工作的基础，需要根据需求文档来确定模块设计，实现工作的基础，需要根据需求文档来确定模块设计，而模块又要作为编写代码的依据。系统构建过程需要而模块又要作为编写代码的依据。系统构建过程需要跟踪每项需求与相应的设计和软件代码。跟踪每项需求与相应的设计和软件代码。1010软件需求的抽象层次软件需求的抽象层次软件设计描述软件设计描述系统需求系统需求用户需求用户需求原始问题描述原始问题描述原始问题描述原始问题描述原始问题描述原始问题描述解决方案空间解决方案空间解决方案空间解决方案空间1111软件需求的抽象层次软件需求的抽象层次l原始问题描述原始问题描述：是对要解决的问题的叙述，它是软件：是对要解决的问题的叙述，它是软件需求的基础。需求的基础。l用户需求用户需求：是用自然语言和图表给出的关于系统需要：是用自然语言和图表给出的关于系统需要提供的服务及系统的操作约束。提供的服务及系统的操作约束。l系统需求系统需求：用详细术语给出系统要提供的服务及受到：用详细术语给出系统要提供的服务及受到的约束，系统需求文档应该是精确的，可以为系统的的约束，系统需求文档应该是精确的，可以为系统的实现提供依据，因而系统需求文档也称为功能描述，实现提供依据，因而系统需求文档也称为功能描述，可能成为用户和软件开发组织之间合同的重要内容。可能成为用户和软件开发组织之间合同的重要内容。l软件设计描述软件设计描述：是在系统需求的基础上加入更详细的：是在系统需求的基础上加入更详细的内容构成的，它作为软件详细设计和实现的基础，是内容构成的，它作为软件详细设计和实现的基础，是对软件设计活动的概要描述。对软件设计活动的概要描述。1212软件需求的抽象层次软件需求的抽象层次 用户需求：从用户的角度描述系统的需求，原则：用户需求：从用户的角度描述系统的需求，原则：l标准的格式标准的格式l使用一致的语言使用一致的语言l使用特殊文本使用特殊文本l尽量避免专业术语尽量避免专业术语1313软件需求的抽象层次软件需求的抽象层次系统需求的分类：系统需求的分类：l功能需求功能需求:描述系统所应提供的功能和服务描述系统所应提供的功能和服务,包括系统包括系统应该提供的服务、对输入如何响应及特定条件下系统应该提供的服务、对输入如何响应及特定条件下系统行为的描述。行为的描述。l非功能需求非功能需求:是指那些不直接与系统的具体功能相关的是指那些不直接与系统的具体功能相关的一类需求，是功能需求的补充。一类需求，是功能需求的补充。l领域需求领域需求:其来源不是系统的用户，而是系统应用的领其来源不是系统的用户，而是系统应用的领域，反应了该领域的特点。领域需求可能是功能需求，域，反应了该领域的特点。领域需求可能是功能需求，也可能是非功能需求，其确定需要领域知识。也可能是非功能需求，其确定需要领域知识。1414软件需求质量评价软件需求质量评价 我们需要在软件需求规格说明书建立之后，我们需要在软件需求规格说明书建立之后，就对软件需求的质量进行评价，一个好的需求就对软件需求的质量进行评价，一个好的需求集应该包括用户解决问题需要的功能和服务，集应该包括用户解决问题需要的功能和服务，而且而且尽量避免涉及软件设计与软件是实现的细尽量避免涉及软件设计与软件是实现的细节。节。1515软件需求质量评价软件需求质量评价软件需求质量度量的软件需求质量度量的软件需求质量度量的软件需求质量度量的9 9 9 9个元素：个元素：个元素：个元素：ll正确性正确性正确性正确性ll无歧义无歧义无歧义无歧义ll完备性完备性完备性完备性ll一致性一致性一致性一致性ll根据重要性和稳定性分级根据重要性和稳定性分级根据重要性和稳定性分级根据重要性和稳定性分级ll可验证性可验证性可验证性可验证性ll可修改性可修改性可修改性可修改性ll可跟踪性可跟踪性可跟踪性可跟踪性ll可理解性可理解性可理解性可理解性1616需求工程发展历程需求工程发展历程 20 20世纪世纪8080年代中期，软件工程的子领域年代中期，软件工程的子领域需求工需求工程（程（RERE）逐步形成。它是一个包括创建和维护需求文档）逐步形成。它是一个包括创建和维护需求文档所必须的所有活动的过程，是将用户非形式化的软件需所必须的所有活动的过程，是将用户非形式化的软件需求转变为形式化的需求规格说明的过程。求转变为形式化的需求规格说明的过程。对应用问题及其环境进行理解与分析对应用问题及其环境进行理解与分析 为问题所涉及的信息和功能建立模型为问题所涉及的信息和功能建立模型 将用户需求精确化和标准化将用户需求精确化和标准化 编写需求规格说明书编写需求规格说明书 进入进入2020世纪世纪9090年代后，需求工程成为研究热点。年代后，需求工程成为研究热点。1818需求工程发展历程需求工程发展历程 需求工程的发展趋势是对象化、形式化和自需求工程的发展趋势是对象化、形式化和自动化，并将向纵深发展和综合发展。动化，并将向纵深发展和综合发展。1919ll需求工程需求开发需求工程需求开发需求工程需求开发需求工程需求开发 +需求管理需求管理需求管理需求管理 需求工程需求工程获取需求获取需求分析需求分析需求定义需求定义需求验证需求验证需求需求变更控制需求变更控制需求跟踪需求跟踪需求状态跟踪需求状态跟踪需求文档版本控制需求文档版本控制需求开发需求开发需求管理需求管理需求工程研究内容需求工程研究内容需求工程研究内容需求工程研究内容2020需求开发与需求管理之间的界限需求开发与需求管理之间的界限需求开发与需求管理之间的界限需求开发与需求管理之间的界限用户用户/系统系统市场市场管理者管理者初始需求初始需求变更的需求变更的需求获取获取,分析分析,定义定义,验验证需求证需求控制需求控制需求变更变更需求规格说明需求规格说明项目环项目环境境需求开发需求开发需求管理需求管理2121二、什么是需求开发二、什么是需求开发二、什么是需求开发二、什么是需求开发2222需求获取需求获取 需求获取是需求开发的第一个步骤，是一切需求获取是需求开发的第一个步骤，是一切工作的开始。从确定需求开发过程，确定如何工作的开始。从确定需求开发过程，确定如何组织需求的收集、分析、细化并核实的步骤，组织需求的收集、分析、细化并核实的步骤，到将它编写成文档，主要的活动和展现成果有到将它编写成文档，主要的活动和展现成果有1111项。项。2323需求获取需求获取l确定需求开发过程确定需求开发过程l编写项目视图和范围文档编写项目视图和范围文档l用户群分类用户群分类l选择产品代表选择产品代表l建立核心队伍建立核心队伍l确定使用实例确定使用实例l召开应用程序开发联系会议召开应用程序开发联系会议l分析用户工作流程分析用户工作流程l确定质量属性确定质量属性l检查问题报告检查问题报告l需求重用需求重用2424需求分析需求分析 需求分析包括提炼、分析和仔细审查已收集到的需需求分析包括提炼、分析和仔细审查已收集到的需求，以确保所有的项目参与者都明白其含义并找出其求，以确保所有的项目参与者都明白其含义并找出其中的错误、遗漏或其他不足的地方。中的错误、遗漏或其他不足的地方。l绘制关联图绘制关联图l创建用户接口原型创建用户接口原型l分析可行性分析可行性l确定需求优先级确定需求优先级l建立需求模型建立需求模型l编写数据字典编写数据字典l应用质量功能调配应用质量功能调配2727编写需求文档编写需求文档 软件需求文档包括用户需求和详细的系统需求描述，软件需求文档包括用户需求和详细的系统需求描述，是对软件系统要求的正式陈述。编写需求文档应注意是对软件系统要求的正式陈述。编写需求文档应注意以下几点：以下几点：l语句和段落尽量简短语句和段落尽量简短l表达时采用主动语态表达时采用主动语态l语句要完整，语法、标点等要正确语句要完整，语法、标点等要正确l使用的术语要与词汇表中定义保持一致使用的术语要与词汇表中定义保持一致l陈述时要采用一致的格式陈述时要采用一致的格式l避免模糊的、主观的术语，如性能避免模糊的、主观的术语，如性能“优越优越”l避免使用比较性的词汇避免使用比较性的词汇需求之用例图需求之用例图3030编写需求文档（续）编写需求文档（续）3131编写需求文档（续）编写需求文档（续）IEEE标标准准830-19983232编写需求文档（续）编写需求文档（续）l需求文档实例：需求文档实例：进销存系统需求规格说明书进销存系统需求规格说明书 oa oa办公自动化系统需求规格说明书办公自动化系统需求规格说明书3333需求验证需求验证l需求验证分析需求规格说明的正确性和可行性，检验需求验证分析需求规格说明的正确性和可行性，检验需求能否反映客户的意愿。需求能否反映客户的意愿。l重要性重要性如果在构造设计开始之前通过验证基于需求的测试如果在构造设计开始之前通过验证基于需求的测试计划和原型测试来验证需求的正确性及其质量，就计划和原型测试来验证需求的正确性及其质量，就能大大减少项目后期的返工现象。能大大减少项目后期的返工现象。而如果在后续的而如果在后续的开发或当系统投入使用时才发现需求文档中的错误，开发或当系统投入使用时才发现需求文档中的错误，就会导致更大代价的返工，因为需求的变化总是带就会导致更大代价的返工，因为需求的变化总是带来系统设计和实现的改变，从而使系统必须重新测来系统设计和实现的改变，从而使系统必须重新测试，由需求问题而对系统做变更的成本比修改设计试，由需求问题而对系统做变更的成本比修改设计或代码错误的成本要大得多。或代码错误的成本要大得多。3434需求验证需求验证l目的：目的：需求规约正确描述了预期的系统行为和特征；需求规约正确描述了预期的系统行为和特征；软件需求符合业务需求或其他来源的要求；软件需求符合业务需求或其他来源的要求；需求是完整和高质量的；需求是完整和高质量的；所有对需求的看法、观点是一致的；所有对需求的看法、观点是一致的；需求为产品设计、构造和测试提供了坚实的基础需求为产品设计、构造和测试提供了坚实的基础l手段：手段：软件测试软件测试软件评审软件评审3535需求验证步骤需求验证步骤确定合格的标准确定合格的标准编写用户手册编写用户手册依据需求编写测试用例依据需求编写测试用例审查需求文档审查需求文档3636需求验证的内容需求验证的内容可读性可读性可读性可读性一致性一致性一致性一致性完备性完备性完备性完备性现实性现实性现实性现实性可检验性可检验性可检验性可检验性可跟踪性可跟踪性可跟踪性可跟踪性可调节性可调节性可调节性可调节性有效性有效性有效性有效性3737三、什么是需求管理三、什么是需求管理l需求管理需求管理是一种获取、组织并记录软件需求的系统化是一种获取、组织并记录软件需求的系统化方案，同时也是一个使客户与项目团队对不断变更的方案，同时也是一个使客户与项目团队对不断变更的软件需求达成并保持一致的过程。软件需求达成并保持一致的过程。l需求管理需求管理在需求开发的基础上进行，贯穿于整个软件在需求开发的基础上进行，贯穿于整个软件项目过程，是软件项目管理的一部分。项目过程，是软件项目管理的一部分。3838需求管理与其他项目过程的联系需求管理与其他项目过程的联系需求管理需求管理制定项目计划制定项目计划系统测试过程系统测试过程项目跟踪和项目跟踪和控制过程控制过程变更控制过程变更控制过程制造过程制造过程用户编制用户编制文档过程文档过程基础基础基础基础产品可产品可追溯到追溯到作为作为参考参考验证实现验证实现的正确性的正确性作为作为基线基线进行进行变更变更跟踪跟踪状态状态作为作为输入输入基线确定前基线确定前缩小范围缩小范围请求范围请求范围缩减缩减3939l为什么要管理需求？为什么要管理需求？避免失败就是一个很充避免失败就是一个很充分的理由分的理由。提高项目的成功率和需求管理所。提高项目的成功率和需求管理所带来的其他好处同样也是理由。带来的其他好处同样也是理由。四、四、为什么要什么要进行需求管理行需求管理4040需求管理的困难性需求管理的困难性ll开发软件系统最为困难的部分就是准确说明开发开发软件系统最为困难的部分就是准确说明开发开发软件系统最为困难的部分就是准确说明开发开发软件系统最为困难的部分就是准确说明开发什么。什么。什么。什么。ll最为困难的概念性工作就是编写出详细技术最为困难的概念性工作就是编写出详细技术最为困难的概念性工作就是编写出详细技术最为困难的概念性工作就是编写出详细技术需求需求需求需求，这包括所有面向用户、面向机器和其它软件系统这包括所有面向用户、面向机器和其它软件系统这包括所有面向用户、面向机器和其它软件系统这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统的接口。同时这也是一旦做错，将最终会给系统的接口。同时这也是一旦做错，将最终会给系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改带来极大损害的部分，并且以后再对它进行修改带来极大损害的部分，并且以后再对它进行修改带来极大损害的部分，并且以后再对它进行修改也极为困难。也极为困难。也极为困难。也极为困难。4141需求获取的偏差需求获取的偏差客户如此描述需求客户如此描述需求项目经理如此理解项目经理如此理解分析员如此设计分析员如此设计程序员如此编码程序员如此编码商业顾问如此诠释商业顾问如此诠释项目文档如此编写项目文档如此编写安装程序如此简洁安装程序如此简洁客户投资如此巨大客户投资如此巨大技术支持如此肤浅技术支持如此肤浅 实际需求原来如此实际需求原来如此4242需求管理的困难性需求管理的困难性l需求不总是显而易见的，而且它可来自各个方面。需求不总是显而易见的，而且它可来自各个方面。l需求并不总是能容易用文字明白无误地表达。需求并不总是能容易用文字明白无误地表达。l存在不同种类的需求，其详细程度各不相同。存在不同种类的需求，其详细程度各不相同。l如果不加以控制，需求的数量将难以管理。如果不加以控制，需求的数量将难以管理。l需求之间相互关联，而且需求也和软件工程流程中的需求之间相互关联，而且需求也和软件工程流程中的其他可交付工件有关。其他可交付工件有关。l需求有唯一的特征或特征值。例如，它们的重要性和需求有唯一的特征或特征值。例如，它们的重要性和容易满足的程度都各不相同。容易满足的程度都各不相同。l需求涉及众多相关方面，这意味着需求要由功能交叉需求涉及众多相关方面，这意味着需求要由功能交叉的各组人员管理。的各组人员管理。l需求会变更。需求会变更。4343需求管理的目标需求管理的目标 l需求管理的目的是在客户和软件项目之间就需要满足的需求管理的目的是在客户和软件项目之间就需要满足的需求建立和维护一致的约定：需求建立和维护一致的约定：使软件需求受控，并建立供软件工程和管理使用的使软件需求受控，并建立供软件工程和管理使用的需需求基线求基线。必须控制需求基线的变动，按照变更控制的。必须控制需求基线的变动，按照变更控制的标准和规范的过程进行需求变更控制和版本控制。标准和规范的过程进行需求变更控制和版本控制。使软件计划、产品和活动与软件需求保持一致。必须使软件计划、产品和活动与软件需求保持一致。必须对需求进行跟踪，管理需求和其它联系链之间的联系对需求进行跟踪，管理需求和其它联系链之间的联系和依赖，必须就变更和软件项目各小组达成共识，对和依赖，必须就变更和软件项目各小组达成共识，对软件项目计划做出调整，其中包括人员的安排、任务软件项目计划做出调整，其中包括人员的安排、任务的安排、用户的沟通、成本的调整、进度的调整等。的安排、用户的沟通、成本的调整、进度的调整等。4444需求管理的原则需求管理的原则l需求一定要分类管理需求一定要分类管理l需求必须分优先级需求必须分优先级l需求必须文档化需求必须文档化l需求一旦变化，就必须对需求变更的影响进行评估需求一旦变化，就必须对需求变更的影响进行评估l需求管理必须与需求工程的其它活动紧密整合需求管理必须与需求工程的其它活动紧密整合4545需求管理策略需求管理策略l需求一定要与投入有必然的联系需求一定要与投入有必然的联系l需求的变更要经过出资者的认可需求的变更要经过出资者的认可l小的需求变更也要经过正规的需求管理流程小的需求变更也要经过正规的需求管理流程l精确的需求与范围定义并不会阻止需求的变更精确的需求与范围定义并不会阻止需求的变更4646五、如何进行需求管理五、如何进行需求管理l需求管理的关键技巧需求管理的关键技巧l需求管理的工具需求管理的工具4747制定需求管理规划制定需求管理规划l编写用于需求管理活动的计划。编写用于需求管理活动的计划。需求识别需求识别变更管理过程变更管理过程需求跟踪需求跟踪自动化工具自动化工具4848需求管理活动需求管理活动需求管理活动需求管理活动活动的任务活动的任务变更控制变更控制建议需求变更并分析其影响，做出是否变建议需求变更并分析其影响，做出是否变更的决策更的决策版本控制版本控制确定单个需求和确定单个需求和SRSSRS的版本的版本需求跟踪需求跟踪定义对于其它需求及系统元素的联系链定义对于其它需求及系统元素的联系链需求状态需求状态定义并跟踪需求的状态定义并跟踪需求的状态4949构建功能交叉的需求团队构建功能交叉的需求团队l与诸如测试或应用程序建模等流程不同（这些流程可与诸如测试或应用程序建模等流程不同（这些流程可在单个业务组中进行管理），需求管理涉及了每一个在单个业务组中进行管理），需求管理涉及了每一个能够为开发流程提供专门技术的个人；能够为开发流程提供专门技术的个人；l其中应包括那些代表客户和业务预期的人；其中应包括那些代表客户和业务预期的人；l开发经理、产品经理、分析员、系统工程师甚至客户开发经理、产品经理、分析员、系统工程师甚至客户都应该参与进来；都应该参与进来；l需求团队还应包括创建系统解决方案的人需求团队还应包括创建系统解决方案的人 -工程师、工程师、构架设计师、设计员、程序员、技术文档编写员以及构架设计师、设计员、程序员、技术文档编写员以及其他提供技术支持的个人；其他提供技术支持的个人；l测试员和其他质量保证人员应当作重要的团队成员。测试员和其他质量保证人员应当作重要的团队成员。5050干系人需求知识培训干系人需求知识培训l目的：建立对需求管理过程的共识目的：建立对需求管理过程的共识l作用：作用：控制客户期望控制客户期望保证需求过程的质量保证需求过程的质量保证需求的质量保证需求的质量5151范围管理范围管理l在需求超出资源能力在需求超出资源能力200%200%时，时，“砍砍”掉掉50%50%需求的步骤：需求的步骤：找出找出25-5025-50个概要需求，先不要精化个概要需求，先不要精化排定这些概要需求的价值排定这些概要需求的价值(Critical,Important,(Critical,Important,Useful)Useful)，CriticalCritical需求约占三分之一需求约占三分之一初估各个需求的工作量级别初估各个需求的工作量级别(High,Medium,Low)(High,Medium,Low)给出各个需求的风险级别给出各个需求的风险级别(High,Medium,Low)(High,Medium,Low)综合考虑以上三个因素得出优先级，再划出分界线，综合考虑以上三个因素得出优先级，再划出分界线，线上基本上包括所有线上基本上包括所有CriticalCritical和少量和少量ImportantImportant需需求求5454需求的变更管理需求的变更管理1 1 1 1、需求的变更难于完全避免、需求的变更难于完全避免、需求的变更难于完全避免、需求的变更难于完全避免 初始需求对问题的初始理解变更的需求对问题的新理解时间需求的变更需求的变更55552 2 2 2、需求变更原因分析、需求变更原因分析、需求变更原因分析、需求变更原因分析1)1)1)1)单纯的用户因素单纯的用户因素单纯的用户因素单纯的用户因素 2)2)2)2)市场形势变化市场形势变化市场形势变化市场形势变化 3)3)3)3)系统因素系统因素系统因素系统因素 4)4)4)4)工作环境和要求变化工作环境和要求变化工作环境和要求变化工作环境和要求变化 5)5)5)5)需求开发的缺陷需求开发的缺陷需求开发的缺陷需求开发的缺陷 需求分析、定义和评审不充分需求分析、定义和评审不充分需求分析、定义和评审不充分需求分析、定义和评审不充分 与用户沟通不畅与用户沟通不畅与用户沟通不畅与用户沟通不畅 需求的变更管理需求的变更管理56563 3、需求变更对软件开发的影响、需求变更对软件开发的影响 使变更前开发工作和成果失效使变更前开发工作和成果失效 返工成为被迫采取的对策返工成为被迫采取的对策 工作量及资源投入的增加使开发成本提高工作量及资源投入的增加使开发成本提高 项目完成时间后延项目完成时间后延 需求的变更管理需求的变更管理57574 4 4 4、需求变更失控可能导致的后果、需求变更失控可能导致的后果、需求变更失控可能导致的后果、需求变更失控可能导致的后果 未受控的需求未受控的需求未受控的需求未受控的需求 变更引起需求变更引起需求变更引起需求变更引起需求 和实现不一致和实现不一致和实现不一致和实现不一致 系统实现系统实现V1V1系统实现系统实现V2V2需求文档需求文档V1V1需求变更需求变更需求的变更管理需求的变更管理5858 受控的需求受控的需求受控的需求受控的需求 变更使需求和实现一致变更使需求和实现一致变更使需求和实现一致变更使需求和实现一致 未受控及受控的需求变更未受控及受控的需求变更 需求文档需求文档V1V1需求文档需求文档V2V2系统实现系统实现V1V1系统实现系统实现V2V2需求变更需求变更需求的变更管理需求的变更管理59595 5、降低需求变更风险的策略、降低需求变更风险的策略 与用户充分沟通与用户充分沟通与用户共同明确确定的需求的意义与用户共同明确确定的需求的意义 项目开发工作项目开发工作项目开发组织项目开发组织用户用户*产品后续开产品后续开发工作的基础发工作的基础*产品维护工产品维护工作的重要参考作的重要参考*对用户的承诺对用户的承诺*关系到项目开发工作的关系到项目开发工作的投入、交付期和产品质量投入、交付期和产品质量*关系到能否如期关系到能否如期获得所需的产品获得所需的产品*作为合同的附件，关系到双方的权益作为合同的附件，关系到双方的权益*是产品验收的依据是产品验收的依据向用户说明需求不确切或频繁变更对开发工作的冲击向用户说明需求不确切或频繁变更对开发工作的冲击使用户理解过多变更最终对用户不利使用户理解过多变更最终对用户不利 需求的变更管理需求的变更管理6060 与用户共同确定需求，作为合同附件，与用户共同确定需求，作为合同附件，签字生效签字生效 合同中含有对需求变更的条款合同中含有对需求变更的条款 采用原型方法开发，或螺旋模型开发采用原型方法开发，或螺旋模型开发 项目计划中适当留有余地（时间进度、人力投入、项目计划中适当留有余地（时间进度、人力投入、费用等）费用等）严格实施变更控制严格实施变更控制 需求的变更管理需求的变更管理61616 6、需求变更控制要求、需求变更控制要求 变更控制的策略变更控制的策略所有需求变更必须遵循需求变更控制规程实施变更。所有需求变更必须遵循需求变更控制规程实施变更。需求变更提出后是否被接受，应由专门的组织需求变更提出后是否被接受，应由专门的组织变变 更更控控制制委委员员会会（CCBCCBChange Change Control Control BoardBoard）审审查查决决定。定。不得以任何理由删除和修改需求变更的原始文件。不得以任何理由删除和修改需求变更的原始文件。应将已接受的需求变更通知到所有相关人员。应将已接受的需求变更通知到所有相关人员。已接受的需求变更应能追溯到批准的变更请求。已接受的需求变更应能追溯到批准的变更请求。对项目的需求赋予状态属性，以利于需求变更的控制。对项目的需求赋予状态属性，以利于需求变更的控制。需求的变更管理需求的变更管理6262需求变更影响的控制需求变更影响的控制由于分配需求的变更导致软件计划、工作产由于分配需求的变更导致软件计划、工作产品和活动的变更，都应对其作：品和活动的变更，都应对其作：识别识别评价评价风险分析风险分析编制文档编制文档制定计划制定计划传达给受影响的小组和人员传达给受影响的小组和人员跟踪直至结束跟踪直至结束需求的变更管理需求的变更管理6363需求的变更管理需求的变更管理变更管理过程变更管理过程变更管理过程变更管理过程变更控制的步骤变更控制的步骤I.I.提出变更请求提出变更请求II.II.审理变更请求，进行变更影响评估。评估内容审理变更请求，进行变更影响评估。评估内容包括：包括：变更所需人力投入变更所需人力投入变更对原计划安排的影响变更对原计划安排的影响估计变更引起的成本增加估计变更引起的成本增加III.III.批准变更请求批准变更请求IV.IV.取得用户的认可取得用户的认可V.V.修订项目计划修订项目计划VI.VI.实施变更实施变更VII.VII.验证变更验证变更 6464需求的变更管理（案例）项项目名称目名称移移动协动协同服同服务务支撑平台支撑平台变变更更请请求号求号V1.0变变更状更状态态申请/接受/拒绝/关闭申申请请人人刘波申申请请日期日期2004.4.10审审核人核人王卫红审审核日期核日期2004.4.12变变更更负责负责人人刘波完成日期完成日期2004.4.15变变更更说说明明1.修改原系统中采用的手机端与服务器通信采用的http协议为tcp协议；2.抛弃原系统中采用的摩托罗拉专用类库，采用sun的通用J2ME通用类库。3.将原系统中采用的CLDC1.0，MIDP1.0改为CLDC1.1和MIDP2.0。变变更必要性分析更必要性分析1.通信协议采用tcp协议，可增强手机端与服务器的交互性。2.采用sun的通用类库，可以增加系统的可用性。3.采用新版本的CLDC和MIDP可进一步方便程序开发。验证负责验证负责人人施铮验证验证日期日期2004.4.15需求变更请求表需求变更请求表需求的状态需求的状态需求要考虑的属性：需求要考虑的属性：l需求的创建时间l需求的版本l需求的创建者l需求的批准者l需求状态l需求的原因或根据l需求涉及的子系统l需求涉及的产品版本l需求的验证方式或测试标准l需求的优先级l需求的稳定性6767需求的状态需求的状态l已建议已建议：需求已经被有权提出需求的人所建议。：需求已经被有权提出需求的人所建议。l已批准已批准：需求已经被分析，估计了其对项目其余部分：需求已经被分析，估计了其对项目其余部分的影响；已经用确定的产品版本号或创建编号分配倒的影响；已经用确定的产品版本号或创建编号分配倒相关的基线中；软件开发团队已经同意实现它。相关的基线中；软件开发团队已经同意实现它。l已拒绝已拒绝：需求已经有人提出，但被拒绝了。拒绝的需：需求已经有人提出，但被拒绝了。拒绝的需求被列出的目的是因为它有可能被再次提出。求被列出的目的是因为它有可能被再次提出。l已设计已设计：已经完成了需求的设计和评审。：已经完成了需求的设计和评审。l已实现已实现：已经完成了需求功能代码的设计、编写和单：已经完成了需求功能代码的设计、编写和单元测试。元测试。l已验证已验证：已经使用某种方法验证了实现的需求，需求：已经使用某种方法验证了实现的需求，需求能够达到预期的效果，此时认为需求已经完成。能够达到预期的效果，此时认为需求已经完成。l已交付已交付：需求完成后，已经交付用户进行使用。：需求完成后，已经交付用户进行使用。l已删除已删除：计划的需求已经从基线中删除，但需要给出：计划的需求已经从基线中删除，但需要给出做出删除决定的人员及删除的原因。做出删除决定的人员及删除的原因。6868需求状态的变迁需求状态的变迁已建议已建议已批准已批准已删除已删除提出需求需求分析并被接受需求的设计和评审已设计已设计已实现已实现已验证已验证已交付已交付需求功能代码的设计、编写和单元测试已验证需求能够达到预期的效果交付用户使用从基线中删除从基线中删除从基线中删除已拒绝已拒绝被拒绝6969需求文档版本控制需求文档版本控制 需求文档的版本控制就是保证软件项目干需求文档的版本控制就是保证软件项目干系人得到最新版本的需求文档和记录需求的全系人得到最新版本的需求文档和记录需求的全部历史版本。做好需求文档必须保证以下几点：部历史版本。做好需求文档必须保证以下几点：统一确定需求文档的每个版本，保证每个成员都能得统一确定需求文档的每个版本，保证每个成员都能得到当前最新的需求文档版本到当前最新的需求文档版本清楚地将变更写成文档，并及时通知到项目干系人清楚地将变更写成文档，并及时通知到项目干系人为尽量减少困惑、冲突、误传，应只允许指定的负责为尽量减少困惑、冲突、误传，应只允许指定的负责人来更新需求文档人来更新需求文档7070需求的可跟踪性管理需求的可跟踪性管理l在软件能力成熟度模型在软件能力成熟度模型CMMCMM三级中要求软件团队必须具三级中要求软件团队必须具备需求跟踪的能力，即备需求跟踪的能力，即“在软件工作产品之间，维护在软件工作产品之间，维护一致性。工作产品包括软件计划，过程描述，分配需一致性。工作产品包括软件计划，过程描述，分配需求，软件需求，软件设计，代码，测试计划，以及测求，软件需求，软件设计，代码，测试计划，以及测试过程。试过程。”l目的：目的：建立和维护从用户需求开始到测试之间的一致性与建立和维护从用户需求开始到测试之间的一致性与完整性完整性确保所有的实现都以用户需求为基础，而实现的需确保所有的实现都以用户需求为基础，而实现的需求也全部覆盖了预期的需求求也全部覆盖了预期的需求确保所有的输出与用户需求的符合性确保所有的输出与用户需求的符合性使每一项需求前后继承关系的脉络清晰可见使每一项需求前后继承关系的脉络清晰可见7171需求的可跟踪性管理需求的可跟踪性管理l原因：原因：随着开发工作的进展需求将逐步扩展和演化随着开发工作的进展需求将逐步扩展和演化各个开发阶段的工作产品之间存在的继承关系，没各个开发阶段的工作产品之间存在的继承关系，没有一个需求表述是孤立存在的有一个需求表述是孤立存在的团队为了确定变更带来的影响，保证系统符合预期，团队为了确定变更带来的影响，保证系统符合预期，就必须理解、记录并维护这些可追踪性关系。就必须理解、记录并维护这些可追踪性关系。7272需求的可跟踪性管理需求的可跟踪性管理可追溯性信息：可追溯性信息：l 源可追溯性源可追溯性信息信息:用来说明连接需求到提出需求的项目干系用来说明连接需求到提出需求的项目干系人和产生需求的原因。当需求变更发生的时候，该信息用来发人和产生需求的原因。当需求变更发生的时候，该信息用来发现项目干系人以便能与他们商讨这些变更事宜。现项目干系人以便能与他们商讨这些变更事宜。l需求可追溯性需求可追溯性信息：用来说明连接需求文档中彼此依赖的需信息：用来说明连接需求文档中彼此依赖的需求。该信息用来评估一个需求变更会对其余多少需求产生影响求。该信息用来评估一个需求变更会对其余多少需求产生影响以及引发的需求变更的范围和程度。以及引发的需求变更的范围和程度。l设计可追溯性设计可追溯性信息：用来说明连接需求到其实现的设计