软件需求评审之道
发布于 2024-10-03
2088
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
摘要
本文概述了软件需求评审过程中常见的失败案例,并提出了九个提升评审成功率的实践建议,目的在于帮助减少需求风险,提高软件开发质量。
关键词
需求评审,需求层次,阶段评审,检查单,评审流程
失败案例分析
文章列举了五个软件需求评审失败的案例。这些案例反映出评审过程中的常见问题,如需求报告过长、缺乏准备、评审节奏无法控制、评审员质量不高等。
评审建议
为改善评审过程,提出九个建议:
- 分层次评审:根据目标性、功能性和操作性需求分层评审,确保每个层次的参与者都合适。
- 正式评审与非正式评审结合:灵活运用两种评审方式,兼顾效率和发现问题的能力。
- 分阶段评审:在需求形成过程中逐步评审,降低返工风险,提高质量。
- 精心挑选评审员:选择与系统相关且有足够了解的人员参与评审。
- 对评审员进行培训:培训评审员掌握评审方法、技巧和流程,提高评审效率。
- 充分利用需求评审检查单:使用检查单系统全面地评估需求。
- 建立标准的评审流程:定义评审活动,确保评审过程规范。
- 做好评审后的跟踪工作:对评审结果进行跟踪和变更管理,确保评审效果。
- 充分准备评审:提前下发需求文档,执行评审的进入条件,确保评审前充分沟通。
结语
作者强调,细心体会并实施这些建议将对软件需求评审有显著益处。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 1198K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
一个典型的代码走查检查单
代码走查的最主要的目的是为了发现程序中的逻辑错误,编程风格方面的错误可以通过风格检查的工具去检查。如下的检查单给代码走查的专家发现逻辑错误提供了一个很好的帮助。序号检查项1代码的注释与代码是否一致?注释是否是多余的?2是否存在超过3层嵌套的循环与/或判断?3变量的命名是否
快速学习COSMIC方法之十二:如何识别输出?
输出是从功能处理向功能用户移动数据组的数据移动。每个输出移动的是一个兴趣对象的一个数据组。在识别输出时要注意如下的问题:1 输出不要和写混淆。输出是把数据组移动到功能用户,不是移动到存储介质。虽然识别错了数据移动的类型不影响功能点的多少,但是概念上是错误的。2 查询固定文本的内容应识别为输出。比如在word中有按钮:关于word。当我们点击后,显示出来关于word的一些信息,这些信息就是一个固定文...
测试用例评审的旁观记录
测试用例评审应该如何做?
职业的程序员与业余程序员
(1)职业的程序员设计的时间长于编码的时间,业余程序员编码的时间长于设计的时间; (2)职业的程序员是设计程序,业余程序员是调试程序; (3)职业的程序员是预防BUG,业余程序员是修改BUG; (4)职业的程序员无论何时都能读懂自己的代码,业务程序员总是读不懂自己的10天前的代码; (5)职业的程序员总能读懂别人的代码,业余程序总是读不懂别人的代码; (6)职业的程序员习惯了读别人的代码,业余程序
再谈站立会议的实施要点
昨天在东莞客户封闭开发的现场,观察了一个产品开发组四个小组实施站立会议的情况,分析了他们执行的优缺点,对如何执行站立会议,如何获得站立会议的成功进行了再次归纳总结,要点如下:1 任务的分配与领用i)任务的责任人要明确;ii)任务的颗粒度小于2天;iii)如果有的任务颗粒度实在无法拆分到2天以内,则需要设置中间的检查点;iv)任务的完成时间要明确;v)任务的完成标准要明确;vi)任务识别的要尽可能完
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线