51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3651|回复: 3
打印 上一主题 下一主题

[讨论] 如何做好需求评审?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2006-3-28 19:25:55 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
需求评审的重要性大家都知道,我简单列出几点:
1.软件需求是软件开发最重要的一个输入 ,好的开始是成功的一半! 所以,需求的质量很大程度上决定了项目质量或产品质量。
2.需求风险常常是软件开发过程中最大的一个风险 ,要降低需求阶段带来的风险,就要把需求评审做好。
3.需求评审做不好的后果:
需求变更
需求不明确
需求不可测
需求不可实现
导致后续工作难于开展或经常出现变更。
4、产品经理:不识庐山真面目,只缘身在此山中,需求是自己写的,容易受到固定思维的限制,所以,需要一双没有看过这个需求的眼睛来检查一下,有什么问题。

先大概说一下需求的不同类型:
需求的不同层次:
目标性需求:定义了整个系统需要达到的目标;
   -高层关注
功能性需求:定义了整个系统必须完成的任务;
   -中层关注
操作性需求:定义了完成每个任务的具体的人机交互;
   -执行人员关注

在做需求评审的时候,应该根据不同的需求层次,进行不同的评审。

因为经常参加需求评审会议,所以对需求评审中常见的问题有所了解,现在举一些例子:
1、某产品经理在主持需求评审会,评审开始时间不长,就被一位主管打断,明确指出此方案与企业业务发展方向不符,不能实施。紧接着其他与会人员纷纷发言表示同意,结果评审会无法继续进行,需求最终被否决。
问题所在:
缺乏初步沟通,目标性需求尚未明确,功能性需求和操作性需求无从谈起。

2、某次需求评审会,主要是公司内部相关领域的专家参加,在评审会开始后不久,某专家就对需求中的某个具体问题提出了自己的不同意见,于是,与会人员纷纷就该问题发表自己的意见,大家争执不下,结果,致使会议出现了混乱状况,主持人无法控制局面,会议大大超出了计划评审时间。
问题所在:
前期沟通和准备不够,缺乏应对不同意见的准备,难以化解争执。
主持者不能有效把握会议目标,会议讨论过于关注细节,导致评审失控。
3、某产品经理主持需求评审会,在讲解需求说明书时,与会人员似懂非懂,没有提出任何有价值的问题,致使会议没有得到预期效果,不得不改日重新进行。
问题所在:
前期准备和沟通不够,评审变成了培训。
没有选择合适的评审人员,无法获得有价值的信息。

4、某需求评审会,与会人员各抒己见,气氛热烈,产品经理忙于收集意见,结果散会时发现对需求有价值的并不多,并且遗漏了许多要评审的问题,评审效果不佳。与会人员在离开会议室后,私下也认为评审没有多少实际效果,完全是在走过场。
问题所在:
评审缺乏有效依据和规范,不能保证评审的覆盖率和有效性。
产品经理没有把握好会议主题,评审变成了头脑风暴。

需求评审常见问题汇总
目标性需求没有沟通好,后面的需求变成空中楼阁。
缺乏评审的可操作依据,遗漏评审内容。
没有作好前期准备工作,导致评审时间长,效率低。
没有选择合适的评审人员,无法获得有价值的反馈。
参加人员过多,容易陷入细枝末节的讨论,会议演变成一场人人自由的混战。

针对以上问题,提出一些建议:
建议一、做好评审前的沟通和准备
需求编写人员应将评审所需的资料准备齐全,数据、图表、其他相关资料等,并仔细检查以保证文档质量。
需求文档在评审会议前应提前下发给参与评审会议的人员,并留出时间让参与评审的人员阅读需求文档。
参加评审的人,应该是带着问题而来,而不是来参加培训的。

建议二、先沟通好目标,再进行细节的落实。
应该在需求形成的过程中进行分阶段的评审,而不是在需求最终形成后再进行评审。
分阶段评审保证了需求在形成的过程中不偏离方向,不出现大的错误,降低了需求返工的风险,提高了最终评审的质量

建议三、正式评审与非正式评审相结合
正式评审
是指通过开评审会的形式,组织多个专家,将需求涉及到的人员集合在一起,并定义好参与评审人员的角色和职责,对需求进行正规的会议评审。
非正式的评审
通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。 两种形式各有利弊,因此在评审时,根据项目复杂程度,紧急程度不同,应该灵活地利用这两种方式。

建议四、精心挑选评审员
为了保证评审的质量和效率,需要精心挑选评审员。
首先要保证使不同类型的人员的都要参与进来,否则很可能会漏掉了很重要的需求。(测试经常被遗忘哦!)
在不同类型的人员中要选择那些真正和系统相关的,对系统有足够了解的人员参与进来,选择有经验的,而不是有时间的人。(teamleader选择参加,主要执行人员必须参加!针对评审目标选择参与者,避免高、中、低层一起评审。)

建议五、充分利用需求检查单
使评审有可操作依据,提高评审有效性,避免遗漏。
便于收集评审数据,记录评审结果

建议六、做好评审后的跟踪工作
切忌评审完毕后,没有对问题进行跟踪,而无法保证评审结果的落实,使前期的评审努力付之东流
发送项目状态通知,让相关人员周知需求评审已完成。
说明需求经评审后改动的部分,如实现优先级、加入和裁减了哪些。
针对评审结果对需求进行完善,并保证相关人员获得最新版的需求文档


另外,关于开会说几点:

为什么会议时间过长?
前期沟通不够,把应该花在前期沟通上的时间,用在了会议上。
自己准备不足,比如资料不全,不准,数据准备不充分等,不能说服与会人员,陷入争执。
不能把握会议主题,偏离目标。

说了这么多,希望能对遇到过相似问题的朋友有所帮助。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2007-4-26 14:51:47 | 只看该作者
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2007-4-27 15:10:57 | 只看该作者
sdlkfj3
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2007-4-29 22:14:34 | 只看该作者
好贴
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-16 14:40 , Processed in 0.067124 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表