产品需求分析与需求管理培训教材PPT.ppt

上传人:laozhun 文档编号:2266096 上传时间:2023-02-08 格式:PPT 页数:171 大小:7.04MB
返回 下载 相关 举报
产品需求分析与需求管理培训教材PPT.ppt_第1页
第1页 / 共171页
产品需求分析与需求管理培训教材PPT.ppt_第2页
第2页 / 共171页
产品需求分析与需求管理培训教材PPT.ppt_第3页
第3页 / 共171页
产品需求分析与需求管理培训教材PPT.ppt_第4页
第4页 / 共171页
产品需求分析与需求管理培训教材PPT.ppt_第5页
第5页 / 共171页
点击查看更多>>
资源描述

《产品需求分析与需求管理培训教材PPT.ppt》由会员分享,可在线阅读,更多相关《产品需求分析与需求管理培训教材PPT.ppt(171页珍藏版)》请在三一办公上搜索。

1、产品需求分析与需求管理实务,第一讲 产品需求分析,课程目录,2、产品需求分析和需求管理概述,3、产品需求收集,5、产品需求分解和分配,4、产品需求整理和需求分析,实现全方位研发管理信息化,案例分析,对企业核心价值链的理解,对项目立项管理的理解,调研,从需求管理角度分析该产品研发失败的原因?从自己了解的项目出发每个代表只能讲一个原因,产品需求分析与需求管理概述,需求的重要性,需求是产品的根源,需求工作的优劣对产品影响最大。就像一条河流,如果源头被污染了,那么整条河流也就被污染了。,什么是项目?,项目是临时的努力,旨在创造出产品和服务项目管理就是把知识、技能、工具和技术应用到项目活动中去,以便达到

2、项目的要求。,项目,范围,质量,资源,时间,需求的定义,需求是对产品或过程的操作、功能和设计的特性或约束的表述,这些表述是明确的、可测试的、可度量的,而且对于产品或过程的可接受性(被顾客或内部质量保证措施)来说是必须的。IEEE1220-1998,缺陷引入阶段分析,错误定位费用分析,错误引入阶段分析,James Martin:超过50%的缺陷由不完善的、不正确的、不准确的和/或不明确的需求所引起,James Martin:80%以上的用于定位产品错误的费用是基于产品系统需求定义的错误,什么是需求工程?,把所有与需求直接相关的活动通称为需求工程需求工程中的活动可分为两大类:需求开发、需求管理,需

3、求工程各个阶段工具,需求收集,需求整理和分析,需求分解和分配,需求实现和验证,市场需求的执行与验证,客户所想所需,市场 需求,产品包 需求,设计 需求,产品规格书,开发 需求,测试,需求的执行,需求的验证与确认,结构化的产品开发流程,资料来源Setting the PACE in Product Development,A Guide to Product and Cycle-time Excellence,产品开发过程关键的控制点,概念,方案,开发,验证,发布,启动项目,TR,TR,TR,TR,TR,TR,DCP,DCP,DCP,需求在产品开发流程中的位置,概念,计划,开发,验证,发布,理解

4、需求收集需求(内部/外部)核心技术方案分析标竿研究解释需求汇总产品包需求,需求分解总体方案设计需求分配规格确定需求确认BUILD划分,需求跟踪需求变更控制,需求内部验证需求外部验证,市场管理流程与产品开发流程之间的关系,进入产品开发流程管道,业界流行的Marketing组织架构,PDT,.,PDT,PDT,PDT,.,PDT,PDT,PDT,.,PDT,PDT,产品线,公司决策委员会,C-Marketing,PL-Marketing,产品线,产品线,PL-Marketing,PL-Marketing,项目任务书中的需求,持续的需求工程,持续的需求工程,市场管理和产品路标规划,市场驱动的新产品开

