第8章软件项目需求与变更管理ppt课件

1、软件工程管理 软件工程需求管理概述 1软件工程义务分解 2第8章 软件工程需求与变卦管理3软件需求的变卦控制 学习目的掌握软件需求的概念熟习需求管理的方法与过程掌握义务分解的方法与步骤掌握需求确认、变卦控制和需求跟踪的方法和过程第8章 软件工程需求与变卦管理Hot Tip软件需求定义 需求是来源于用户调查，即客户的需求。 需求分析是指软件分析人员经过研讨用户在软件问题上的需求志愿，分析出软件系统的功能、性能、数据等诸方面应该到达的目的，从而获得有关软件的需求规格定义的过程。 8 .1 软件工程需求管理概述Hot Tip软件需求定义1用户需求特点： 1用户需求直接来源于用户 2用户需求需求以文档

2、的方式提供应用户审查3可以把用户需求了解为用户对软件的合理恳求4用户需求主要是为用户方的管理层、用户方的技术代表、操作者以及开发方的高层技术人员撰写的8 .1 软件工程需求管理概述Hot Tip2系统需求1功能需求全面性一致性 可了解可维护可追踪等8 .1 软件工程需求管理概述2非功能性需求性能需求、可靠性、可用性需求、系统平安以及系统对开发过程、时间、资源等方面的约束和规范关怀系统的整体特性 3数据要求Hot Tip3需求规格阐明书的写作规范1明晰 2完好 3一致 4可测试 8 .1 软件工程需求管理概述需求的重要性需求是业务的根源，需求任务的优劣对业务影响最大。就像一条河流，假设源头被污染

3、了，那么整条河流也就被污染了。8 .1 软件工程需求管理概述需求是缺陷主要来源错误定位费用分析James Martin：超越50%的缺陷由不完善的、不正确的、不准确的和/或不明确的需求所引起James Martin：80%以上的用于定位业务错误的费用是基于业务系统需求定义的错误8 .1 软件工程需求管理概述一个小故事如何练就需求分析的火眼金晴？ 5W + 1H + 8C 5W就是 Who、When、Where、What、WhyWhy是关键1H就是 How 需求本身的流程8C指的是8个约束和限制，即8个Constraints：包括性能Performance、本钱Cost、时间Time、可靠性Re

4、liability、平安性Security、合规性Compliance、技术性Technology、兼容性CompatibilityDFX-Design for X 面向产品生命周期各环节的设计。DFC、DFS明确的需求是工程的根底1需求的生命周期：需求产生变化、内部、外部需求认识现存、潜在、超前、前景分析需求表达：1、让提出需求的人尽能够清楚地阐明他们的需求；2、对需求提出一系列问题：明确的需求是工程的根底明确的需求是工程的根底2？提出需求的人是如何描画需求的？需求真实吗，是真正需求还是外表景象？我们能满足这个需求吗，其他人能满足吗，是不是真的有处理方法？需求重要吗，值得去满足他吗 ？满足需

5、求的关键问题在那里，会不会有新的需求产生，还要进一步满足其他需求吗，新的需求能取代目前这个需求吗？需求直接涉及什么人，他们以为这是一个必要的需求吗，满族足需求后对他们有什么影响，他们的反映会怎样样？需求对机构的影响是什么，对我的影响是什么明确的需求是工程的根底明确的需求是工程的根底33、作一些必要的研讨任务，更好地了解需求4、根据以上三步得出结论，尽能够清楚地描画这个需求5、听听用户对他的论述的反映，并作适当修正。功能和技术要求1、把需求变胜利能要求；2、功能要求应描画工程最终交付产品的特征3、技术要求根据功能要求产生4、功能要求运用日常言语陈说清楚明确的需求是工程的根底定义需求时的问题1模糊

6、的需求：1、不断变化的需求人员变化、预算变化、技术变化、商业环境变化2、误解需求我说不清楚我所需求的是什么，但我见到东西时就会知道觉得会随环境变化过早作出结论截断需求表达过程需求分析需求耐心和自我控制与真正的用户讨论需求定义需求时的问题定义需求时的问题2多种用户，多种需求确定优先级，即需求层次曲解用户的需求需求镀金对用户的需求有选择的过滤包办替代定义需求时的问题 需求和目的 根本需求: 工程实施范围、质量要求、 利润或本钱目的、时间目的以及必需满 足的法规要求等 期望要求: 如一种新产品性能之外的外形、运用温馨Hot Tip需求管理1需求管理复杂性分析需求的描画问题 需求的完备程度问题 需求开

