软件工程管理-需求管理部分

项目需求管理第三部分目录需求管理的概念需求变更版本控制需求状态需求跟踪需求评审需求工具需求管理的概念为什么要管理需求？这是Rational的标准开发流程图，从图中，我们可以看出，需求分析在启动和计划阶段，占有相当大的比例。需求管理存在的问题1、需求不总是显而易见的，而且它可来自各个方面。2、需求并不总是容易用文字明白无误地表达。3、存在不同种类的需求，其详细程度各不相同。4、如果不加以控制，需求的数量将难以管理。5、需求相互之间以及与流程的其他可交付工件之间以多种方式相关联。6、需求既非同等重要，处理的难度也不同。7、需求涉及众多相关利益责任方，这意味着需求要由跨职能的各组人员来管理。8、需求发生变更。9、需求可能对时间敏感。需求管理的原则-需求一定要分类管理-需求必须分优先级-需求必须文档化-需求一旦变化，必须对需求变更的影响进行评估-需求管理必须与软件工程其他活动紧密整合需求工程需求工程需求开发需求管理需求获取需求分析规格说明需求状态需求跟踪版本控制需求验证需求变更需求管理活动•Requirementsmanagementinvolves–Controllingchangestotherequirementsbaseline.–Keepingprojectplanscurrentwiththerequirements–Controllingversionsofbothindividualrequirementsandrequirementsdocuments–Trackingthestatusoftherequirementsinthebaseline–Managingthelogicallinksbetweenindividualrequirementsandotherprojectworkproducts需求管理活动Majorrequirementsmanagementactivities需求变更管理2.4.1需求变更与项目经理的责任时间紧迫压缩需求过程产品不满足需求变更需求维护工作量增加项目资源恶化需求过程的恶性循环可怕的噩梦需求变更的原因多种多样，现在分析，经常发生的主要有以下几种：（1）因竞争、成本等因素，工期已经确定且极不合理：（2）用户在需求期提不出需求、或用户的需求不明确：（3）项目组对业务不熟悉、或者没有与用户密切结合、需求分析工作不细致：（4）项目组没有很好地实施需求管理。需求变更——项目经理的责任软件需求管理不能解决不合理工期的问题。很好的需求管理，可以帮助项目组按照合理的工期，达到预期的时间计划目标，减少因需求失控，造成的时间延误。软件需求管理也不能解决用户需求不明确的问题。需求管理可以帮助项目组有条理地收集用户需求、处理用户需求、在实施过程中保证需求获得满足。软件需求管理更不能帮助项目组熟悉特定的业务，这是项目组系统分析师的职责。项目经理应当意识到，项目组的系统分析师对用户业务不能尽快地熟悉起来，他有责任调整项目组或向公司更高层提出解决问题的办法。在科学的、经验的、用户和项目组都能接受的项目预期时间内，项目组能比较充分地获取用户的需求的前提下，软件项目经理的需求变更管理可以使需求的意外变化，在可控、可接受的范围内，使项目计划、成本、质量不受到负面的影响，或使影响在可容忍的范围内。这就是项目经理需求变更管理的职责和目标。2.4.2需求变更控制活动6大需求变更控制活动（1）确定需求变更控制过程：确定需求变更的选择、分析、决策、记录的过程，所有需求的变更，都要在选择、分析、决策、记录环节上，受到机制和责任的保证。（2）建立需求变更控制委员会：组织公司、项目组内部和用户利益和风险承担人员，成立需求变更控制委员会，由他们来决定要变更哪些需求，是否在项目范围之内（包括：项目范围和合同范围。因为有时，在项目范围，但不在合同范围，需要项目进行二期合同开发），评估变更的波及，最后决定变更是可以接受，还是放弃。对变更的需求设置优先级、制定版本规定等。需求变更——6大需求变更控制活动（3）进行需求变更影响分析：波及分析有利于对需求变更要求，进行更深入、精确的理解，帮助变更控制委员会做出科学的决策。波及分析还可以帮助项目组对现有系统做出合理的、有前瞻性的调整，使面对日后新的需求变更，有充足的技术准备。波及分析完全依赖于需求的跟踪能力。没有需求形式化记录、没有需求跟踪链，就没有波及分析的可能。如果有，也是主观的、非定量的。由此对项目计划、成本、质量控制的影响分析，其可信度是有疑问的。系统分析师和架构师应评估变更对系统技术实现的影响。项目经理应根据新需求，明确相关任务，评估新的工作量和相应的要求变化。新需求不但导致分析、编码、测试的工作量增加，项目管理有关的各环节（需求管理、计划管理、成本管理、配置管理、质量管理等）都会有所变化。在需求变更评估分析中，也要做需求稳定性评估。频繁地需求变更，应该超出了需求变化的范围。项目经理要考虑项目组织管理方面，是不是发生了什么问题。需求变更——6大需求变更控制活动（4）跟踪所有受需求变更影响的工作产品：当确定某一需求发生变更时，根据需求跟踪矩阵，找到与变更需求有关的各层、各环节需求项。例如：涉及需求项的设计模型、代码模块、测试用例等。这些部分全部必须做相应的修改。依据需求跟踪矩阵，可以完整地追踪到需求变更所影响到的所有地方，可以不会发生遗漏，而产生系统BUG，或产品缺陷。甚至包括对软件产品本身以外的影响，如：因需求变更，版本控制没有相应的记录、产品使用手册没有做相应修改等。因为需求变更，需求状态记录应相应地发生变化。每一条记录，反映了需求的现实情况。（5）调整需求基线：需求变化以后，需求变更控制委员会要决定是否调整需求基线。新需求是反映为基线的调整，还是版本的变化。基线是产品的标准，基线变化可以作为产品标准的变化，也可以理解为将发行一个新版本的产品。需求变更——6大需求变更控制活动但是，版本并不一定就是新产品。因为，当产品面对不同地区、不同用户群的时候，也可以确定不同的版本。因此，需求变更控制委员会要做的工作，是对新需求，决定是全面升版，还是局部更改。是基线变化，还是个别版本变化。有时，这是一个比较难于做出的决定，他依赖于对新需求的分析，评估它对市场、用户和产品本身的影响。（6）维护需求变更记录和文档，并沟通：决定变更基线或提升版本以后，就要做好记录，修改相应的文档。变更记录要记录变更原因、变更内容、变更影响、变更实现过程、其他相应变更等。变更记录越完整，对于追溯，甚至以后可能发生的回退，就越有帮助。有一些版本控制工具，可以帮助项目经理来做到记录相应的信息。State-transitiondiagramforachangerequestMeasuringChangeActivitySamplechartofrequirementschangeactivityMeasuringChangeActivitySamplechartofrequirementchangeorigins•经验一：相互协作–很难想像遭到用户抵制的项目能够成功。–在讨论需求时，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。–即使用户提出了在开发人员看来过分的要求，也应该仔细分析原因，积极提出可行的替代方案。•掌握变更管理的核心要旨：–需求变更控制一般要经过“定基线、变更申请、变更评估、决策、实施、验证”这六大步骤。•经验二：充分交流–需求变更管理的过程很大程度上就是用户与开发人员的交流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。同时，软件开发人员应该向用户说明，进入设计阶段以后，再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。•经验三：安排专职人员负责需求变更管理–有时开发任务较重，开发人员容易陷入开发工作中而忽略了与用户的随时沟通，因此需要一名专职的需求变更管理人员负责与用户及时交流。•经验四：合同约束–需求变更给软件开发带来的影响有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程。–诸如“诸如，需求发布后，变更本着双方友好协商的原则，确定协商流程”•经验五：区别对待的原则–学会识别变更的类型、层次•业务需求变更•用户需求变更•软件需求变更–随着开发进展，有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。–遇到这种情况，开发人员可以向用户说明，项目的启动是以最初的基本需求作为开发前提的，如果大量增加新的需求(虽然用户认为是细化需求，但实际上是增加了工作量的新需求)，会使项目不能按时完成。–如果用户坚持实施新需求，可以建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。同时，还要注意控制新需求提出的频率。•经验六：选用适当的开发模型–采用建立原型的开发模型比较适合需求不明确的开发项目。–开发人员先根据用户对需求的说明建立一个系统原型，再与用户沟通。–一般用户看到一些实际的东西后，对需求会有更为详细的解释，开发人员可根据用户的说明进一步完善系统原型。–这个过程重复几次后，系统原型逐渐向最终的用户需求靠拢，从根本上减少需求变更的出现。–目前业界较为流行的迭代式开发方法对工期紧迫的项目的需求变更控制很有成效。•经验七：加强前期的用户参与力度–诸如，用户参与需求评审。作为需求的提出者，用户理所当然是最具权威的发言人之一。实际上，在需求评审过程中，用户往往能提出许多有价值的意见。同时，这也是由用户对需求进行最后确认的机会，可以有效减少需求变更的发生。需求版本控制RequirementsVersionControl•Versioncontrol是管理需求规格说明和项目其他文档所必须的活动•需求文档的每个版本必循唯一确认。不存在二义性RequirementsVersionControl(cont’d)•每个下发的需求文档应该包括:arevisionhistorythatidentifiesthechangesmade,thedateofeachchange,theindividualwhomadethechange,andthereasonforeachchange.RequirementsVersionControl(cont’d)•最简单的版本控制的机制是–通过标准协定或流程来标注每个SRS的修订版。•最好的版本控制的方式是–通过需求管理工具来保存需求信息在数据库中，并跟踪。需求状态跟踪需求属性•可以为需求和其他相关的模型元素设置属性，以便于追踪它们的一般状态。每个项目都可能有其特定的属性集，而且所追踪元素的类型不同，属性也会有所不同。•每个需求类型都有一组唯一属性，与在该级别上定义的每个需求相关联。•对于已确定的每一需求类型，都应列出将要使用的属性，并简要解释其含义。需求属性•需求类型和每种类型的属性是为整个项目定义的，由此确保了团队上下使用的一致性。•需求的多维性以及不同类型的需求（每种类型都有自己的属性）对于组织大量需求和管理项目的整体规模来说是不可或缺的。•为每个需求类型提供一个矩阵，其中一条轴上列出需求，而另一个轴上列出所有属性。对于每个需求，显示其各自属性的状态。需求类型的属性•1状态•2优先级•3工作量•4风险•5稳定性•6目标发布版•7职责分配•8原因需求属性的作用•定义和更新需求属性值是需求管理成本的一部分。•精心挑选属性最小子集能帮助你有效管理项目。需求属性的作用•如果为项目需求选择了适当的属性和可追踪性，将有助于：–评估需求变更对项目的影响–评估测试故障对需求的影响（例如：若测试出现故障，则需求将得不到满足）–管理项目的规模–核实通过实施系统所有需求都已实现–核实应用程序仅仅执行了预期的任务–管理变更1.需求状态•在整个开发过程中,跟踪每个需求的状态是需求管理的一个重要方面。•在每一可能的状态类别中,如果你周期性地报告各状态类别在整个需求