用户至上是软件开发的核心，我们要一切都要以用户的角度来看待问题，即便是这样，我们也只是从我们自己的立场来为用户看问题。要想真实的了解用户的想法，我们只能是同用户及时的沟通。在开发过程中，我们要忠于用户的想法，即使我们有自己的看法，也要及时的与用户交流，耐心的向用户解释我们的想法。对于一些细节问题，即使是用户没有考虑到，我们也要把这个问题及时的回馈给用户，然后我们按照用户的要求提供相应的解决方案。对于一个成熟的软件开发团队来说，我们要听用户的，也要给用户提意见，把决定权交给用户，让用户决定自己的产品的功能。一个真正优秀的需求分析是建立在一个动态的过程当中的，这和以前我们学到的瀑布模型是有很大的差距的。在瀑布模型当中，特别注重项目文档的编写，但是却不太重视与用户的及时沟通与交流。我们要明白的是，用户才是这个软件的拥有者，在软件的开发过程中，用户要参与进来，需求的确定要让用户来参与，在这个参与过程中，我们要保持开发人员和用户地位的平等，在这种参与和交流的时候，双方谁都不能主导这个交流。如果用户主导了这个交流，那么就会不切实际的要求开发人员开发很难实现的功能，而且用户给开发人员的时间也不够。如果开发人员主导了这种交流，那么需求当中的商业术语就会被开发人员的技术术语所代替，这样一来，用户不可能用到他们需要的软件，而只是功能快的拼凑。
借助UML图，我们既可以完成需求分析，也可以实现软件设计。当然需求分析和软件设计使用到的图可能不太一样，即使是同一种图在这两种使用场合下也有一些差别。比如说，类图在用于需求分析这个场合下，我们一般只需在类图中写出每个类的属性以及各个类之间的联系就可以了，不需要把这个类所包含的操作也写出来。
类图在用于软件设计的场合之下，还需要把类包含的操作也写出来。对象图在软件开发中使用的较多，因为在需求分析阶段，系统没必要细化到对象这个层次。对象图往往只有在描述复杂算法的时候才会使用，而且同一个类常常会有多个对象。
构件图是用来描述软件内部组成的一种图，我现在对这种图几乎没有任何的认识，所以也谈不上理解。
部署图是用来描述系统如何部署，以及本系统和其他系统是什么关系的一种图。我们为客户开发的软件不会是只运行在一台设备上的，往往有许多台设备，甚至我们的系统会运行在不同类型的设备上。如，总公司的服务器、总公司内部的PC设备、手机客户端、部分手持设备等一系列设备。每种不同的设备都是一个节点，不同节点之间的互联互通才构成了一套完整的系统。
包图是对类图的一种管理，包图的思想类似于面向对象的编程思想当中的包，也就是按照某种标准对一些有着共同特征的类按照文件的结构来保存。
活动图有开始也有相应的结束，和以前学过的流程图很相似，这两种图的区别我不太清楚，我还要好好地理解一下。
状态图关注的是系统中某个对象或者事物在一次系统的运转过程中状态的变化。状态图关注的是系统中的一个对象或者是事物。
顺序图描述的是在用户的参与下系统完成某一次业务的流程。在用户参与下，系统与用户的交互。
通信图和顺序图都描述了交互的过程，但是顺序图侧重交互的时间顺序，而通信图则更看重交互的过程，不注重时间的顺序。
用例图描述的是用户在和系统交互的时候的一个具体场景，是对系统某一项功能的描述，因为一项具体的功能往往对应一个场景。用户的实际需求往往要转换成具体的系统功能，这样一来，用例图在分析系统需求的时候会起很大的作用。
时序图，没有搞清楚。