7、发的工期问题 需求的细致程度问题 需求的变化问题 8 .1 软件工程需求管理概述Hot Tip需求管理2需求管理的根本原那么需求管理必需与需求工程的其它活动严密整合 需求必需是文档化的、正确的、最新的、可管理的、可了解的只需需求变化了，需求变卦的影响就必需被评价 需求必需分优先级 需求一定要分类管理 8 .1 软件工程需求管理概述Hot Tip3需求管理的方法确定需求变卦控制过程进展需求变卦影响分析建立需求基准版本和需求控制版本文档维护需求变卦的历史记录跟踪每项需求的形状衡量需求稳定性8 .1 软件工程需求管理概述Hot Tip需求管理过程1定义需求2需求确认3建立需求形状4需求评审 评判需求

8、优劣的主要目的有：正确性、明晰性、无二义性、一致性、必要性、完好性、可实现性、可验证性、可测性。 8 .1 软件工程需求管理概述Hot Tip需求管理过程5需求承诺6需求跟踪正向跟踪：以用户需求为切入点，检查中的每个需求能否都能在后继任务产品中找到对应点。逆向跟踪：检查设计文档、代码、测试用例等任务产品能否都能在中找到出处。 7需求变卦控制8 .1 软件工程需求管理概述 需求分析在工程中的位置用户/系统业务管理者初始需求变卦的需求获取,分析,定义,验证需求控制需求变卦需求规格阐明工程环境需求开发需求管理需求工程活动综合关系三要点：需求确认、需求变卦控制、需求跟踪需求管理的三要点 需求管理的目的

9、是在用户与开发方之间建立对需求的共同了解，维护需求与任务成果的一致性，并控制需求的变卦。 需求工程贯穿开发全过程设计需求架构设计系统规格软件需求硬件需求质量属性DFX业务需求用户需求内部需求客户要求功能需求非功能需求规范约束书面规范现实规范Hot Tip任务分解构造 工程的分解构培育是将工程的产品或效力、组织、过程这3种不同的构造综合为工程分解构造的过程，也就是给工程的组织人员分派各自角色和义务的过程。基于成果或功能的分解方法，以完成该工程应该交付的成果为导向，确定相关的义务、任务、活动和要素。基于流程的分解方法，以完成该工程所应阅历的流程为导向，确定相关的义务、任务、活动和要素。8 .2 软

10、件工程义务分解Hot Tip任务分解构造1图表方式分解层次与构造 8 .2 软件工程义务分解Hot Tip 任务包是完成一项详细任务所要求的一个特定的、可确定的、可交付以及独立的任务包，可为工程控制提供充分而适宜的管理信息。 WBS编码设计 8 .2 软件工程义务分解Hot Tip2清单方式需求分析方案流程优化编写需求阐明书编写需求规格词汇表绘制业务流程笼统业务类建立数据模型将需求分析图示参与规格文档需求规格测试需求规格确认8 .2 软件工程义务分解Hot Tip义务分解过程1分解步骤1确认并分解工程的主要组成要素。2确定分解规范3确认分解能否详细，分解结果能否可以作为费用和时间估计的规范，明

11、确责任。4确定工程交付成果。5验证分解正确性，验证分解正确性后，建立一套编号系统。8 .2 软件工程义务分解Hot Tip义务分解过程2分解的规范:普通不能采用双重规范。选择一种工程分解规范之后，在分解过程中应该一致运用此规范，防止因运用不同规范而导致的混乱。 3分解结果的检验核实分解的正确性：更低层次的细目能否必要和充分？最底层要素能否有反复？每个细目都有明确的、完好的定义吗？能否每个细目可以进展适当的估算？谁能担负起完成这个义务？8 .2 软件工程义务分解Hot Tip4义务分解的本卷须知留意搜集与工程相关的一切信息。义务分解结果必需有利于责任分配。最底层的任务包普通要有全面、详细和明确的

12、文字阐明，并聚集编制成工程任务分解构造词典。防止不用要的过细，最好不要超越7层。按照软件工程的平均规模来说，引荐义务分解时至少分解到一周的任务量40小时。8 .2 软件工程义务分解Hot Tip5责任分配及本钱分解8 .2 软件工程义务分解WBS编号预算责任者WBS编号预算责任者10.1张明3.30.15李立20.46李立3.40.1李立30. 46张明、李立3.50.02张明3.10.04张明40.08万风3.20.15李立50.1张明Hot Tip需求确认 需求确认是指开发方和用户共同对需求文档进展评审，双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。8 .3 软件需求确实认

