今天读了关于如何做需求分析的博文，学习了软件需求与分析需要掌握的一些内容，下面就做一些总结。
首先要认识到深入地去理解客户的业务，进而想到客户的心坎儿上去，最后做出来的东西必然是客户满意的。第一个举出来东软的例子，东软在做这个项目的时候，整个过程经历了10多次结构性的大变更，局部性的调整更是不计其数。百处程序进行修改。最后这个项目导致的结果是，整个这个项目组的所有成员都离开了东软，常常会听到抱怨客户总是对需求改来改去，那是因为我们对客户的需求没有真正理解清楚时，我们做出来的东西客户必然不满意。不知道怎么才能让客户满意，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。
第二个举例自己一次失败的例子告诉了我们不能客户怎么说软件就怎么做。客户提出的原始需求往往是不考虑技术实现，基于非计算机管理的操作模式提出来的。他们提出的很多需求常常比较理想而不切实际，毕竟人家是非技术的。但我们作为技术人员，需求分析必须实事求是的、基于技术可以实现的角度去考虑。那种“有条件要上，没有条件创造条件也要上”的鲁莽行事，结果必然是悲惨的。我们做需求就应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操作与管理。
在本学期我们应该学会学会需求调研，需求调研是需求分析最重要的一环，它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。
需求研讨首先跟客户探讨的不是软件功能，而是客户现有的业务知识，需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。
对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。在一个用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary）。用例描述的是系统为用户提供的功能，也就是系统能为用户做什么。
进行业务流程分析时，我们是绘制行动图、状态图，以及编写用例说明来完成这部分工作。编写用例说明应当是最主要的工作，用例标识，用例名称，用例类型，用例描述，参与者，触发事件，前置条件，事件流。用例分析实质是需求人员的一份设计。用例说明中对流程的描述都是用枯燥无味的文字来表述的，缺乏生动形象的图形表示。针对这些不足，UML的另外两种视图，可以有效地弥补用例图的缺陷。它们就是行动图与状态图。
业务领域分析，就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。我们去设计开发系统时，应当设计哪些类，类中都应当有什么属性和行为，以及怎样去设计数据库，都是以这个领域模型为基础的。
