如何进行需求评审

上一篇 / 下一篇  2011-03-14 17:05:05 / 个人分类:需求阶段

问题描述:我们公司快要成立测试部了,之前我们一直是研发部下的测试小组,在成立之前,我们测试组集体讨论了下测试组成立前后的一些问题。其中一个难题就是需求,我们几个都没有相关的经验,所以我在此求助大家,邀大家来讨论下:如何进行需求评审?怎样的需求评审机制才是有效的?

精彩回答:

  关于需求评审,首先我觉得应该解决的是可用的评审可用资源问题,只有把这个问题解决了,其评审结果才可以采信,否则不过形式尔耳。

  关于需求评审的一些必备资源,我这里选列了相关角色,如下列:

  * 业务专家或是熟悉该业务的人员(通常也叫业务方代表)

  * 文档审查人员

  * 架构师

  * 需求分析师

  * 需求评审组织人员及记录人员

  当然,除了人员意外,必要的时间、场地和上层决策者的支持也是不可或缺的。

  这些资源一旦准备停当,接下来就是如何安排评审事宜的问题了。我这里简单列下以往曾做过的一轮需求评审的过程:

  * 准备阶段(P)

  o 争取上层决策者的支持与谅解

  o 筹备相关的资源,包括人力、时间计划,评审场地

  o 在正式评审之前,将相关的需求记录(文档或其他形式)发布给每个参与评审的人员手中,并确保其有足够的时间可以通阅需求并做好评审前的相关质疑与确认记录

  o 在正式评审之前,会议组织者应先收集相关评审人员的各项需求评审建议和意见,对存在争议和疑惑的需求说明必须做好讨论的安排

  o 发布经确认后的评审计划或时间表

  * 实施阶段(D)

  o 由评审组织者召集各评审人员集中评议,可以以正式的会议等形式组织,此处以会议为形式做说明

  o 与会人就某具体的问题进行讨论,讨论的优先级如下所列

  * 最重要的业务内容,一般是按流程、功能、细节来排定

  * 争议或疑问较多的地方

  * 部分有争议的地方

  * 对于没有提出疑义的地方,可以快速流过

  o 最后,要注意一定要回顾已提出问题和有结论的地方

  o 由会议记录人员整理会议的纲要,记录各与会人员的相关意见,并在会后递交纪要

  * 检查再实施阶段(C)

  o 对评审得出结论的问题进行再次确认和修正补充

  o 确定下次评审的时间

  o 按照第一阶段的流程再次进行组织,并确认结果

  o 对大多数组织,两次评审可以解决大部分的问题,对于悬而未决的问题,如影响范围有限,则可以延后讨论解决

  * 总结阶段(A)

  o 就以上内容做最后的确认,需求定稿,各方签字确认。

  o 今后的变更转入需求变更流程,其后产生的评审为小范围内评审。

  4#给出了一项检查清单,作为文档审查人员审查需求的参考检查表使用,大家可以在进行需求评审时参考使用。

来源于:http://www.51testing.com/html/42/n-108742.html


TAG: 需求评审

 

评分:0

我来说两句

Open Toolbar