5、发,任务书,项目代号:MP31028项目概述:竞争对手:核心需求(510条)1、利用汽车点烟器直接充电2、音乐发送射到汽车音响并播放3、支持MP3、WMA、WAV主流音乐格式4、存储容量500首音乐、500M存储空间5、不间断播放时间48小时,?,需求工程贯穿产品开发全过程,市场需求,产品包需求,内部需求,设计需求,系统规格,产品需求,客户要求,功能需求非功能需求,标准约束,硬件需求,架构设计,质量属性DFX,书面标准事实标准,演练与讨论,项目任务书作为市场管理和产品开发管理衔接的核心文档,起到对市场管理成果进行整理浓缩,同时明确产品开发方向和约束的作用,小组讨论思考,一个高质量的项目任务书需

6、要包含哪些要素?每个小组选派一名代表上台发言,产品需求收集,需求收集过程,市场细分产品扩展路线图波士顿矩阵技术鸿沟,干系人分析决策分析关注点分析焦点小组,调查方法选择10种调查方法需求访谈10问调查问卷设计原型法,单项需求模板听的技巧一手信息二手信息客户描述需求陈述需求陈述5原则短、中、长期需求,谁是用户?,“用户”(user)是一种泛称,它可细分为“客户”(customer)、“最终用户”(the end user)和“间接用户”(或称为关系人)。掏钱买产品的用户称为客户,而真正操作产品的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。,需求采集的要点:确定用户,需求采集的要

7、点:决策影响分析,需求采集的要点:关注要点分析,客户划分,创新者,早期接受者,前期主流顾客,后期主流顾客,落伍者,鸿沟,创新无处不在,颠覆性创新,应用性创新,产品创新,平台创新,产品线延伸创新,增强型创新,营销创新,体验式创新,价值工程创新,集成创新,流程创新,价值转移创新,产品扩展策略,业务,客户,以客户为导向投入,现有产品,全新产品,老客户,拓展客户,全新客户,以产品为导向投入,拓展产品,不做,谨慎,谨慎,创新,客户需求的收集途径,市场活动,销售活动,用服活动,公开信息,商业伙伴,专业数据,一手信息,二手信息,需求库,需求整理分析,报告交流,竞争者信息.,专家顾问团,高层拜访,展览,用户探

8、针,用户大会,用户访谈,客户反馈,现场问题解决,网上设备巡检,产品介绍、投标,标杆研究,采集方法的特点,用户访谈的要点,利用一个或两个客户群来优化调查的问题并了解在市场细分中的普遍问题,进行单个的访谈来了解特殊客户的需求-注意被访对象的筛选-建议在客户地点进行-允许将你所见的加入客户的声音(VOC)中去,在业界最佳的公司在首选的搜集客户声音的方法访谈单个的客户资料来源:Best Practices Survey 1994,广泛的、开放式问题,历史产品使用的美好回忆,使用产品失败的经历描述,最近一次购买时所见、所想,如何自己设计会如何,其他产品的哪些功能可以考虑集成,客户试图解决哪些问题,演练与

9、讨论,根据前面讲解的需求访谈问题设计方法,每小组针对所选择的演练产品,通过小组讨论的方式,确定本小组需求访谈问题清单?请结合自身工作经历,归纳自己最想问的问题每个小组选派一名代表上台发表,需求收集的要点:听的技巧,多问多听,不要推销你的想法对于听到的确认,确保理解对方的意思表现的“无知”些,让他们详细的描述或举例聚焦与人们的期望而不是问题注意倾听大家不一致的地方,真正理解客户意图,密切关注,我想我希望 我要 我正在找 我对很感兴趣 我期望我认为,“抽象之梯”法:深入探索、了解、洞察客户需求,抽象,具体,解决方法,需求,评判,证据,通常,某一次,其他人的体验,个人经历,无法行动,可采取行动,案例

