阅读‘王’推荐的博客之后，有一点点收获吧，也许再以后的开发中会有一点点作用，但是我觉得该亲身经历的永远无法避免！！附上博客地址
http://blog.csdn.net/yqmfly/article/details/7679781
收获1 吧！开发小总结 作者亲身经历了东软的例子开发 据说某天早上，客户对某个功能不满意，他们不得不对几百处程序进行修改。之后客户对修改的内容还是不满意，又不得不将几百处修改重新改回来。最后这个项目导致的结果是，整个这个项目组的所有成员都离开了东软，并似乎从此不愿涉足软件开发领域，很惨痛的例子，当然根据下文的例子也让我了解了一些开发时与客户怎么交流 当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了，如果，刚开始时，就被客户牵着鼻子走，一方面我们的专业性感觉被忽视了，一个不懂计算机的和编程的成了项目总的思想，软件做好便很难了！！当然客户由于不懂开发之中的事情，其中等同的工功能实现，也许会难以实现！总之，做软件之前要与各个部门交流沟通好，深入了解客户需求，一个软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。需求调研的初期需要召开项目动员大会，这是十分必要的。但真正要完成需求分析，应该是一个一个的小会，1~3个业务专家，只讨论某个领域的业务需求，并且很多问题都不是能一蹴而就完成的，我们必须与专家建立联系，反复沟通后完成。需求分析必须遵从的是一定的科学方法，而不是盲目的大上快上。
收获2 吧 如何做好需求调研！
在客户至上的今天，与客户保持适当的谦卑是有必要的，但过于的谦卑却常常给项目日后的进程带来风险。为什么这么说呢？过于的谦卑，处处都是诺诺诺，客户说什么就是什么，就会使客户变得非常强势。这样的结果就是，客户提出了许多变态的、不太现实的、不合理的需求，而我们呢却是一味地服从，客户说什么就是什么。最后我们做得很累，结果却不能让客户满意！！！！起初的唯唯诺诺，客户说啥就是啥，必然造成客户不再关注你的意见，对你发号施令就可以了。相反，起初展现出一位技术专家的姿态，能大方而得体地提出自己的意见，会使客户重视你的意见，甚至主动征求你的意见。这一方面要求我们对自己要有足够的自信，另一方面也要有循循善诱的表达能力。如果我们做到了这些，就会客户心目中形成一种威信，使项目向着一种良性的方向前进！！
调研需求时 和高层领导谈一些大题的功能，高层领导关注是一些宏观问题，不在意那些细枝末节！！之后便是中层领导，中层领导是各项业务流程、功能模块的需求决策者。他们关心功能的定义、业务流转的衔接、查询报表的设计，但不太关心一些具体的操作，以及一些具体业务流程的细节；最重要的也是底层人员，基层人员往往受到自身视野的局限，可能只清楚自己工作涉及的十分狭小的一个范围，因此我们需要努力寻找那些业务涉及面广，经验丰富，又有一定大局观的真正的专家，接下来就是拜访 我们也不能总是期望客户中的所有人都能与我们合作，很多项目都不可避免地存在阻碍项目开展的人！！分析一个客户人群的关系，就是在分析这个人群中，谁有意愿支持我们，而谁却在自觉不自觉地阻碍我们。那些通过这个项目可以提高政绩，提高自身价值的人，都是我们可以争取的盟友。他们是我们最可以依赖的人，我们一定要与他们站在一起，荣辱与共，建立战略合作伙伴关系。另一种人，即使软件获得了成功，也与他没有太多关系，但你与他相处得好，却可以给予你巨大的帮助，这种人是我们需要拼命争取的人。所谓领域专家，他可以给你多讲点儿，但随便打发你，对他也没太大影响。报着谦虚谨慎、相互尊重的态度，大方地与他们交往。当他们帮助我们以后，真诚地予以感谢。这是我总结出来的，与他们交往的准则。最后，就是那些对我们怀有敌意的人。尽管有敌意，但我们能够坦荡的，敞开心扉的与他们交往。虽然不能奢望太多，但拿出诚意去争取他们，也还是有机会化干戈为玉帛、化敌为友。
业务研讨会 业务研讨形式比较容易出现的另一个问题，就是将各个方面的业务代表拉过来开大会。在大会上，你说你的，我说我的，杂乱无章，一些重要的需求被不经意地漏掉。遇上这样的情形，项目经理应当有清醒的认识，我们需要再下来开小会。销售部门的需求跟销售部门谈，采购部门的需求跟采购部门谈••••••既然是小会，每次谈的时候人不在多，在精，参会的业务人员对自己的业务了解精细而全面。这样的会议，通常有一至三个业务人员，和一个负责人（负责拍板）参加。会议之后，我们最好询问与会人员的联系方式，便于日后建立长期的联系，毕竟业务需求不是一蹴而就的事情。同时，如果我们今后采用的是迭代式开发，他们也就成为了我们业务验证的客户代表！！需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控
第五迭代，这是我个人觉得最需要也是最重要的部分一个项目不是一次就能实现的，反复的讨论和循环：需求捕获->需求整理->需求验证->再需求捕获••••••需求捕获和需求整理的内容在博客中也做了详细的解释，需求分析就是按照这样的过程，每次多理解一些，再多理解一些，更多理解一些，逐渐深入的过程。每深入一步，我们的软件就更接近客户的满意。
第六用例图，大二上半学期学过了用例图，但是至于掌握了什么就只能用XXXXXXXXXXXXX来形容一下，曾经我也慰问过大三大四的说用例图有用吗？他们说自从考过没有学过！！，我以后还会再重复学习一遍了，毕竟各种图都分不清！！
第七还是各种uml图，现在才发现它的重要性，希望以后还可以补回来，确实很便捷。还有规格说明书，我以为以后没用的！！！
最后 双方领导在需求规格说明书上签字，项目开始进入一个新的轮回。在这个轮回中，是焦头烂额、不胜其苦，还是如履薄冰、最终顺利交付，是与许多因素有关的。但我想说，一份高质量的需求分析必定起到决定性的作用，必定为日后的软件开发扫清了许多许多的地雷。
一些小小的感触！！感觉自己差的很远很远！！！！！！........具体以后如果有机会的话我会引以为戒！！也有一些人不撞南墙不回头......走着瞧