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

软件项目管理软件项目需求管理概述1软件项目任务分解2第8章软件项目需求与变更管理3软件需求的变更控制学习目标掌握软件需求的概念熟悉需求管理的方法与过程掌握任务分解的方法与步骤掌握需求确认、变更控制和需求跟踪的方法和过程第8章软件项目需求与变更管理HotTip一.软件需求定义需求是来源于用户调查，即客户的需要。需求分析是指软件分析人员通过研究用户在软件问题上的需求意愿，分析出软件系统的功能、性能、数据等诸方面应该达到的目标，从而获得有关软件的需求规格定义的过程。8.1软件项目需求管理概述HotTip一.软件需求定义1．用户需求特点：（1）用户需求直接来源于用户（2）用户需求需要以文档的形式提供给用户审查（3）可以把用户需求理解为用户对软件的合理请求（4）用户需求主要是为用户方的管理层、用户方的技术代表、操作者以及开发方的高层技术人员撰写的8.1软件项目需求管理概述HotTip2．系统需求（1）功能需求全面性一致性可理解可维护可追踪等8.1软件项目需求管理概述（2）非功能性需求性能需求、可靠性、可用性需求、系统安全以及系统对开发过程、时间、资源等方面的约束和标准关心系统的整体特性（3）数据要求HotTip3．需求规格说明书的写作规范1）清晰2）完整3）一致4）可测试8.1软件项目需求管理概述需求的重要性需求是业务的根源，需求工作的优劣对业务影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。8.1软件项目需求管理概述需求是缺陷主要来源Requirements56%Design27%Other10%Code7%错误定位费用分析Requirements82%Design13%Other4%Code1%JamesMartin：超过50%的缺陷由不完善的、不正确的、不准确的和/或不明确的需求所引起JamesMartin：80%以上的用于定位业务错误的费用是基于业务系统需求定义的错误8.1软件项目需求管理概述一个小故事如何练就需求分析的火眼金晴？5W+1H+8C5W就是Who、When、Where、What、WhyWhy是关键1H就是How–需求本身的流程8C指的是8个约束和限制，即8个Constraints：包括性能Performance、成本Cost、时间Time、可靠性Reliability、安全性Security、合规性Compliance、技术性Technology、兼容性CompatibilityDFX-DesignforX面向产品生命周期各环节的设计。DFC、DFS明确的需求是项目的基础1需求的生命周期：需求产生（变化、内部、外部）需求认识（现存、潜在、超前、前景分析）需求表达：1、让提出需求的人尽可能清楚地说明他们的需求；2、对需求提出一系列问题：明确的需求是项目的基础明确的需求是项目的基础2？提出需求的人是如何描述需求的？需求真实吗，是真正需求还是表面现象？我们能满足这个需求吗，其他人能满足吗，是不是真的有解决方法？需求重要吗，值得去满足他吗？满足需求的关键问题在那里，会不会有新的需求产生，还要进一步满足其他需求吗，新的需求能取代目前这个需求吗？需求直接涉及什么人，他们认为这是一个必要的需求吗，满族足需求后对他们有什么影响，他们的反映会怎么样？需求对机构的影响是什么，对我的影响是什么明确的需求是项目的基础明确的需求是项目的基础33、作一些必要的研究工作，更好地理解需求4、根据以上三步得出结论，尽可能清楚地描述这个需求5、听听用户对你的阐述的反映，并作适当修改。功能和技术要求1、把需求变成功能要求；2、功能要求应描述项目最终交付产品的特征3、技术要求根据功能要求产生4、功能要求应用日常语言陈述清楚明确的需求是项目的基础定义需求时的问题1含糊的需求：1、不断变化的需求（人员变化、预算变化、技术变化、商业环境变化）2、误解需求（我说不清楚我所需要的是什么，但我见到东西时就会知道—感觉会随环境变化）过早作出结论（截断需要表达过程——需求分析需要耐心和自我控制）与真正的用户讨论需求定义需求时的问题定义需求时的问题2多种用户，多种需求（确定优先级，即需求层次）曲解用户的需求需求镀金对用户的需求有选择的过滤包办代替定义需求时的问题需求和目标基本需求:项目实施范围、质量要求、利润或成本目标、时间目标以及必须满足的法规要求等期望要求:如一种新产品性能之外的外形、使用舒适HotTip二．需求管理1．需求管理复杂性分析需求的描述问题需求的完备程度问题需求开发的工期问题需求的细致程度问题需求的变化问题8.1软件项目需求管理概述HotTip二．需求管理2．需求管理的基本原则需求管理必须与需求工程的其它活动紧密整合需求必须是文档化的、正确的、最新的、可管理的、可理解的只要需求变化了，需求变更的影响就必须被评估需求必须分优先级需求一定要分类管理8.1软件项目需求管理概述HotTip3．需求管理的方法确定需求变更控制过程进行需求变更影响分析建立需求基准版本和需求控制版本文档维护需求变更的历史记录跟踪每项需求的状态衡量需求稳定性8.1软件项目需求管理概述HotTip三．需求管理过程1．定义需求2．需求确认3．建立需求状态4．需求评审评判需求优劣的主要指标有：正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性、可验证性、可测性。8.1软件项目需求管理概述HotTip三．需求管理过程5．需求承诺6．需求跟踪正向跟踪：以用户需求为切入点，检查《需求规格说明书》中的每个需求是否都能在后继工作产品中找到对应点。逆向跟踪：检查设计文档、代码、测试用例等工作产品是否都能在《需求规格说明书》中找到出处。7．需求变更控制8.1软件项目需求管理概述需求分析在工程中的位置•业务模型用户•抽象、提炼•需求模型需求分析师•设计依据•软件模型开发团队用户/系统业务管理者初始需求变更的需求获取,分析,定义,验证需求控制需求变更需求规格说明项目环境需求开发需求管理需求工程活动综合关系三要点：需求确认、需求变更控制、需求跟踪需求管理的三要点需求管理的目的是在用户与开发方之间建立对需求的共同理解，维护需求与工作成果的一致性，并控制需求的变更。需求工程贯穿开发全过程设计需求架构设计系统规格软件需求硬件需求•质量属性•DFX业务需求用户需求内部需求客户要求•功能需求•非功能需求标准约束•书面标准•事实标准HotTip一．工作分解结构项目的分解结构就是将项目的产品或服务、组织、过程这3种不同的结构综合为项目分解结构的过程，也就是给项目的组织人员分派各自角色和任务的过程。基于成果或功能的分解方法，以完成该项目应该交付的成果为导向，确定相关的任务、工作、活动和要素。基于流程的分解方法，以完成该项目所应经历的流程为导向，确定相关的任务、工作、活动和要素。8.2软件项目任务分解HotTip一．工作分解结构（1）图表形式分解层次与结构8.2软件项目任务分解HotTip工作包是完成一项具体工作所要求的一个特定的、可确定的、可交付以及独立的工作包，可为项目控制提供充分而合适的管理信息。WBS编码设计8.2软件项目任务分解HotTip（2）清单形式①需求分析计划②流程优化③编写需求说明书•编写需求规格词汇表•绘制业务流程•抽象业务类•建立数据模型•将需求分析图示加入规格文档④需求规格测试⑤需求规格确认8.2软件项目任务分解HotTip一．任务分解过程1．分解步骤（1）确认并分解项目的主要组成要素。（2）确定分解标准（3）确认分解是否详细，分解结果是否可以作为费用和时间估计的标准，明确责任。（4）确定项目交付成果。（5）验证分解正确性，验证分解正确性后，建立一套编号系统。8.2软件项目任务分解HotTip一．任务分解过程2．分解的标准:一般不能采用双重标准。选择一种项目分解标准之后，在分解过程中应该统一使用此标准，避免因使用不同标准而导致的混乱。3．分解结果的检验核实分解的正确性：更低层次的细目是否必要和充分？最底层要素是否有重复？每个细目都有明确的、完整的定义吗？是否每个细目可以进行适当的估算？谁能担负起完成这个任务？8.2软件项目任务分解HotTip4．任务分解的注意事项注意收集与项目相关的所有信息。任务分解结果必须有利于责任分配。最底层的工作包一般要有全面、详细和明确的文字说明，并汇集编制成项目工作分解结构词典。避免不必要的过细，最好不要超过7层。按照软件项目的平均规模来说，推荐任务分解时至少分解到一周的工作量（40小时）。8.2软件项目任务分解HotTip5．责任分配及成本分解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张明HotTip一．需求确认需求确认是指开发方和用户共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。8.3软件需求的确认、变更控制和跟踪项目开发面临的实际问题8.3软件需求的确认、变更控制和跟踪一．需求确认项目开发面临的实际问题8.3软件需求的确认、变更控制和跟踪一．需求确认项目开发面临的实际问题8.3软件需求的确认、变更控制和跟踪一．需求确认需求验证的目的和任务需求确认的目的和任务需求验证的目的就是要确保软件需求具有良好的特性（如完整性，正确性等）。需求验证包含的活动满足性（功能需求是否满足需要）满意性（非功能需求是否满意）明确及含蓄的需求(失败)、(成功)共识行（是否能共同理解）可行性（技术是否可行）明晰性（信息是否存在含混性）8.3软件需求的确认、变更控制和跟踪一．需求确认需求确认的方法：1、为需求进行正式评审2、为需求写测试用例3、用检查单识别常见问题4、为需求设定优先级5、最后：形成总体共识8.3软件需求的确认、变更控制和跟踪一．需求确认1、为需求进行正式评审1、为需求进行正式评审8.3软件需求的确认、变更控制和跟踪一．需求确认需求评审做不好的后果：‹需求变更‹需求不明确‹需求不可测‹需求不可实现‹导致后续工作难于开展或经常出现变更由于需求未能得到有效管理，在最终项目验收过程中出现了令人不愉快的情况，实际开发的软件没能完全反映用户的需求，导致用户不满意，项目延期。8.3软件需求的确认、变更控制和跟踪需求确认做不好的后果如何进行需求评审1、为需求进行正式评审‹如何进行需求评审参与需求分析和评审的人员的管理‹软件需求文档的管理‹需求分析过程的管理‹需求变更的管理8.3软件需求的确认、变更控制和跟踪例1：“产品应在不少于每秒的正常周期内提供状态信息。”分析：这个需求是不完整的：状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超过秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。8.3软件需求的确认、变更控制和跟踪例1需求：•后台任务管理器因以误差上下不超过10秒的秒间隔，在用户界面的指定位置显示状态信息；•如果后台进程处理正常，那么应该显示任务已完成的百分数/比；•任务完成时，应显示相关的信息；•后台任务出错应该显示错误信息；•为了测试和追踪，将需求分解多个子需求。使在构造和测试时，被易于分别执行。8.3软件需求的确认、变更控制和跟踪例2：“产品应瞬间在文本中的显示和隐藏不可打印字符间切换”计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些什么动作？而且，在文档中改变显示的范围是多大：选中的文本？整个的文档，或其他的？这也是个模模糊的问题。不可打印字符和隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。8