10、:解决方法 VS 需求,解决方法,需求,“满足我需求的电脑包一定是树脂材料做的”,“我每周都在各种恶劣的气候环境里使用电脑包上下班和出差,包在机场的行李搬运中,经常被挤压,磨损,划伤,到了客户现场,电脑包可能放在有水迹的工地上,也许会放在渣土地上”,尽可能了解到具体细节,关键要素防御各种恶劣天气防水防摩擦,客户陈述需求描述,客户需要翻译,客户之声(客户反馈/原始陈述,反映了客户所关心的和所渴望的)场景图画(基于“客户之声”的体察和发现,在头脑中产生的有关客户使用环境的印象、图画)关键要素(讲“客户之声”和“场景图画”联系,产生的关键字或词语)客户需求(包含一个或几个关键要素的一句陈述),单项需

11、求采集模板,部门:,姓名:.,联系方式:,采集的活动(where/when),客户背景资料,客户情况介绍(who),客户陈述(what),产生的原因(why),客户的评判(how),需求关联,系统关联业务关联人物关联支持材料关联,验收标准满意度竞争评判优先级,需求描述(demands),需求收集工作反思,是否和目标市场上所有主要类型的客户都交流了?,通过捕捉客户的潜在需求,我们能够看到产品相关需求之外的需求吗?,哪些是我们现在知道而开始是不知道的?我们是否对其中的需求感到惊奇?,需求调研组织中是否包含哪些需要深化理解客户需求的人?,在实际客户交流中,哪些将成为进行开发活动的优秀参与者?,构造例

12、行化需求收集机制,构建需求收集IT系统形成需求收集报告机制组建需求收集分析专业团队与员工任职资格、绩效挂钩控制神经末梢(出差、展览、招标等),演练与讨论,依据提炼总结的客户需求访谈问题,对客户进行需求调研,详细记录客户访谈情景,然后对访谈获得进行总结提炼,完成客户需要翻译。每个小组选派一名代表上台发表,产品需求整理和需求分析,需求整理和分析过程,需求收集,解释原始数据,整理需求,设置权重,概念选择,识别客户一对一访谈客户需求十问单项需求收集单,系统工程核心小组法DFX,$APPEALS产品包镀金需求冲突矩阵卡片法25个大组,BSA法AHP法15个等级雷达图SWOT,未来需求是否充分考虑价值创造

13、(4步法)产品包需求概念甄别电梯测验,什么是系统工程?,业界流行的Marketing组织架构,系统工程、部件设计、项目管理,系统工程涉及项目的各个方面,最终用户,集成商,安装人员,维护人员,市场行销,系统工程,界面,协议,控制,集成验证,需求分解分配,概念甄选与评估,定位:设定目标,用户,子系统团队,GUI,认证,模块负责人,需求集成,SE,实现团队,易用性设计可维护性设计可靠性设计可测试性设计人机界面重用设计安全性设计可制造性设计$APPEALSQFD,.,需要,需求,需求与规格,项目管理,项目计划,技能支撑,PDT的两个核心团队,SE,制造工程,产品系统,硬件系统,测试工程,服务工程,业务

14、分析,PDT:Product(Project)Development Team 产品(项目)开发团队,STEP1:整理单项需求(工具:黄纸贴),STEP2:需求归类,进度管理,报告管理,STEP3:定义归类后的需求组,层次1标题,原始陈述,原始陈述,层次1标题,原始陈述,原始陈述,原始陈述,层次2标题,黑色字体,红色字体,蓝色字体,优先筛选法非限制选择标记有重点的选择标记,STEP4:狂想(方法:头脑风暴法),与众不同的新奇想法其他产品功能的借鉴客户还可能需要的深层次需求每个人都要开动脑筋思考,需求群2,整理需求,需求群1,a,c,g,f,x,客户需求(需求描述),客户需求(需求描述),KJ亲

