本学期刚刚开始，这学期也继续开始新课程的学习----需求分析。本文是对博客《我们应当怎样做需求分析》（网址链接：http://blog.csdn.net/yqmfly/article/details/7679781）的阅读感想以及对本学期《软件需求分析》需要掌握内容的小小的总结以及自己的理解。阅读这篇博客的前几部分内容之前一直觉得需求分析的作用不大甚至不清楚为什么做需求分析更不知道怎样做需求分析了。阅读前几段落后发现做需求分析的重要性，其实最重要的谁也不想去改已经编好的代码，所以做软件之前做好需求分析就显得尤其重要了。那，到底怎样做需求分析才能真正满足客户要求，使其满意？
首先要进行需求调研：
初识客户——拜访——研讨会—— 需求调研——迭代——需求捕获：
初次接触客户，对于项目团队意义重大。与人交往，往往在接触的初期就决定了相互的行为方式，与客户交往也是一样。对方对你印象的好坏，今后如何与你交往，都在这个阶段被确定下来。在客户至上的今天，与客户保持适当的谦卑是有必要的,树立良好的职业威信；不能唯命是从，顾客就是上帝，一切都要服从上帝，这样是不现实的。我们应对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。这样更利于以后的开发。当然在交谈中要进行详细角色分析，将与会各方代表对号入座，最后从宏观上制订目标与方案。
做好初步认识之后，接下来就要一一去拜访这些对应角色了。需求不是一蹴而就，在这漫长的时间里，我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求，这都需要有良好的客户关系。软件供应商与客户建立的是长期供应的战略协作关系，这更需要我们与客户建立长期友好的关系。我们一定要与他们站在一起建立战略合作伙伴关系。报着谦虚谨慎，相互尊重的态度，大方地与他们交往。当他们帮助我们以后，真诚地予以感谢。经过一番交往，我们将举荐在客户中结实一批可以帮助我们的人。在今后一段日子里，我们将依靠他们学习和认识业务知识，手机业务需求，为今后的软件研发提供素材。
这也是很重要的。将项目负责人以及客户代表聚到一起开需求研讨会是非常重要的，在研讨会上可以详细地对项目进行需求分析，将客户聚到一起一方面可以将各个部门的客户的需求统一化，避免每个部门的需求不一致，导致项目需要开发很多的版本，导致项目太大开发困难而且不容易维护；另一方面可以将各个部门的需求进行分析，取长补短，从而制定一个好的项目。保证项目的顺利进行。
这是与客户进行软件功能需求的讨论，不同的客户对我们专业的了解程度不同，所以对于软件本提出功能需求的能力不同，对于开发不了解，有的人提出的问题是无法解决的 ，碰到这些，我们没有办法解决的情况下，我们就要努力的说服客服接受我们的方案。我们做需求分析，眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。
需求分析不是一蹴而就的，是一个反复迭代的过程.它将从第一次需求分析开始，一直持续到整个项目生命周期。我们在一段时期内需要与客户进行反复地讨论，这个过程往往是这样一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获••••••
没有捕获哪来后面的整理与验证工作？需求捕获是这个迭代过程的开始，也是整个需求分析工作中最重要的部分。我们不能只是被动等待顾客放映，我们应主动地从客户那里捕获需求，不能被动地捕获，这样可以有效地分析客户业务的详细流程，
之后就是需求分析
需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司，我们就应当对需求调研的成果进行一次需求分析。需求分析不是一项一蹴而就就可以完成的工作，它需要一个长期的过程，而这个过程是一个由粗到细的过程，它体现了人类认识事物的客观规律。
1.功能角色分析与用例图
我们对需求的分析，首先应当从功能角色分析开始。对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。在一个用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary）。功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。用例图是贯穿整个面向对象分析/设计（OOA/D）的核心视图，它描述的是系统到底为用户提供了哪些功能，以及到底是哪些用户在使用这些功能，是沟通用户与技术人员的桥梁。运用用例视图对业务需求进行分析、抽象、整理、提炼，进而形成抽象模型的过程称之为用例建模，而这个模型就是用例模型。
2.业务流程分析（细化需求也需要一定的方法与思路。一般来说，我们可以有两个方向细化需求：业务流程分析与业务领域分析）
我们进行业务流程分析，就是要分析业务流程中哪些是需要信息化管理的，而哪些则不需要。信息化管理过细，无疑会加重基层业务人员的负担（这也正是为什么许多基层业务人员会排斥信息化系统的原因），而适当的信息化管理则可以提高工作效率。我们可以进行我们对流程改进的分析：清除低效环节、简化业务瓶颈、整合可用资源，以及将繁琐任务自动化。
3.用例说明
图形的最大优势是能够形象生动地描述我们的分析，但它最大的缺点是会遗失许多的细节信息，因此我们必须要对它进行进一步的文字描述。对该用例的功能定义、要实现的业务需求，以及谁（参与者）应该如何使用进行描述。同时，这部分还可以整体概述实现业务需求的主要流程，以及与其它用例、其它外部系统的关系。通过用例描述，阅读者可以对该用例有一个整体的认识。
4.查询报表分析
对于些查询、汇总与报表功能，需要我们描述的是那些数据项、数据来源、报表格式、数据链接，以及使用者、使用频率的说明。那么我们需要写一个查询报表。一个报表的核心就是展现给客户的报表格式，以及报表与报表间的各种链接。
5.子用例与拓展用例
子用例和拓展用例在基本流程中将多个用例所共有的，可以相互共享的流程，将这些流程提取出来就是子用例，这样提取公共部分提高了系统的内聚降低了系统的耦合。
6.行动图和状态图
用例图并不能最好最全面的描述，所有我们还需要行动图和状态图。行动图（Active Diagram），比较类似于我们过去绘制的流程图，是UML中描述流程与分支的视图。状态图就是对关键对象中流程中状态变化的描述在需求分析中，状态图并不是必须的，它仅仅出现在你认为需要对某个对象的状态进行说明的时候。
7.业务领域分析以及需求列表：
进行业务领域分析时，可以采用原文分析法，是在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。需求列表不掺杂我们对业务需求的任何分析与设计，这是需求列表的核心，也是它存在的意义。其次，需求列表应当是站在业务人员的视角，对业务需求的简明扼要的描述。最后，需求列表也不是一步到位的，而是经过由粗到细逐渐整理形成的。
最后进行需求确认：
我们根据用户的初步需求构建出一个实物提供参考，然后再不断细化，从而使用户的需求展现给需求人员。本着实事求是、切实可行的态度，去描述用户的业务需求。用户需求规格说明书是站在用户角度描述的系统业务需求，是用于与用户签字确认业务需求；产品需求规格说明书是站在开发人员角度描述的系统业务需求，是指导开发人员完成设计与开发的技术性文档。这就是需求规格说明书的重要作用。写规格说明书，评审与签字确认会最后完成需求确认。
本学期需要掌握的内容上有：
1.在开发软件过程中，需求分析不是一蹴而就的，是一个反复迭代的过程，我们需要需要不断的与客户进行交流反馈，及时获得反馈信息，保证后续工作正常进行。
2.上学期学习的UML建模非常重要，用例图，状态图等常用uml图的绘制。这些图是描述系统各部分之间联系的表示图形，如果不能清晰的进行表示出来，那说明这个系统还有需要分析的地方。
3.用例说明，同用例图一样重要，用例图不能清楚的反应各个相互联系，还需要语言描述来更加清楚的表达。
4.快速原型法，首先做出主要部分，与用户进行交流，然后再进行下一步。
5.本着实事求是、切实可行的态度，去描述用户的业务需求。用户需求规格说明书是站在用户角度描述的系统业务需求，是用于与用户签字确认业务需求；文档的书写是非常重要的一个方面，需要提高文档写作的能力。
6.深入地去理解客户的业务，进而想到客户的心坎儿上去。需求分析必须遵从的是一定的科学方法，而不是盲目的大上快上。