13、、变卦控制和跟踪工程开发面临的实践问题8 .3 软件需求确实认、变卦控制和跟踪需求确认工程开发面临的实践问题8 .3 软件需求确实认、变卦控制和跟踪需求确认工程开发面临的实践问题8 .3 软件需求确实认、变卦控制和跟踪需求确认需求验证的目的和义务需求确认的目的和义务需求验证的目的就是要确保软件需求具有良好的特性如完好性，正确性等。需求验证包含的活动满足性功能需求能否满足需求称心性非功能需求能否称心明确及含蓄的需求(失败)、(胜利)共识行能否能共同了解可行性技术能否可行明晰性信息能否存在含混性8 .3 软件需求确实认、变卦控制和跟踪需求确认需求确认的方法：1、为需求进展正式评审2、为需求写测试用

14、例3、用检查单识别常见问题4、为需求设定优先级5、最后：构成总体共识8 .3 软件需求确实认、变卦控制和跟踪需求确认1、为需求进展正式评审1、为需求进展正式评审8 .3 软件需求确实认、变卦控制和跟踪需求确认需求评审做不好的后果： 需求变卦 需求不明确 需求不可测 需求不可实现 导致后续任务难于开展或经常出现变卦 由于需求未能得到有效管理， 在最终工程验收过程中出现了令人不愉快的情况，实践开发的软件没能完全反映用户的需求，导致用户不称心，工程延期。8 .3 软件需求确实认、变卦控制和跟踪需求确认做不好的后果如何进展需求评审1、为需求进展正式评审 如何进展需求评审 参与需求分析和评审的人员的管理

15、 软件需求文档的管理 需求分析过程的管理 需求变卦的管理8 .3 软件需求确实认、变卦控制和跟踪例1：“产品应在不少于每秒的正常周期内提供形状信息。分析：这个需求是不完好的： 形状信息是什么，如何显示给用户。这个需求有几处模糊。我们在议论产品的哪部分？形状信息间隔真的假定为不少于秒？，甚者每10年显示一条新的形状信息也可以？也许它的意图是音讯间隔不应超越秒，那么1毫秒是不是太短？“每这个词导致了不确定性。问题的后果，就是需求的不可证明。8 .3 软件需求确实认、变卦控制和跟踪例1需求：后台义务管理器因以误差上下不超越10秒的秒间隔，在用户界面的指定位置显示形状信息；假设后台进程处置正常，那么应

16、该显示义务已完成的百分数/比；义务完成时，应显示相关的信息；后台义务出错应该显示错误信息；为了测试和追踪，将需求分解多个子需求。使在构造和测试时，被易于分别执行。8 .3 软件需求确实认、变卦控制和跟踪例2：“产品应瞬间在文本中的显示和隐藏不可打印字符间切换 计算机在瞬间不能做任何事，所以这个需求不真实可行。它的不完好性表如今没有声明触发形状切换的条件。软件要在某些条件下更改本人？或者用户为了模拟更改要做一些什么动作？而且，在文档中改动显示的范围是多大：选中的文本？整个的文档，或其他的？这也是个模模糊的问题。不可打印字符和隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的

17、不可证明。8 .3 软件需求确实认、变卦控制和跟踪例2需求：用户可以在一个由特定触发条件激活处于编辑的文档中在显示和隐藏一切HTML标志间切换。如今就很清楚，不可打印字符是HTML标志。由于没有定义触发条件，需求对设计没有约束力。只需设计人员选定了触发条件后，他才干编写测实验证触发的正确操作。8 .3 软件需求确实认、变卦控制和跟踪例3：“HTML分析器可以产生HTML标志错误报告，协助HTML入门者快速处理错误。单词“快速使其模糊，没有加进错误报告的定义也是不完好的。我不知道，他怎样验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速处理错误？8 .3 软件需求确实认、变卦

18、控制和跟踪例3需求：“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描画。假设没有错误，就不会产生错误报告。如今我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，那么留由设计人员决议。我们还指定了一个例外：假设没有发现错误，不产生错误报告。8 .3 软件需求确实认、变卦控制和跟踪 练习：以下描画哪些属于不准确的用户需求描画？假设不准确，应如何矫正？ 1系统应表现出良好的呼应速度。 不准确，应指出详细工程和呼应时间。 2系统必需用菜单驱动。 “必需不准确，因系统还可以用其他方式驱动。 3在数据录入界面，应该有10个按钮。 不准确，因