15、和图法,案例:刻录机KJ图,产品外部需求的8个大类,(Price)价格A(Availability)可获得性P(Packaging)包装P(Performance)性能E(Easy of use)易用性A(Assurances)保证L(Life cycle costs)生命周期成本S(Social acceptance)社会接受程度,$APPEALS要素展开,设置需求群的重要性和权重,选择两个友商进行对比(雷达图),10=绝对最好 9=显然的领导者 8=在前2名内 7=位于前3-5名 6=在市场中普遍被认为是优秀的 5=大多数购买者能接受 4=有25%-35%的购买者不能接受 3=大多数购买者

16、不能接受 2=极不满意 1=完全不合格,分析差距,找改进点,客户为什么认为我们比较差,X有哪些我们可以借鉴,X表现就十全十美了吗?能否超越他们?,客户认为我们哪些地方做的比较好,X针对我们的优点会有哪些改进措施,这些措施对我们的威胁如何?还能做的更好吗?,价值创造的四步动作框架,演练与讨论,请根据讲解的市场需求分析的方法,对所选择的产品进行$APPEALS的需求分析,寻找该产品和竞争对手及客户期望之间的差距;结合业界市场需求和研发需求的管理的组织体系,思考适合公司实际情况的需求管理组织体系?每个小组选派一名代表上台发表,识别冲突(冲突矩阵法),需求,需求,设置权重(优先级确定),用数字来表示重

17、要性以排列需求组基于与客户的经验,依靠团队以决定权重基于对潜在客户访谈或问卷调查的评估需要在成本、速度与相对正确性之间进行平衡调查参与最初问卷访谈的客户以判断权重的相对重要性,需求优先级设定,费用与价值比方法:计算每个需求的相对价值和相对费用。优先级最高的需求是以最小的费用比例产生出最大产品价值比例的需求。质量功能开发(QFD)方法:为产品提供用户价值与性能相联系的一种综合方法。完全质量管理方法:它以多个重大项目成功的标准来评价每个需求,并且计算出一个分值用于编排需求的优先级。,质量功能开发方法的图表和步骤,XXX,XX%,X,XX%,X,XX%,XX,X,X,n.XXXXX,优先级,风险%,

18、相对风险,费用%,相对费用,价值%,总价值,相对损失,相对利润,需求/特性,XXX,XX%,X,XX%,X,XX%,XX,X,X,1.XXXXX,总计,X,X,X,X,相对权值,在一个平面中列出要设定优先级的所有需求、特性或使用实例;在这个例子中,我们将使用特性来设定优先级。所有项都必须在同一抽象级别上;不要把个人需求与产品特性混合在一起。如果某些特性有逻辑上的联系(例如,只有包括特性A的情况下才能实现特性B)那么在分析中只要列出驱动特性就可以了。这种模型在其有效范围内可以容纳几十种特性。如果你有更多的项,那么就把相关的特性归成一类,并建立一个可管理的初始化列表。如果你需要的话,可以在更详细的

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

20、计实现每个特性的相对费用,使用1(低)9(高)划分等级。平面图将计算出由每一个特性所构成的总费用的百分比。,开发者应该要估计出与每个特性相关的技术或风险相对程度,并利用1 9划分等级。1级表示你可以轻而易举地实现编程,而9级表示需要极大地关注其可行性、缺乏具有专门知识的人员,或者使用不成熟或不熟悉的工具和技术。平面图将计算出每个特性所产生的风险百分比。在缺省情况下,利润损失,费用和风险的权值是相等的,但是你可以在平面图中调整其权值。如果你无需在模型中考虑风险,就把风险的权值设为0。,优先级设计的矩阵范例,4 基于价值、费用和风险的优先级设定,KANO模型,客户满意度,客户不满意度,很好的执行,

