需求评审会是对需求进行澄清的机会。在需求评审会上，参与需求的各方对需求一起进行评审，从各自的角度对需求的疑问点提出问题。需求的提出方对各种疑问进行解答，对各种建议进行听取，然后根据意见修改需求的描述。理想情况下，需求评审结束后，通过短时间的修改，会出现一个较为完美的版本，交给开发和测试，进行相关的开发和测试用例设计工作。
但是，现实往往比较骨感。需求评审会结束后，需求的问题没有被完全发现，有的问题要到开发的时候才发现，因为不写到那段代码是无法提前预知哪个地方会有一个变量有可能为空，对于为空的情况要进行判断和处理。有的甚至到了测试阶段，集成阶段才发现有问题。
那么是什么导致了需求评审会的效果都没有这么理想呢？
那就要先剖析一下需求评审会到底是怎么开的。需求评审会往往是需求提出方讲解需求的内容，然后由各方根据自己的经验提出见解。问题就出在这个经验上了。经验是取决于人的，经验多的人就会想得全面一些，经验少的人就会想得不全一些。同样的，需求的书写也是依靠经验的。
有的人会提出不同的观点，我们有模板，可以确保减少遗漏。然而如果模板真的有效，就不会有这么多的问题发生了。其实模板问题在于，只能通过章节项目来确定内容上没有重大遗漏，但是到了具体的细节上，模板就无能为力了。仍然要依靠需求的书写者和评审会的参与者通过经验来进行弥补。
既然依靠经验不是可
标签：指南,需求,经验,召开,问题,评审会,模板,进行 From： https://blog.csdn.net/qqx52012/article/details/143499174