说来惭愧，这是我参加的第二个项目，心里有些没底，但是一个这么美好的愿景摆在面前没有退缩的理由是吧？！项目启动会议结束后我在我的笔记本上写上了几个字：忙碌的50天。后来一个同学看到了说该多加几个字，于是写上了：收获的50天。于是一切的忙碌和收获从需求分析开始了。

一、文档可以不多，但是一定要精

        之前所有参与过的项目都是从代码编写开始的，这次的不同从需求分析开始的，虽然不是全新的需求，却是全新的用户。开始的前两天只有自己在整理之前版本留下来的资料的时候就会发现基础系统的文档该有的基本都有，想要找些什么资料都会找到，这跟我在开会交流时听到的声音不太一样，因为其他小组都会说文档不全什么的，这点的感触很深，同样是开发，有的小组留下的文档很全面，有的小组只是有简单的一些内容的可用性很低。这里毫无抱怨之前版本的意思，只是觉得文档可以不是成百页的写，但是要有主要的内容，翻看之前自己写的文档就会发现很多都是官话，对后期系统的开发和维护有用的资料很少。只有一次一次的保留好文档版本就是留给后来维护人的巨大财富

二、一次分析并不能面面俱到

         现在看从项目启动那次开会开始的记录，第一次要求原型一天完成，十天过去了，我只能默默地说一声基础的原型还没有完全的定下来。

虽然第一天我们组也是如期完成了原型的设计，但是现在只能说那不是原型设计，只是画上一版本的流程，是对之前需求的一次了解，只是让自己的组员迅速了解基础系统需求流程的过程，一次的画画好之后交流，发现这样画一些没考虑到，再改，再商量，每天都会有新的改变，每天都想解决问题的办法，终于在上周五完成了原型的确定，几次的讨论几次的交流会发现，集体的力量很强大，就用那种头脑风暴的方式讨论需求，确定原型，会发现自己哪里想的不好，可以知道自己哪里想的比较到位，交流的过程就是创造的过程。现在再看第一次的设计，可能有的变动很大，有的基本没变，有的变了又变成原来的样子，但是可以自信的说最终的一个版本比第一次的版本可以应对更多的变化。

三、人多力量大，是在目标一致的基础上

         可能这一条与需求分析没有多大关系，却是我在基础系统需求分析的时候感触颇深的一点，java组的人不多，有5个人，有分歧的问题也是会讨论一会儿，因为也就是5个人最多5个观点，会有最终的结果，但是如果人很多，就会各说各的，每个人都有自己的观点，有自己的看法，这样没人说一句会议也会维持一个上午，会议结束时很多观点都忘记了，所以人多并不是一件好事，个人觉得分组讨论才是最好的选择，这样可以组内可以短时间达到观点的一致，然后小组长拿着本组的观点再交流，人多，且目标一致力量才足够大！不然怎么每个公司都有层次之分，而不是总裁直接管理每一个员工呢？！

      50天的工期，需求分析用了近五分之一，上次师哥师姐回来也说，前期的工作很重要，只有设计的好了，后期工作才会如鱼得水！