21、很差的执行,基本需求,最好满足的需求,兴奋需求,Kano模式,客户需求重要性判断,如果提供了该功能,您会有什么感觉?,如果没有这功能,您又会有什么感觉?,单项需求重要性定义(BSA),B(Basic):基本需求S(Satisfied):让客户更满意的需求 A(Attractive):更有吸引力的需求,BSA,需求群权重设置方法(AHP),分层展开,如:A、B、C每一层次的项目数量最佳效果5个,最多9个两两比较、经过计算得到权重数据具体分4步:,AHP:Analytical Hierarchy Process(层次分析法),建立矩阵,量化重要性,重要性计算,层次分析,建立矩阵,量化重要性,同等重

22、要:1分列和行有同等的影响中等重要:3分经验和判断中,行比列更重要一点比较重要:5分经验和判断中,行比列更重要一些非常重要:7分行是非常重要的,并由实践证实极其重要:9分行是极其重要的,填写比较结果,重要性计算,重要性计算,最终确定需求群的重要性和权重,需求群权重确定,需求群,什么是产品包?,无形效益,服务,核心产品,产品包需求相关的角色定义,市场需求业务专家负责,制造需求制造专家负责,测试需求测试专家负责,服务需求服务专家负责,整合、折中,产品包需求SE、LPDT负责,形成产品需求文档,编号客户陈述需求描述优先级改进目标衡量需求带来的利益BSA定义,产品包需求,某系统产品包需求类别,性能方面

23、、标准协议、维护补丁、平滑升级、告警维护、运行统计、文档资料、关键接口、数据安全恢复、安装升级、系统自检自测、操作界面、兼容性、鲁棒性、操作维护日志、操作权限、故障修复、系统可测试性、系统可维护性、系统可制造性、专项维护工具、动态跟踪、二次开发、故障定位、可移植性、错误诊断工具,,演练交付,高质量产品包需求的标准,有“杀手锏”,明确性,一致性,可验证性,可行性,完整性,产品包需求,洞察客户需求,消费了,但是不满意,有需求,但是未消费,消费了,基本满意,认为自己没有需求,未消费,现实需求没有满足的三个方面,未加入消费群体的三个主要障碍,认为自己没有需求的三个主要原因,需求的象限分析,高兴的噪声,

24、无用的浪费,差异化优势(魅力功能),强制性要求(基本功能),对客户的重要性,和竞争者的区别,低,低,高,高,第一、唯一,第一个到太空,第一个奥运金牌,美国第一任总统,智者言论,“蜂窝式移动电话的费用高,让很多人望而却步,他们90%是在本地范围活动,想拥有移动通讯工具,又希望通话费同市内电话一样。”余杭电信局长 徐福新,“市场需要才是重要的,好的技术就是最适合市场需要的技术”UT CEO 吴鹰,“有压力的、有歧变的、由政策行为导致的需求,就不是真正的需求,我们一定要区分真正的需求和机会主义的需求”华为 CEO 任正非,有所不为,才能有所为,戏剧性的巨大差异(哇!),是什么可能是什么.不可能是什么

25、,12核心利益:44%3个以上核心利益:37%,概念选择,概念是让某种产品或者服务不同于其他产品和服务的核心信息,概念A,概念B,概念C,概念评估,为概念选择提供依据,为标示风险提供依据,优化已有概念,优化已有需求,概念案例,免费通话音质超优安装简易全球通用,支持不限容量的文件共享支持离线文件传输支持5人同时语音聊天,概念甄别方法:电梯测验,第一步:描述机会和需要解决的问题(20秒)第二步:描述本产品或服务是如何满足机会和解决问题的,具体给消费者带来的核心利益(20秒)第三步:描述会取得的结果,对公司的价值(20秒)第四步:用概括的语言(最好是一句话)将上述3点的精髓表达出来(5秒),价值定位

