这里有几个假设：
1. 评委一定是不认真的。会前不看资料，会中不仔细听讲，会后撒手不管
2. 评委的意见一定是基于自身经验的应激性反应，不是经过深思熟虑之后的发问
3. 评委一定不是天才，他们都是某些方面有丰富经验的普通人。如果触发到他们经验的开关，也会给出非常好的意见和建议
1. 需求的编写，要写明白需求
2. 组织评审会议的准备工作
3. 评审会议的高效进展
4. 会议之后的改进和沟通机制
需求的编写是重中之重。
其次，需求的描述必须是完整的，很多需求编写规范可以参考，大致是每个需求都有用户，有明确的业务和技术目标，有前后依赖关系，有具体的操作步骤，有例外情况，有些还包含算法说明。如果再分解下去发现没有用户了，或者用户变成了技术概念，说明业务需求变成了功能需求。
1. 概念部分。目的是向评委灌输产品的定位和来龙去脉，如果是新版本，则是表述我们遇到了什么样的问题，决定要在新版本中加入这些新功能。这个讲述逻辑一定是沿着需求树自顶向下开始讲，讲完业务需求，也可以到第一层的功能需求。
3. 一些需要关注或特别说明的点。例如一些特别的技术攻关需求，一些复杂逻辑的专题说明等。
总而言之，如果真的想要有成效的需求规范，需求的一致性和完整性是核心，正确的讲述逻辑和次序是外表。如果想依赖评审给出什么特别的建议，一方面概率不大，另一方面表示需求准备阶段是失败的。
1. 这个形式主义的说法 https://baijiahao.baidu.com/s?id=1657592380716314568
2. 这个讲到了一些本质的东西 https://zhuanlan.zhihu.com/p/319447037
3. 软件需求分层处理的多种常见方式 https://blog.csdn.net/zhangmike/article/details/49529587