更好的进行需求评审

    最近，一次偶然的机会，被领导安排了开发系统的任务。想想，有时候觉得自己这一路走来真不可思议。从一个大学毕业时，只会用电脑上网，聊Q，玩游戏的大白菜，变成现在，做测试，做开发，做项目管理，呵，人生，真的如我QQ签名一般"人生就像做801公交车，投一块钱的时候查票，投两块钱的时候，大多遇见了查票......"。

    这次开发的任务是在已经基本成型的平台上进行二次开发，最终的目的就是在该平台上实现公司的项目全生命周期管理。为公司的项目积累数据的同时，更多的我想是为了达到CMMI 4级 量化管理级。

   这一段时间，主要的工作放在了需求的收集和整理上，之后就发起对于需求的评审，鄙人不才，不慎被选中。但在本次需求评审的过程中，我发现了有这么个问题：出于对需求的熟悉，从而避免实现和设计过程的逻辑错误，领导把相关的参与者都纳入了会议。同时，需求的讨论是分段增量讨论。这样问题就出现了，我跟几个哥们，对于前几天讨论的需求所涉及的业务基本都不清楚。基于此，我们在参与此部分的需求讨论时，基本都是接收，机器式的接收，也提不出什么意见。不知道他们怎么样，至少我还是对于那一部分的需求不清楚。

  另外，评审的需求文档本身来说，中间存在描述不清晰的问题，编写者已经站在一个对业务相当熟悉的角度，从而中间省略了很多内容，这样也不利于对相关业务需求不熟悉人员之前的预评审过程。从而这里的评审，的确是浪费了我们哥几个的时间。

   针对以上的问题：我认为，要做好需求评审应该做到以下几点：

  1.作为评审输入的《需求规格说明书》，文档的描述要清晰，易读，前后一致，完整。

  2.需求正式开始之前，发起相关活动的预评审活动，给相关人员预留一定时间的预评审活动，正式会议评审时，应该出具相关的预评审发现的问题清单。

  3.参与需求讨论的人，应该熟悉所讨论的业务需求，否则将出现鸡同鸭讲的情况。

  以上为个人观点，不周到之处欢迎拍砖