26、“我为什么应该向你购买?”,产品概念的测试,概念评估与测试是否是能激发热情和感情投入的绝好主意?是否可信?是否与需求或者挫折相关,前提假设是否正确?是否有改进该想法的办法,以更好的满足需求?产品概念选择概念的价值(15分)概念的可信度(15分),新概念的名称(1n)产品概念的文字与图像描述客户需求(问题假设)核心创意解决方案:功能和性能特征对客户的利益新产品原型草图,新颖型、需求的满足性、操作方便性、整体吸引力、技术实现难度、成本,市场需求文档,产品需求分解和分配,版本化开发与路标规划,MP3功能,U盘功能,拍照功能,广播功能,电影功能,版本二,版本一,版本三,功能/市场,时间,客观原因资源需

27、求进度专业分工人才培养,设计需求工程全过程,需求因子,功能,环境,性能,鲁棒性,可靠性,安全性,重量,电源,需求关键技术:Use Case,产品需求划分,产品需求,功能需求,非功能需求,行为响应周遭事物的关联,属性标准约束规范,人类飞行需要什么?,需求分解与分配过程,分析产品包需求定义功能接口分配非功能需求QFD法,可选设计方案CBB构思BB划分,DAR功能架构完整性物理架构完整性约束的满足程度确定优选的设计方案,定义子功能定义子功能的操作方式进行功能失效模式分析,功能分组和分配分配非功能需求定义物理接口产品设计需求产品总体方案,Y,N,功能分解工具一:功能流框图(FFBD),面向功能而不是面

28、向设计方案定义下级功能及其顺序关系反映系统的逻辑架构和层次表示,FFBD:Function Flow Block Diagram,功能定义,确定系统的主要功能、输入/输出信息按照时间功能列出典型的输入和输出,称之为行为情景直接面向外部系统,一般要求端到端,功能定义实战方法:创建故事板,时间,功能分解,将系统功能分解为更详细的子功能将子功能需求按照逻辑顺序排列详尽考虑所有可能的异常和反复,四种基本功能控制,并行,选择,循环,迭代,自上而下层层分解,Top Level1st Level2nd Level,6.0,5.0,3.0,4.0,2.0,1.0,1.1,1.2,1.3,1.4,1.5,1.6

29、,1.7,2.6,2.8,2.7,1.4.1,1.4.2,1.4.3,1.4.4,1.4.5,1.4.6,1.4.7,1.5.6,1.5.7,功能分解工具二:层次图,层次图:Hierarchy Diagram(Function Tree、Physical Tree),演练与讨论,选择一个功能需求,利用前面讲解的FFBD(功能流图)法,对该功能进行自顶而下的分解,形成功能分解图?或者具体演练:“QQ防老板特性设计”选择一个功能需求,利用前面讲解的HD(层次图法),对该功能进行自顶而下的分解,形成层次图?或者具体演练:“产品的安全性设计或者易用性设计”每个小组选派一名代表上台发表,架构建立,从子系

30、统到模块、组件的逐级细化过程定义系统内、外的物理接口考虑子系统、模块的可重用性最大限度利用已有、特别是商用的产品通过创造性的活动,形成多个候选的设计方案,决策分析与决议表单,优势,风险,问题,优势,风险,问题,需求分配,明确系统内、外接口定义确保所有的功能需求都分配到物理部件每个功能都要由一个物理部件来完成将非功能需求分解分配到功能和物理部件,需求分配示意图,系统,功能1,功能2,功能3,子功能1.1,子功能1.2,系统,子系统1,子系统2,子系统3,模块A,模块B,功能分解,物理分解,需求分解分配方法,以下需求有什么问题?,某照相机有2个需求:在胶片到底后,可高速回绕。胶片回绕过程中噪音要小

31、。某发动机有4个需求:如果 70 温度 100,那么输出功率为3000W如果100 温度 130,那么输出功率为2000W如果120 温度 150,那么输出功率为1000W如果150 温度,那么输出功率为0W,好需求的标准,需求标示规则,R.TYPE.FI.NNN,产品需求模板,第二讲 需求管理,内 容,需求管理 CMM2级需求管理关键过程域,用户/系统,市场,管理者,初始需求,变更的需求,获取,分析,定义,验证需求,控制需求变更,需求规格说明,项目环境,需求开发,需求管理,需求工程活动综合关系,需求管理的目的是在客户与开发方之间建立对需求的共同理解,维护需求与工作成果的一致性,并控制需求的变

