需求变更的5W1H分析
发布于 2024-10-03
1499
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
需求变更原因
需求变化可能由甲方的特殊原因,如不清楚需求、缺乏明确需求或未确认乙方描述的需求。乙方原因包括误解需求或未能引导客户明确需求。共性原因涉及业务本质的变化以及人际沟通障碍。特殊原因可以消除,但共性原因难以根除。
需求变更的提出者
需求变更可能由客户各个层次、最终用户或开发方提出,后者可能因技术实现难点导致需求变更。
需求变更的时机
需求变更可能发生在多个阶段,包括需求确定后设计前、设计后编码前、编码后测试前,以及交付后。需求变更的时机越晚,处理成本越高。
需求变更的内容
需求变更可以从层次(目标、业务、操作)和类型(功能性、非功能性、基本需求、期望、约束、接口、全局性、局部性)两个维度分析。不同需求对象的变更成本有显著差异。
应对需求变更的方法
需求变更应对是系统工程,涉及预防、控制、商务、技术和沟通手段。商务手段包括需求规格说明书、系统验收准则作为合同附件,约定变更决策机构与流程,及成本分担。技术手段涵盖需求获取、分析、描述、评审、复用和领域工程等。沟通手段强调教育客户、沟通以及测试人员参与。管理手段包括建立需求控制组、选择生命周期模型、建立变更流程和需求跟踪矩阵。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 959.3K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
快速学习COSMIC方法之二:COSMIC方法的度量过程
COSMIC方法的度量分为三个阶段:1 度量策略阶段2 映射阶段3 度量阶段在度量策略阶段,主要包括四个活动: 1)确定度量目的:为什么执行本次度量。比如你要度量一个房子的面积,是为了卖房子?是要装修?还是为了装中央空调?目的不同,度量的范围不同,度量的结果也不同。卖房子是要包含建筑面积与分摊面积的,装修房子要考虑套内面积与晾台面积,而装中央空调时只考虑套内面积,目的不同,度量的范围不同,度
开好迭代回顾会议的5个原则
迭代回顾会议是Scrum五个仪式之一,是在迭代评审会议之后对本次迭代的优点与改进点进行复盘的一个活动,其最主要的目的是提升团队的整体能力,持续改进,形成一个自学习的团队。通过回顾会议可以使团队每个迭代都能比上个迭代做得更好。在很多敏捷团队中,最容易忽略该活动,很多团队没有意识到该活动的重要性。为什么呢?最主要的原因是开了会议,没有实际效果,大家认为没用,所以也就不开了。实践中,在开迭代回顾会议时常犯的错误有: 把回顾会议开成了吐槽大会,大家只提意见,不提改进措施; 把回顾会议开成
程序员必读之作:重构
十月一之后安排了我去培训《设计模式》,由于听众多为C与C++的新手,我想先从重构开始讲起,循序渐进,于是我决定仔细阅读〈重构〉这本书。 这本书我很久之前买的,当时大概读了读,感觉不错,就拿给了我表弟去读,他是程序新手。 这次是系统地读。 有个朋友曾经跟我说过,这本书不错,只是有点罗嗦,他是十多年经验的老程序员了,有此感觉很正常。写一个好程序的道理其实就如一层窗户纸,一点就透。但是,难得的是这本书系
敏捷方法开发总结的点评记录
某项目组采用敏捷的方法完成了一个项目,在此过程中,每次迭代结束后,项目组的每个成员都总结了本次迭代的经验教训,我汇总这些经验教训后,点评如下:
如何做好软件估计?
1 有经验的人参与估算 一方面要对估计的内容有开发经验,另一方面也要经过了估计的训练,在估计方面有经验.两种经验缺少其一,估计的风险都比较大. 2 分解的颗粒度要小 在估计时要对估计的内容进行分解,划整为零,对于小的任务进行估计时,才容易把握.比如让你估计一碗大米中有多少粒一样,一般的办法就是把大米划分成大小基本相等的几堆,先估计其中一小堆或者数一数,然后再估计整体的粒数. 3 确保没有遗漏 如果
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线