对于To B的软件需求阶段，需求评审只是最后一道关，主要是前期工作要到位做足，在正式评审时候要讲究效率。
这里有几个假设：
1. 评委一定是不认真的。会前不看资料，会中不仔细听讲，会后撒手不管
2. 评委的意见一定是基于自身经验的应激性反应，不是经过深思熟虑之后的发问
3. 评委一定不是天才，他们都是某些方面有丰富经验的普通人。如果触发到他们经验的开关，也会给出非常好的意见和建议
因此，需求评审规范包含几个部分：
1. 需求的编写，要写明白需求
2. 组织评审会议的准备工作
3. 评审会议的高效进展
4. 会议之后的改进和沟通机制
其中2,4很多会议组织的规范里都讲了，我更看重1和3
需求的编写是重中之重。
首先要确保需求是整体的而非离散的。简而言之，就是必须有一个时刻在维护的需求树，从愿景开始逐层分解，所有的需求无论多细都应该在这棵树中存在位置。无法归纳到这个树中的需求就一定不是真实需求，要不就是树的分解有问题。一般需求分为业务需求，功能需求，系统需求和技术需求。业务需求满足的是客户的目标，功能需求满足的是用户的目标，系统需求满足的模块的目标，技术需求满足的是业务逻辑的目标。
其次，需求的描述必须是完整的，很多需求编写规范可以参考，大致是每个需求都有用户，有明确的业务和技术目标，有前后依赖关系，有具体的操作步骤，有例外情况，有些还包含算法说明。如果再分解下去发现没有用户了，或者用户变成了技术概念，说明业务需求变成了功能需求。
评审会议的时候，讲述非常重要。我们刚才说评委都是普通人，就意味着他们有和普通人的特点：对于陌生的事物，无法进行抽象的理解。所以，评审会议的讲述主要分为三个部分：
1. 概念部分。目的是向评委灌输产品的定位和来龙去脉，如果是新版本，则是表述我们遇到了什么样的问题，决定要在新版本中加入这些新功能。这个讲述逻辑一定是沿着需求树自顶向下开始讲，讲完业务需求，也可以到第一层的功能需求。
2. 产品的使用。所有的功能需求最好用原型配合进行讲解。讲解的次序不是原型的页面次序，依然是需求树中的顺序，按照功能在树中的排列次序，依次讲解，逐层深入。用术语讲就是在一个大功能内部采用广度优先而非深度优先的讲解顺序。广度优先的讲解顺序有助于保持听众的全局感。深度优先通常会引发一些不必要的争议，会打乱演讲的节奏。
3. 一些需要关注或特别说明的点。例如一些特别的技术攻关需求，一些复杂逻辑的专题说明等。
4. 最后是答疑部分。这个也在标准的会议议程中，不再赘述。
总而言之，如果真的想要有成效的需求规范，需求的一致性和完整性是核心，正确的讲述逻辑和次序是外表。如果想依赖评审给出什么特别的建议，一方面概率不大，另一方面表示需求准备阶段是失败的。