关于需求评审
1、 传统的软件开发模式中，太过依赖文档，有各种各样的文档，需求说明书，比如市场需求说明书，业务需求说明书， 软件概要说明书，软件详细设计文档等等，这些文档在追求速度的时代却似乎效用不大，很多时候反而成了负担。怎么解决这个问题？
去掉无用的功能定义文档、需求文档可行方法：
想法快速制作成静态的原型->>根据“市场效果反馈”修改原型设计->>用真实数据建立一个动态原型->去除累赘
这样，以实际的界面或原型来说明你要构建一个真正的产品，是很好的方法。
从这个点出发，我们可以把重心从“需求文档评审”转移到“原型(Demo)评审”,以原型评审为中心，辅以必要的文档说明，作为原型的补充。
2、 三方协作
也就是说，每项功能需求的讨论都要开发人员，测试人员，产品人员的参与，有参与才有认同，开发前必须达成一致
3、各种评审会上，一定要有个能做决定的人，因为评审的时候各方不可避免地会对需求有不同理解，从而出现争论，公说公有理，婆说婆有理，谁也说服不了谁，会议相关人都要参与
