对工作产品的评审有两类方式，一类是正式技术评审，也称同行评审，另一类是非正式技术评审。对于任何重要的工作产品，都应该至少执行一次正式技术评审。在进行正式评审前，需要有人员对其要进行评审的工作产品进行把关，确认其是否具备进入评审的初步条件。

　　需求评审的规程与其它重要工作产品(如系统设计文档、源代码)的评审规程非常相似，主要区别在于评审人员的组成不同。前者由开发方和客户方的代表共同组成，而后者通常来源于开发方内部。

　　有人问：需求评审究竟评审什么?要细到什么程度?怎么样进行?

　　严格地讲，应当检查需求文档中的每一个需求，每一行文字，每一张图表。评判需求优劣的主要指标有：正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性、可验证性、可测性。如果有可能，最好可以制定评审的检查表。

　　需求评审面临的困难及对策如下：

　　需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后头越马虎。当需求文档很长时，几乎没人能够坚持到最后。会议主持人事先要强调需求评审的重要性：认真评审一小时可能会避免将来数十天的“返工”，让大家足够重视。评审组长还要设法避免大家在昏昏沉沉中评审。如果评审时间比较长，建议每隔两小时休息一次。另外，如果系统比较大，也可以细分成不同的部分分别进行，严格控制每一次评审的文档规模及持续时间。

　　需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易(例如有些人可能出差在外，有些人可能事务缠身)。没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。对于需求的工作产品《需求规格说明书》，我们可以标明几种文档状态，如草稿状态。评审状态，初始状态等。只有进入评审状态时，我们可以用不同的方式来对文档进行评审。但当其评审状态转化为初始状态时，需要进行严格的正式的同行评审。

　　开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。对于自主研发的产品，由于需求评审人员大部分是开发人员，大家会不知不觉地谈论软件“如何做”。由于需求是否“可实现、可验证、可测试”本来就属于需求评审的范畴，所以强制大家“只谈做什么，不谈怎么做”几乎是不可能的。那么，在需求的评审会上，需要允许开发人员谈如何做，但不需太细，适而可止。同时，评审会必须明确一位评审组长，对时间与问题进行控制。

　　开评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞成要好。然而当争议变为争吵时就坏事了。争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。同时也解决不了问题。所以，在评审会的过程中，我们要尽可能的是在阐述事实与证据，而并不是从你心底要如何地说服别人。

　　人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是好办法。我们应当养成良好的习惯：不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案。试著从不同的角度去看同样的问题。