19、过于细致，限制了设计的自在度。 4系统运转时占用的内存不得超越200M。 仅是一个约束条件。 5电梯应平稳运转。 不准确，应指出加速、减速、运转速度的大小。 6即使系统解体，也不能损坏用户数据。 不准确，因这是一个难以保证的“用户需求。8 .3 软件需求确实认、变卦控制和跟踪2、为需求写测试用例2、为需求写测试用例目的是识别需求的含混性 以需求为根底，并视其为黑盒子，然后编写测试用例。 要覆盖需求常见的测试点入口条件出口条件主事件流可选事件流非功能需求8 .3 软件需求确实认、变卦控制和跟踪3、用检查单识别常见问题4、为需求设定优先级4、为需求设定优先级支持工程分期交付支持需求取舍之道支持需求

20、的方式化8 .3 软件需求确实认、变卦控制和跟踪 为什么要设定需求的优先级软件开发受时间、本钱、质量等多种资源的限制，同时软件开发的高不确定性，导致 需求在工程终了时往往难以被全部实现。因此需求在需求开发阶段，对需求进展分解，设定优先级，先实现优先级别较高的需求，有助于维护工程收益和提高工程胜利率。基于价值、费用和风险的优先级设定费用方法Cost：价值方法Value：风险方法Risk：最小费用优先原那么最高价值优先原那么最低风险优先原那么 它们本质上从单一视角探寻适用规范来评价每个需求，并且计算出一个分值用于编排需求的优先级。 如何设定需求的优先级基于价值、费用和风险的优先级设定XXXXX%X

21、XX%XXX%XXXXn. XXXXX优先级 风险% 相对风险 费用% 相对费用 价值% 总价值 相对损失 相对利润 需求/特性XXXXX%XXX%XXX%XXXX1. XXXXX总计XXXX相对权值在一个平面中列出要设定优先级的一切需求、特性或运用实例；在这个例子中，我们将运用特性来设定优先级。一切项都必需在同一笼统级别上；不要把个人需求与产品特性混合在一同。假设某些特性有逻辑上的联络例如，只需包括特性A的情况下才干实现特性B那么在分析中只需列出驱动特性就可以了。这种模型在其有效范围内可以包容几十种特性。假设他有更多的项，那么就把相关的特性归成一类，并建立一个可管理的初始化列表。假设他需求的

22、话，可以在更详细的级别上进展第二轮分析。估计每一个特性提供应客户或业务的相关利益，并用1 9划分等级，1代表可忽略的利益，9代表最大的价值。这些利益等级阐明了与产品的业务需求的一致性。客户代表是判别这些利益的最正确人选。在缺省情况下，利润和损失的权值是相等的，作为一种精化，他可以更改这两个要素的相对权值。估计出假设没有把应该实现的特性包括到产品中，将会给客户或业务上带来的损失。运用1 9划分等级，这里1代表根本无损失， 9代表严重损失。总价值相对利润相对损失价值%=总价值/总计价值100 根据需求的复杂度，所需求的用户界面的实现情况、重用当前代码的潜在才干、所需求的测试量和文档等等，开发者可以

23、估算出费用。 估计实现每个特性的相对费用，运用1低 9高划分等级。平面图将计算出由每一个特性所构成的总费用的百分比。开发者应该要估计出与每个特性相关的技术或风险相对程度，并利用1 9划分等级。1级表示他可以轻而易举地实现编程，而9级表示需求极大地关注其可行性、缺乏具有专门知识的人员，或者运用不成熟或不熟习的工具和技术。平面图将计算出每个特性所产生的风险百分比。在缺省情况下，利润损失，费用和风险的权值是相等的，但是他可以在平面图中调整其权值。假设他无需在模型中思索风险，就把风险的权值设为0。 价值%优先级费用%费用权值风险%风险权值基于价值、费用和风险的优先级设定优先级设定演示相对权值2110.

24、5 需求/ 特性相对利润 相对损失 总价值 价值% 相对费用 费用% 相对风险 风险% 优先级 UC153138.42813.01.345UC2972516.2511.939.10.987UC355159.737.126.10.957UC42153.212.413.00.833UC5491711.049.5412.10.708UC643117.137.126.10.702UC762149.149.539.10.646UC8982616.9716.78220.586UC934106.549.526.10.517UC1074811.7921.4721.20.365总计544615410042100

25、33100迭代1 BaseLine=UC1-3迭代2BaseLine=UC4-6迭代3 BaseLine=UC7-95、最后：构成总体共识 本需求文档建立在双方对需求的共同了解根底上，我赞同后续的开发任务根据该需求文档开展。假设需求发生变化，我们将按照“需求变卦控制规程执行。我明白，需求的变卦将导致双方重新协商本钱、资源和进度等。 甲方担任人签字 乙方担任人签字8 .3 软件需求确实认、变卦控制和跟踪1、什么是需求变卦？需求变卦控制、范围控制初始需求变卦的需求对问题的初始了解对问题的新了解时间二、控制需求变卦8 .3 软件需求确实认、变卦控制和跟踪Hot Tip需求的变卦要经过出资者的认可,这

