扫码阅读
手机扫码阅读
需求变更的5W1H分析
138 2024-10-03
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:需求变更的5W1H分析
文章来源:
麦哲思科技任甲林
扫码关注公众号
需求变更原因
需求变化可能由甲方的特殊原因,如不清楚需求、缺乏明确需求或未确认乙方描述的需求。乙方原因包括误解需求或未能引导客户明确需求。共性原因涉及业务本质的变化以及人际沟通障碍。特殊原因可以消除,但共性原因难以根除。
需求变更的提出者
需求变更可能由客户各个层次、最终用户或开发方提出,后者可能因技术实现难点导致需求变更。
需求变更的时机
需求变更可能发生在多个阶段,包括需求确定后设计前、设计后编码前、编码后测试前,以及交付后。需求变更的时机越晚,处理成本越高。
需求变更的内容
需求变更可以从层次(目标、业务、操作)和类型(功能性、非功能性、基本需求、期望、约束、接口、全局性、局部性)两个维度分析。不同需求对象的变更成本有显著差异。
应对需求变更的方法
需求变更应对是系统工程,涉及预防、控制、商务、技术和沟通手段。商务手段包括需求规格说明书、系统验收准则作为合同附件,约定变更决策机构与流程,及成本分担。技术手段涵盖需求获取、分析、描述、评审、复用和领域工程等。沟通手段强调教育客户、沟通以及测试人员参与。管理手段包括建立需求控制组、选择生命周期模型、建立变更流程和需求跟踪矩阵。
想要了解更多内容?
查看原文:需求变更的5W1H分析
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 133.4K
麦哲思科技任甲林的其他文章
快速学习COSMIC之五:如何识别功能用户
一个(类)功能用户是软件的功能性用户需求中数据的发送者或预期的接收者。功能用户是与被度量软件交互的人、设备或软件系统。度量目的决定了功能用户,功能用户不同,度量范围不同,度量出的功能规模就不同。 在识别功能用户时,要注意如下几点: 1 功能用户是从功能性用户需求中识别出来的。 比如有这样一个需求:业务员录入订单信息: 显然,业务员是录入订单信息这个功能的功能用户,而在需求
评审的分类
管理评审 技术评审 同行评审
好书没废话:《看板和Scrum相得益彰》读书笔记
今天花了大概90分钟读了《看板和Scrum相得益彰》一书,让我击节赞叹,确实是一本好书! 1 本书很薄。薄的书能让人有耐心读完。 2 本书言简意赅,观点明确。能让人产生共鸣,能解惑。 3 充满了干货,读后让人有收获,可实际操作。对于我的收获整理如下: CH1-1 Scrum方法:团队拆小,任务拆小,时间拆小;看板:可视化、WIP、...
需求变更对软件质量的影响
根据我们的经验,需求变更越多,造成的软件修改越多,bug也就会越多,事实是否如此呢?需要我们根据历史的数据进行检验。某企业采集了历史上多个项目的的需求变更次数、交付代码的规模、软件测试发现的缺陷个数,参见下表,基于这些历史数据我们分析一下,看看我们的经验结论是否成立。表一:需求变更的历史数据 ID 需求变更数 代码规模LOC 总缺陷数 测试缺陷密度bugs/KLOC
度量指标的数值越大越好还是越小越好?
系统测试的缺陷密度越大越好,还是越小越好呢?不同的人可能观点不一致。推而广之,每个度量指标都存在这个问题,那结论到底是啥呢?
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线