参考博文：http://blog.csdn.net/yqmfly/artide/details/7679781
读完这篇博客，主要归纳了三方面的内容：需求调研、需求分析、需求确认
1.需求调研
1）树立良好的职业威信；
2）进行详细角色分析，将与会各方代表对号入座；
3）从宏观上制订目标与方案。随后的工作，就是与各方代码建立联系，逐一拜访他们，将需求调研工作一步一步进行下去。
这是这篇文章给出的建议。
初识：
初次接触客户，对于项目团队意义重大。对方对你印象的好坏，今后如何与你交往，都在这个阶段被确定下来。所以拥有一个良好的语言沟通能力是非常重要的，也是我们以后要学习的重要的一方面，只有良好的沟通才能更大的了解客户的需求，为软件的完善提供了很大的帮助。就比如这篇文章说对待客户的态度要谦虚，但谦虚并不是唯唯诺诺，也要掌握主导权，不能被客户牵着鼻子走，所以适度谦虚也要学习，总之沟通。
开展项目会议：
调查也要有目标性，调查的范围和问题都要有针对性，这样更能加快效率，不能漫无目的的调查，这样只会事半功倍。将项目负责人以及客户代表聚到一起开需求研讨会是非常重要的，在研讨会上可以详细地对项目进行需求分析，将客户聚到一起一方面可以将各个部门的客户的需求统一化，避免每个部门的需求不一致，导致项目需要开发很多的版本，导致项目太大开发困难而且不容易维护；另一方面可以将各个部门的需求进行分析，取长补短，从而制定一个好的项目。
2.需求分析
1）、功能角色分析与用例图
我们应根据需求分析角色，分析出各个角色的功能，绘制用例图，其中包括参与者、用例与系统边界。用例图是提供给客户看的，所以不应该出现技术性较强的表达方式，一定要清楚明白，简单易懂，这样才会让客户了解我们了解到的需求，并提出修改意见。和上学期学的统一建模还是很有联系的。
2）、业务流程分析
应根据需求对业务流程进行分析，分清系统外和系统内，将需要信息化管理的部分进行开发，不需要信息化管理的部分则不开发，使软件真正地实现提高工作效率，而不是加重负担。
3）、用例说明
在进行业务流程分析时绘制用例图能够生动形象地描述我们的分析，但是其会丢失很多信息，所以我们需要有一些文字的描述，就是用例说明。
4）、查询报表分析
我们应根据需求实际设计不同的查询报表，报表的内容应符合客户的需求，对必须的内容要加上，不需要的可以删掉。
5）、子用例与扩展用例
在基本流程中将多个用例所共有的，可以相互共享的流程，将这些流程提取出来就是子用例，这样提取公共部分提高了系统的内聚降低了系统的耦合。
6）、行动图和状态图
用例图只是描述了某一个用例自己的功能，而各个功能很分散，没有联系，所以需要行动图和状态图来将各个模块组织起来，来对业务进行整体的描述。状态图描述了业务流程状态的转换，可以清晰地展现各个业务流程。
7）、业务领域分析
业务领域分析就是通过与该业务领域的专家进行学习，了解该领域的一些基础知识，然后构建该领域的知识体系，了解该领域需要什么实体，并可以对业务流程更加熟悉，有助于在项目开发中进行参考，从而提高项目的正确性和提高项目的开发效率。
8）、原文分析法
原文分析就是分析需求的原文，提取出业务领域的名词，对名词进行分析提取出业务领域的实体。
9）、非功能需求
非功能需求包括可用性、可靠性、性能、可支持性以及其他，非功能需求时需求人员非常容易忽略的，但是确实对软件开发非常重要的，某一方面考虑不周全，可能会导致软件的失败，例如界面不友好，性能差，支持性差等都会导致客户不想使用导致软件开发的失败。
3.需求确认
1）.需求列表：又称之为需求跟踪表，是最原始的、用户对业务需求的描述
需求确认是一系列的确认过程，每次确认都可能需要与不同的人，在不同层次的确认。最终应当形成到纸面，形成文档性的东西，双方签字确认。这个过程中可以采用的一个好的方法就是原型法，最终产物应当是需求列表与需求规格说明书，最后结束于一场需求评审会，或者签字确认会。
2).一个需求列表的实例
3）评审与签字确认会
4）需求规格说明书
5）快速原型法
通过上面三部分进行总结，个人觉得我现在应该在需求调研上多花功夫，因为自己的表达能力有待提高，而且软件需求报告规格说明书还是很重要的，写文档，组织语言表达能力。