搜索
1CyberKeJi版权所有请勿翻印CMMIL2REQM需求管理过程域赛柏科技n初始级o已管理级p已定义级q定量管理级r优化级n初始级o已管理级p已定义级q定量管理级r优化级2CyberKeJi版权所有请勿翻印主题I需求开发与需求管理IIREQM的SG和SPsIIIREQM的GGs和GPsIV需求管理示例V小结VI参考材料3CyberKeJi版权所有请勿翻印#建立稳定的项目管理－成熟度L2•建立一个计划（ProjectPlanning）•跟踪这个计划（ProjectMonitoringandControl）•管理这个计划的输入（RequirementsManagement）•确保遵循这个计划(ProcessandProductQualityAssurance)•控制创建的产品(ConfigurationManagement)•适时收集基本的度量数据（MeasurementandAnalysis)•对供应商进行管理(SupplierAgreementManagement)4CyberKeJi版权所有请勿翻印#已管理级的特点•特点是：项目级。建立了基本的项目管理过程来跟踪成本、进度和功能特性，制定了必要的过程纪律，能重复早先类似项目取得的成功。•项目过程得到计划和执行，并遵循相应的方针•提供了适当的资源来执行过程，并分配了执行过程的职责•对执行过程的人进行培训•过程的工作产品得到了管理和控制•过程本身得到了监督、控制和评审，并得到了客观评价5CyberKeJi版权所有请勿翻印#过程域图示表示法项目计划信息库（如基线、计划等）获得对需求的理解过程活动过程域到过程域的连接信息流（处于运动中的信息）变更请求6CyberKeJi版权所有请勿翻印II#需求开发和需求管理需求相关活动需求开发需求管理需求调研需求分析需求定义需求确定管理需求实现管理需求变更管理7CyberKeJi版权所有请勿翻印#需求开发的目的•需求开发的目的：产生客户、产品及产品构件的需求，并且为这些需求的开发和理解进行所需要的分析8CyberKeJi版权所有请勿翻印#客户、产品及产品构件的需求－1市场昀终用户合作经理及管理部门客户可操作概念及场景产品及产品构件的需求客户功能分析导出的需求客户需求项目相关人员9CyberKeJi版权所有请勿翻印#客户、产品及产品构件的需求－2市场昀终用户合作经理及管理部门客户客户客户需求项目相关人员机械工程软件工程硬件工程分配给硬件等的产品需求其他组产品及产品构件的需求10CyberKeJi版权所有请勿翻印#需求开发语境图分析和确认需求确认后的需求开发客户需求客户需求开发产品需求产品需求11CyberKeJi版权所有请勿翻印需求管理的目的•需求管理的目的：管理项目的产品和产品构件的需求，并标识出这些需求与项目的计划和工作产品之间的不一致性12CyberKeJi版权所有请勿翻印需求要控制•将需求交给开发组之前，必须对需求进行评审并解决发现的问题•所有需求要文档化并且受到控制•所有相关的计划、活动及其它与生命周期相关的工作产品要与需求保持一致•在整个产品开发过程中，建立并维护可跟踪性13CyberKeJi版权所有请勿翻印#需求管理过程14CyberKeJi版权所有请勿翻印#需求管理过程的流程图15CyberKeJi版权所有请勿翻印#需求管理过程流示例需求管理及其软件开发生命周期概要软件需求初始的软件估计、计划和活动概要需求追踪用户需要业务目标项目约束边界（范围）批准计划阶段软件需求（委托/承诺）改版的软件估计、计划和活动软件需求（委托/承诺）追踪追踪Approval分析阶段控制变更重计划的软件估计、计划和活动追踪批准设计阶段和后续阶段变更追踪16CyberKeJi版权所有请勿翻印需求是构建系统的基础•构建任何系统，都是基于我们与客户共同确认的昀小需求，对于用户的需求了解得越是确切，需求的稳定性就越高。解决方案的不断演化，就是不断满足客户需求的过程（需求基线/变更）•对于大型系统，系统设计应从客户问题的专门知识入手，通过不断提炼的系统设计和软件设计，逐步增强对客户问题及相关知识的理解（需求确认）•如果上层设计选择正确，则很多低层设计将不会影响需求。当然，需求问题可能在任何开发阶段出现，此时必须在需求层次上恰当地解决，不能只是在设计或编码上修补了事（追溯性）17CyberKeJi版权所有请勿翻印需求管理的基本任务•项目要采取适当的步骤来确保管理已得到批准的需求集，以便支持项目的计划和执行的需要–获得对需求的理解：从被认可的需求提供者收集需求，并与他们共同评审，以便在将需求纳入项目计划之前，解决不明确的问题并排除误解–获得对需求的承诺：一旦需求提供者和需求接收者达成了协议，从项目参与者获得对需求的承诺–管理需求变更：随着项目进展，当计划、工作产品和需求之间出现不一致时，项目经理要更改需求或更改计划–维持需求的双向可跟踪性：需求管理要将需求的变更及其变更的理由文档化，并维持源需求与所有产品和产品构件的需求之间的双向可跟踪性18CyberKeJi版权所有请勿翻印#有哪几类需求?•功能需求•性能需求•界面需求•接口需求•资源需求（管理方面的需求）•潜在需求（potentialrequirements）等19CyberKeJi版权所有请勿翻印#Requirements与Specification？•生命周期分若干个阶段，每个阶段的输出是下一阶段的Requirements，每个阶段的输出是该阶段的Specification•看Specification是否满足Requirements：称Verification•看每个阶段的输出是否满足昀初的输入：称Validation•对第一阶段来讲：Verification也叫Validation•每个阶段既要进行Verification，也要进行Validation20CyberKeJi版权所有请勿翻印需求的双向可跟踪性－1•没有需求的可跟踪性，就不能有效地管理需求•一个需求是可跟踪的，其条件是当且仅当：–知道每个需求的源–知道为什么需要这个需求–知道哪些需求与它相关–知道需求如何与其它信息（如系统设计、实现及用户文档等）相关•可跟踪信息可用于发现哪些需求可能会受到需求变更的影响21CyberKeJi版权所有请勿翻印需求的双向可跟踪性－2•如果在系统实现过程中提出需求变更，应考虑以下情况：–变更对需求、系统设计及其实现影响的程度•如果在系统运行后提出需求变更，还应考虑以下情况：–该系统中有多少利益相关者受到此变更的影响22CyberKeJi版权所有请勿翻印需求的双向可跟踪性－3•在整个产品生命周期中，要捕捉所有需求和需求变更请求，并将他们放在配置管理之下（需求库）•在对项目计划、活动及工作产品执行需求变更请求的影响进行分析时，需求应该是可跟踪的（每项需求有唯一的标识符）•要生成一个需求跟踪矩阵，并可用于向前和向后的（双向）跟踪23CyberKeJi版权所有请勿翻印#需求跟踪矩阵•需求跟踪矩阵用于在各个生命周期阶段跟踪所有需求，确保每一项需求可以跟踪到实现该需求的设计、编码以及测试实现的测试用例•需求跟跟矩阵建立了从需求单元到设计单元、从设计单元到编码单元、从编码单元到测试用例的映射•通过跟踪，可以验证软件是否实现了所有需求以及软件是否对所有需求进行过测试，还可以在需求变更时分析变更带来的影响24CyberKeJi版权所有请勿翻印#前向跟踪和反向跟踪•存在两种类型的跟踪：–前向跟踪–后向跟踪•前向跟踪意味着看需求是否在生命周期的后期阶段（如设计和编码阶段）的输出元素中得到体现•后向跟踪则相反，它意味着后期各个阶段的输出元素满足何种需求。后向跟踪也经常意味着跟踪到原始需求的能力•前向跟踪实质上保证了软件满足需求。后向跟跟则在变更、回归测试等情况中更有用25CyberKeJi版权所有请勿翻印#需求跟踪矩阵的更新和维护•需求跟踪矩阵是随着开发过程逐步细化的，跟踪产品在开发过程中的转移。每当相关阶段结束时或需求变更时都要更新该矩阵，确保需求的前后跟踪•项目经理或指定专人负责更新和维护需求跟踪矩阵•维护矩阵时，需要进行完整性检查：–浏览矩阵中的需求数目与需求文档中的需求，确保矩阵中列出了所有的需求，没有遗漏–为确保矩阵中列出的所有程序在昀终的软件中都是必要的，并且没有冗余的代码，必须在矩阵中指出每个程序、类和其他单元–通过确保功能需求没有空白列来检查需求的实现。对其他需求，如果设计和程序列是空白的，需要仔细检查和验证这些需求对程序有没有直接的影响–对每个性能需求，都应该设计一些测试用例。使用矩阵，可以很容易检查测试用例是否适合检查该项性能需求–集成和系统测试计划可以和矩阵一起进行交叉检查，以此来保证需求的所有条款都包含在系统测试计划中26CyberKeJi版权所有请勿翻印#跟踪矩阵示例Component01,03,…Req.-02Component01,02,…Req.-01ComponentID1，ID2，…Req.ID详细设计概要设计需求27CyberKeJi版权所有请勿翻印#需求库示例03/01/200102/01/2001状态变更时间来源closeRel2.0adoptRel1.0adoptRel1.0opennew变更影响获取时间描述实现版本状态原始需求ID28CyberKeJi版权所有请勿翻印#需求必定会发生变更•在软件或系统的开发过程中，需求必定会发生变更，这一点无一例外•对于大型项目来说，说出完整的需求不仅仅是困难的，实际上是不可能的。除非以前做过类似的工作，现在只需要作微小的变更•软件或系统开发是一个学习过程，步伐宜小不宜大，有效的实践经验是采取渐进式的开发过程29CyberKeJi版权所有请勿翻印#需求必定会变更的原因•客户并不完全了解其需求，更不用说其他人•昀初的需求常常是不完善的，需要补充、删除和修改•必须与了解产品应用的人建立联系、共同工作，直到整个工作完成。系统越大越复杂，需要的应用领域知识就越多30CyberKeJi版权所有请勿翻印#需求变更的影响分析•增加、修改或删除需求时，要进行影响分析：–对开发进度的影响–对发布进度的影响–对人员安排的影响–对成本的影响–对现有约定（Commitment)的影响–变更引起的风险分析–对其他相关的工作产品的影响–等等•对变更进行影响分析时，要使用双向跟踪矩阵31CyberKeJi版权所有请勿翻印#对变更状态的跟踪10.14%52513-21668.45%43509-11357.50%38507-32246.10%31508-25334.14%21507-34621.59%8504-12510.00%05000000需求稳定性变更数总的需求数删除需求数修改需求数增加需求数报告周期500基线需求数•总的需求数=（基线需求数+增加的需求数-删除的需求数）•需求变更数=（增加的需求数+删除的需求数+修改的需求数）•需求稳定性=（需求变更数/基线需求数）32CyberKeJi版权所有请勿翻印#需求稳定性010020030040050060012345670.00%2.00%4.00%6.00%8.00%10.00%12.00%总的需求数变更数需求稳定性33CyberKeJi版权所有请勿翻印#按变更类型的需求稳定性-4-3-2-101234567报告周期012345增加需求数修改需求数删除需求数34CyberKeJi版权所有请勿翻印#需求变更要控制•在项目生命周期中，需求在不断进化，对需求变更必须进行控制–需求变更请求要受到控制：所有相关的人员在变更实施前，要评审变更请求，并对变更请求达成一致–对批准的需求变更要进行跟踪–对每个需求及其变更要记录，要维护其变更历史•初始采集的和/或导出的•批准的变更已经应用之后–应用的需求变更要与所有相关人员及时沟通35CyberKeJi版权所有请勿翻印#需求变更的控制示例变更请求软件经理系统测试软件工程系统工程软件质量保证软件配置管理，以及文档支持更改软件计划、工作产品和活动审批关闭请求变更的需求一致YSCMN变更完成36Cy