需求是不断更新的，当客户加上某点或是删去某点功能，需求变更随时都可能发生。需求的开发是贯穿整个开发过程的，不是做测试计划前就完成。这是一个不断循环迭代的过程。
需求验证活动可以确保需求符合优秀需求称述的特征，并且符合好的需求规格说明的特征。
因此，在部分需求确定下来时，就对这些已经发现的需求进行评审和测试，尽快开发测试用例，就能够及早发现需求方面的缺陷和问题，这样就可以只用较低的费用解决这些问题。
若是在测试结束后，才发现遗漏了某个重要需求；对于某个不是很重要的需求，开发过程中却将其作为重点等等这些问题，那么这个损失就巨大了，需要开发人员重新开发，甚至于重新回到原点，这样将耗费巨大的人力物力。
软件工程正式的技术评审知道原则有哪些?
需求评审对于软件测试人员来说就像是最初的“产品测试”，在理解的基础上发现产品设计上缺陷，其中包括逻辑错误，功能缺失，细节问题等等，这样就会有效的在前期规避很多后期开发中产生的bug，减少了很多后期返工的成本。可偏偏需求评审往往是最不重视的一环，甚至可以说是没有这个环节，追其原因无非因为项目时间紧迫或者觉得没有必要，其实这是本末倒置和得不偿失的。
产品需求作为程序的源头，只有控制好最开始部分，才不会到最后去亡羊补牢。我有过很多血的教训，所以才深深的体会到需求评审的重要性。
说了需求评审的重要性，接着就来谈谈如何进行需求评审，一般还是分为3步：
第一步就是要完全读懂产品需求，这个过程只需要理解而不是去挑刺，因为要明白这个需求的目的是什么，为什么这样做，怎么做等等，只有在理解的基础上才能去发现问题，而不是一知半解的去挑毛病，有些需求设计的是不合理，但也许有其特殊的用意，或者只是没有更好的方案，不能为了挑毛病而去挑。
第二步就是分析和找问题；这就有点类似写测试用例的时候设计测试方案了，把逻辑梳理出来，看看有没有不对或者遗漏的点，整理出来反馈给产品经理。除了考虑有问题的地方，没问题的地方也是需要分析的，比如有些设计非常合理，但会增加代码的复杂度或者不利于后续的扩展和修改，同时也可能会给测试带来成倍的工作量，这些也是需要指出的，因为测试要考虑的东西一定要比产品经理多，用户使用习惯，程序复杂度，与线上系统的兼容性等等，不然直接让产品经理做测试不就好了吗？
第三步就是细节问题的纠正，可以是界面，可以是文字，开发一般都是复制黏贴或者照着样子画葫芦，这些小问题后期其实也可以测试出来的，但其锅不在于开发，早点发现问题早点解决也是好事一件，至少不用提bug走一套bug处理流程了，也算给大家省点工作量，积少成多也是极好的。
当然需求评审能解决的问题也是有限的，一方面计划往往赶不上变化，中间会有部分需求的改动，另外一方面有些深层次的问题只有在测试之后才会发现。但无论如何对于测试来说还是非常有必要的，如果能重视起来不仅仅对项目的效率提高不少，而且也能让后期测试压力减小，何乐而不为呢？
技术评审(Technical Review,TR)的目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除
缺陷，从而有效地提高产品的质量。包括有正式技术评审和非正式技术评审。
正式技术评审的原则：
作者答复评审员的问题，
并与评审员共同查找缺陷、商讨缺陷解决方案。评审结束后，作者应当及时消除工作成果中的缺陷。
1.要有严格的评审计划，并遵守日程安排。
2.
评审小组
☆ 评审主持人应当具备比较高的技术水平和比较丰富的评审经验，能够控制评审会议的进程。评审主持人可以是项目内的技术骨干，也可以是项目外的技术专家。评审主持人本身是一名评审员，评审结论必须有评审主持人的签字才能生效。
☆评审员主要来源于项目内和项目外的技术人员，必要时还应当要求客户和质量保证人员担任评审员。
工作成果的作者不能担任评审员。
评审员的人选以及分工都由评审主持人来确定。
评审员应当根据“检查表”认真地查找工作成果中的缺陷，并和作者共同商讨缺陷解决方案。
☆评审小组的总人数一般在3~7人之间。
记录员：由评审主持人指定一位评审员来担任记录员。记录员如实地将评审过程记录在指定的文档中。