32、更。包括:需求确认、需求变更控制、需求跟踪1、需求确认需求确认是指开发方和客户共同对需求文档进行评审,双方对需求达成共识后做出书面承诺,使需求文档具有商业合同效果。,需求管理的最终作用,需求确认,产品开发面临的实际问题,产品开发面临的实际问题,(1)非正式需求评审项目经理先在项目内部组织人员进行非正式的需求评审,消除明显的错误和分歧。(2)正式需求评审项目经理邀请同行专家和用户(包括客户和最终用户)一起评审需求文档,尽最大努力使需求文档能够正确无误地反映用户的意愿。(3)获取需求承诺通过正式评审后,开发方负责人(项目经理)和客户对需求文档做书面承诺,使之具有商业合同效果。,需求确认步骤:,非正

33、式评审之测试用例法验证,正式评审之专家评审的做法,检查单法,最后:形成总体共识,本需求文档建立在双方对需求的共同理解基础上,我同意后续的开发工作根据该需求文档开展。如果需求发生变化,我们将按照“需求变更控制规程”执行。我明白,需求的变更将导致双方重新协商成本、资源和进度等。甲方负责人签字 乙方负责人签字,形成单项共识,什么是需求变更?,初始需求,变更的需求,对问题的初始理解,对问题的新理解,时间,2、需求变更控制,单纯的用户因素 市场形势变化 系统因素 工作环境和要求变化 需求开发的缺陷 需求分析、定义和评审不充分 与用户沟通不畅,需求变更原因分析,需求变更对产品开发的影响,使变更前开发工作和

34、成果失效 返工成为被迫采取的对策 工作量及资源投入的增加使开发成本提高 项目完成时间后延,需求变更失控可能导致的后果,未受控的需求 变更引起需求 和实现不一致,受控的需求 变更使需求和实现一致,受控的需求变更,降低需求变更风险的策略,与用户充分沟通与用户共同明确确定的需求的意义,向用户说明需求不确切或频繁变更对开发工作的冲击使用户理解过多变更最终对用户不利,与用户共同确定需求,作为合同附件,签字生效 合同中含有对需求变更的条款 采用原型方法开发,或螺旋模型开发 项目计划中适当留有余地(时间进度、人力投入、费用等)严格实施变更控制,需求变更控制要求,变更控制的策略(1)所有需求变更必须遵循需求变

35、更控制规程实施变更。(2)需求变更提出后是否被接受,应由专门的组织变 更控制委员会(CCBChange Control Board)审查决定。(3)不得以任何理由删除和修改需求变更的原始文件。(4)应将已接受的需求变更通知到所有相关人员。(5)已接受的需求变更应能追溯到批准的变更请求。(6)对项目的需求赋予状态属性,以利于需求变更的控制。,需求变更影响的控制,按CMM2级RM KPA的要求,由于分配需求的变更导致产品计划、工作产品和活动的变更,都应对其作:识别评价风险分析编制文档制定计划传达给受影响的小组和人员跟踪直至结束,变更控制的步骤,(1)提出变更请求(2)审理变更请求,进行变更影响评估

36、。评估内容包括:变更所需人力投入变更对原计划安排的影响估计变更引起的成本增加(3)批准变更请求(4)取得用户的认可(5)修订项目计划(6)实施变更(7)验证变更,需求变更控制实施,需求变更请求(1)内容申请号变更说明变更类别影响分析变更请求状态变更请求日期,需求变更请求实例,需求变更申请单(我国),需求变更累积影响的跟踪,(1)需求变更累积影响跟踪的意义和作法累积影响变更累积表(2)需求变更累积表实例(表四),需求变更累积表,需求控制流,(1)需求状态及其演变产品需求在后继阶段开发工作中将逐步展开,加以实现。在不同的开发阶段产品需求以不同的形式进行着状态的演变。例如:需求阶段从获取的需求到定义

