软件需求评审之道
发布于 2024-10-03
1097
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
摘要
本文概述了软件需求评审过程中常见的失败案例,并提出了九个提升评审成功率的实践建议,目的在于帮助减少需求风险,提高软件开发质量。
关键词
需求评审,需求层次,阶段评审,检查单,评审流程
失败案例分析
文章列举了五个软件需求评审失败的案例。这些案例反映出评审过程中的常见问题,如需求报告过长、缺乏准备、评审节奏无法控制、评审员质量不高等。
评审建议
为改善评审过程,提出九个建议:
- 分层次评审:根据目标性、功能性和操作性需求分层评审,确保每个层次的参与者都合适。
- 正式评审与非正式评审结合:灵活运用两种评审方式,兼顾效率和发现问题的能力。
- 分阶段评审:在需求形成过程中逐步评审,降低返工风险,提高质量。
- 精心挑选评审员:选择与系统相关且有足够了解的人员参与评审。
- 对评审员进行培训:培训评审员掌握评审方法、技巧和流程,提高评审效率。
- 充分利用需求评审检查单:使用检查单系统全面地评估需求。
- 建立标准的评审流程:定义评审活动,确保评审过程规范。
- 做好评审后的跟踪工作:对评审结果进行跟踪和变更管理,确保评审效果。
- 充分准备评审:提前下发需求文档,执行评审的进入条件,确保评审前充分沟通。
结语
作者强调,细心体会并实施这些建议将对软件需求评审有显著益处。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 602.6K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
过程描述的方法
图片: 图片: 在CMMI模型中提供了一种描述过程元素的方法,包含了12个要素:• 过程角色(Process roles):哪些角色参与本过程的哪些活动,可以用角色-职责矩阵表示• 适用的过程和产品标准(Applicable process and product standards),包括企业内的或者企业外的• 适用的规程、方法、工具和资源(Applicable procedures, meth
软件需求的12条最佳实践
笔者在咨询实践中总结了针对软件需求工程的12条最佳实践,罗列如下。所谓最佳并非严密的逻辑证明,而是经过大量的实践与观察依据经验确定的,智者见智,仁者见仁,有争议在所难免,仅供参考,能够对大家有所启发,足矣。1 成立甲乙双方参与的需求控制组项目的成功不单是乙方的成功,而是甲乙双方的成功,甲乙双方紧密配合,互相理解,互相合作才能成功,需要避免一方独大,一方具有绝对控制权的现象,所以成立甲乙双方参与的需求控制组是避免需求蔓延的有效手段。该组织具有对需求的决策权,对于每项需求的增删改都要平衡了进度、质量、投入后才
软件项目宏观管理策略点睛
根据国际知名调查机构standish集团的统计,真正成功的项目仅有26%,而其他项目都可以算作失败项目。为什么这么多的项目都失败呢?问题出在哪里呢?依据笔者的经验,很多项目实际上是败在了初期,败在了启动时,败在了项目的宏观管理策略上。即,没有根据项目的特点采用合适的管理策略,即使后续的管理方法再细致也没有用了。我推荐如下八个感触颇深管理策略,供软件项目的管理者借鉴:
头脑风暴会议的注意事项
在组织内会经常召开头脑风暴的讨论会,如何举办一个成功的讨论会议呢,请看如下的30个要点。
软件度量始于规模,终于规模
1 项目初期的度量 无论是甲方还是乙方,希望在项目初期,能够做出一个合理的预算,确定项目的报价。当我们有了初步需求之后,可以对需求进行快速的功能点估算,估算出功能点后,根据历史的单位规模的成本基线,得到本项目的预计成本值,然后再加上一定比例的利润得到项目的报价。 当完成了需求调研之后,我们可以采用精确的功能点度量方法度量软件的规模。有了规模,可以根据历史的生产率基线或规模与工作量之间的回归...
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线