26、样才会对需求的变卦有本钱的概念，可以慎重地对待需求的变卦。小的需求变卦也要经过正规的需求管理流程，否那么会积少成多。准确的需求与范围定义并不会阻止需求的变卦。并非对需求定义的越细，越能防止需求的渐变，这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。由于需求的变化是永久的，并非由于需求细化了，它就不会变化了。8 .3 软件需求确实认、变卦控制和跟踪二、控制需求变卦受控的需求需求文档V1系统实现V1系统实现V2需求变卦二、控制需求变卦8 .3 软件需求确实认、变卦控制和跟踪Hot Tip2变卦控制过程1工程启动阶段的变卦预防2工程实施阶段的变卦控制3工程收尾阶段的总结控制 8 .3 软件

27、需求的变卦控制Hot Tip3、需求变卦处置流程 8 .3 软件需求的变卦控制受控的需求变卦需求文档V1需求文档V2系统实现V1系统实现V2需求变卦由CCB委员会裁定8 .3 软件需求确实认、变卦控制和跟踪CCB的解释CCB 变卦控制委员会(Change Control Board)CCB 是系统集成工程的一切者权益代表，负载裁定接受那些变卦。CCB由工程所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。CCB是决策机构，不是作业机构，通常CCB的任务是经过评审手段来决议工程能否能变卦，不提出变卦方案。 需求变卦恳求单我国变卦管理五级成熟度模型需求变卦案例分析面对客户的需求变卦，接受还

28、是回绝？在某公司的工程管理课堂上，小李，小王、小林等人正在七嘴八舌地议论纷纷。原来，大家正在讨论公司最近遇到的两个颇为有趣的工程。情况1：尽量满足用户需求据小王引见，这两个工程分别由两个工程经理来担任。其中，工程经理A属于“谦虚型，对于客户提出的问题，无论大小都给与处理，客户对此非常称心，然而，工程进度却拖得比较长，而且，客户总想把一切的问题都改完再说，工程曾经一再延期。情况2：严厉执行工程方案相比之下，工程经理B显得稍有些“盛气凌人，对于客户提出的问题，大多都不予理睬，客户对此不是很称心，不过，该工程的进度控制得比较好，根本可以按期完成工程。分析1 不太迁就用户小王：“对工程经理来说，本钱、

29、质量和时间是最为重要的三要素。与客户的关系当然很重要，但也要全盘思索工程的各要素。对于用户的要求，应该在有限的范围内给与处理，但不可以做出太大的牺牲。一味的迁就用户将会使整个工程失败。分析2 坚持原那么，适当调理用户关系小林：“当前，国内的工程普通情况下是由销售处面签单，再由工程经理接手后续的任务，因此客户关系多在事前曾经搞定。发生新的情况后，可以由公司的公关部出面与客户进展协调，工程经理可以在此过程中坚持一下原那么，与公司的公关部一个红脸，一个白脸，唱出一出好戏。分析3 用户就是上帝小李：“不论怎样，客户才是第一位的。客户可以给他带来收入，也可以给他带来更多的客户和任务，有什么道理不多配合一

30、下他们呢？说实话我对B的做法蛮欣赏的，惋惜行不通。由于客户是上帝，假设照B的做法，后果会呵斥做一次工程丢掉一个客户，太不划算了。 问题： 1、假设他的工程遇到需求变卦问题，他会采用哪种方式去应对？ 2、分析这两种应对需求变卦方式的优缺陷。需求变卦案例分析指点战略：合理控制1、根据客户提出需求的实践情况而定对于客户的需求，如何是合理的，在本人的范围之内，是可以变卦的，但是假设在对前面的主体框架是做以否认的话，那就断然回绝！指点战略：合理控制2、把握好度工程的目的是在规定的时间内完成规定的内容。工程范围在工程启动阶段就曾经确定下来了，绝对不能更改的。假设经常更改，工程经理需求分析一下缘由。假设是客户缘由需求更改，工程经理需求分析任务量，尽量少做改动，但是不能完全回绝客户。假设全盘接受，客户会毫无顾及的更改；假设全然回绝，就没做好沟通管理。随着开发任务的进展需求将逐渐扩展和演化各个开发阶段的任务业务之间存在的承继关系使每一项需求均能追溯