• 上下文：
           ××时间××项目进行的需求评审会：
             界面设计人员：

                          这个界面用户体验有问题，这样是不是更好一点！
                      DBA：
                         这个功能对数据库压力太大了，需要....
                      老板：
                          项目的目标必须是增加pv 100w....
                    结果：需求评审会变成了讨论会，经过n小时后大家都累的受不了宣布结束，择日再议。        
                 你越到过类似的问题吗？ 需求确认会变成了讨论会！我们得怎么办？     

• 解决方案：在需求的不同阶段召集不能的人员进行不同类型的评审，第一种是规模较小的内容评审，可能要进行多次；第二种是正式的团队评审，可能仅有一次，不对 正式的团队评审寄予太高期望

• 需求分析过程会有多次迭代，每次迭代产出都不同。

1. 刚开始业务流程产出时我们需要和业务部门确定业务流程是否满足业务要求；
2. 当领域模型出来是我们需要和架构，设计人员，需求人员讨论领域模型的合理性；
3. 当用例划分出来时我们需要和需求，业务人员确定用例是否包含了所有的功能范围
4. 当涉及到用例中具体的交互时我们需要和界面人员讨论交互的合理性。针对每个阶段到达一定程度，我们都可以发起阶段性评审。而不是到最后在和所有项目的涉众去确认。评审会的工夫都在会外