37、的需求建议阶段制定出项目计划以后演化为承诺的需求设计阶段设计工作完成并在验收后成为设计的需求编码阶段完成编码和单元测试后成为实现的需求测试阶段完成确认测试后成为完成的需求,开发阶段,需求状态,需求,建议,设计,编码,测试,获取,定义,承诺,设计,实现,完成,生存期各阶段需求状态的演变,需求的类型及其追踪性,问题,解决方案领域,市场领域,市场需求,产品需求,设计规约,所要构建的系统,(1)需求可跟踪与需求变更控制随着开发工作的进展需求将逐步扩展和演化各个开发阶段的工作产品之间存在的继承关系可跟踪矩阵(2)可跟踪管理的目标使每一项需求均能追溯到前后继承关系的脉络清晰可见(3)两类不同的跟踪(1)向

38、前跟踪(2)向后跟踪,3、需求跟踪,可跟踪矩阵,(1)矩阵的作用 可防止遗漏为评审提供方便便于进行变更影响追踪、分析和检查(2)矩阵的建立与维护,(3)矩阵的应用完整性检验考察有无需求遗漏的情况有无冗余代码检查所有性能需求是否已被测试用例测试对集成测试计划和系统测试计划进行交互检查需求变更控制需求变更后相关的工作产品受影响的部分应随之变更更新需求规格说明,同时要更新跟踪矩阵每增加一项需求,应在跟踪矩阵中得到体现,表 跟踪矩阵实例,需求跟踪归纳如下:1、建立和维护需求跟踪矩阵正向跟踪逆向跟踪当需求文档或后续工作成果发生变更时,要及时更新需求跟踪矩阵2、查找不一致后续工作成果没有实现需求文档中的某

39、些需求后续工作成果实现了需求文档中不存在的需求后续工作成果没有正确实现需求文档中的需求3、消除不一致将消除不一致记录到“需求跟踪报告”消除不一致后,项目经理更新“需求跟踪矩阵”,CMM 2级 RM KPA,需求管理(RMRequirements Management)是CMM 2级的第1个关键过程域。需求管理的目的是要在客户和将处理客户需求的产品项目之间形成共同的理解。这种共同理解应该体现在:客户需求的文档和对客户需求的控制中使项目的计划、产品和活动都应与需求一致,美国企业眼中的需求管理目标与活动,目标1:分配给产品的系统需求应是受控的,以利建立产品工程和管理的基线活动1:在分配需求被纳入产品

40、项目之前,产品工程组应对其进行评审目标2:产品计划、产品和活动要与分配给产品的 系统需求保持一致活动2:产品工程组将分配需求作为产品计划、工作产品和活动的基础活动3:评审对分配需求的变更,并将变更纳入产品项目,2约定与能力,约定1:项目要遵循一个书面的组织方针来管理 分配给产品的系统需求能力1:为每个项目规定分析系统需求并将其分 配给硬件、产品和其它系统成分的职责能力2:编制分配需求文档能力3:为管理分配需求提供足够的资源和资金能力4:产品工程组人员和与产品相关的其它组 人员要接受培训,以利于完成他们的需 求管理活动,3测量与验证,测量1:进行测量,并将测量结果用于确定对分配 需求所作管理活动的状态验证1:高级管理者定期评审管理需求分配的活动 验证2:项目经理定期地也要在特定事件出现时 评审管理需求分配的活动验证3:产品质量保证组评审和(或)审核管理 需求分配的活动和工作产品,并报告结 果,4入口任务验证出口(ETVXEntry,Task,Verification and eXit(表六 RM 的 ETVX),系列需求管理文档及模板介绍,课程结束,祝大家随需应变!,谢谢,

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 建筑/施工/环境 > 项目建议


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号