分享一下我老师大神的人工智能教程!零基础,通俗易懂!http://blog.csdn.net/jiangjunshow
也欢迎大家转载本篇文章。分享知识,造福人民,实现我们中华民族伟大复兴!
需求验证的5大要点
要做好需求验证,必须在思想、方法、语言、人员、内容5个要点上做好相应的工作,否则就会产生很多负面的影响。
1.思想
前面已经说过,由于Review被翻译成“评审”,导致很多人将其与中国人常说的评审相混淆,其实它们之间是有区别的:中国人常说的评审是评价,而Review应该是复查,是发现问题。这一点,必须成为所有组织、参加需求评审会的人员都应该建立的统一认识。
隐喻:
当测试团队严肃、认真地对你说:“经过我们三天时间的测试,发现你提交的程序一个Bug也没有!”请问你会作何理解呢?
A、我的程序很牛!
B、这个测试团队的方法或态度有问题。
我想很多人会选择B吧!因为“人非圣贤,孰能无过!”应该是测试手段还存在问题,导致潜在的问题没有被暴露。
可是,“我的需求评审通过了!”之类的话题总是被许多需求人员以很开心、愉快的方式说出来,我怎么听怎么觉得像听到“我的程序真牛!”。
就像我们不是想花大量的测试成本来验证自己的程序无错一样,采用成本昂贵的评审技术也不是为了验证需求文档是无错的,而是帮助我们尽早地发现问题、找到错误,避免因问题被延误到后期解决而付出惨痛的代价。
SERU诫语8-1:需求验证的目标是尽可能暴露问题,而不是证明无错。
2.方法
统一了思想之后,接下来的重点就是“方法得当”。
SERU诫语8-2:在企业中推行即时评审、同级桌查等正式化程度不高的评审手段,是创建企业评审文化的有效手段。
3.语言
SERU诫语8-3:在评审会中,不要用“评价者”的口气谈论你的观点。
4.人员
要开好评审会,选择合适的参与人员是很重要的;要点在于合适,而不是越多越好。具体来说,包括三个方面的要点:
同级:别忘了,在CMM/CMMI中提到的是Peer Review,Peer就是同级,千万不要一开评审会就请高阶领导。
该来的人要请:也就是评审的内容所涉及的第一责任人,要想办法请他们参加。
不该来的人不要请:也就是评审不是越多人参加越好的,通常应该保持比较小的范围,要直接相关的人员参与;一方面可以保证参与者对评审内容熟悉,另一方面也可以保证参与者关心评审过程。
SERU诫语8-4:参加需求评审的人不是越多越好,一定要保证同级、适合。
5.内容
建议大家控制在9条之内,理由就是心理学中的“7±2” 原则,也就是人们容易记住的信息条目在5~9条之间。因此大家也可以根据实际的情况做一些变通。
除了要对缺陷检查表的规模进行压缩之外,还应该对评审的需求规格说明书进行压缩。根据笔者的经验,一个较熟悉的团队,要对需求进行相对有效的评审,应该控制在每小时30~40页之间。
那么在实际的工作中,我们如何对需求文档进行切分呢?是开一个时间周期很长的评审会,还是多次时间周期较短的评审会呢?似乎这两种方法都不尽可行。
解决该问题的关键在于必须对需求规格说明书进行拆分,根据读者的层次、所关心问题域的不同进行拆分,具体的方法我们在第4~6章中已经做了很多说明。
SERU诫语8-5:评审时要确保评审内容、缺陷检查表的规模适合,内容应该按每小时30~40页的速度来准备,缺陷检查表尽量在9条之内。
上述文字摘自于 徐峰老师 编著的《
软件需求最佳实践</