1楼：uml专家
uml需求分析，主要是针对业务需求进行整理规划，分析出系统需要实现的模型。
uml在需求分析过程中，应用比较多的是用例图、活**、状态图等，也可以根据需要有其他框图。
比如下面的用例图，很好的反应了系统中用户管理要实现的基本功能。
如何用uml来做需求分析
2楼：lowliness岁月
我们进行一系列需求调研工作的同时，我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司，我们就应当对需求调研的成果进行一次需求分析。
我在进行文档管理系统的设计与开发，我现在进行到需求分析阶段，如果用uml的话，应该画些什么图？谢谢
3楼：匿名用户
简单地了解一下uml设计中有的图例及基本作用。首先对uml中的各个图的功用做一个简单介绍： 1、用例图 描述角色以及角色与用例之间的连接关系。
说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。
2、类图 类图是描述系统中的类，以及各个类之间的关系的静态视图。能够让我们在正确编写**以前对系统有一个全面的认识。类图是一种模型类型，确切的说，是一种静态模型类型。
3、对象图 与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类。它描述的不是类之间的关系，而是对象之间的关系。
4、活** 描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。
5、状态图 描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。
一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；该图可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。状态图是对类图的补充。 6、序列图 （顺序图） 序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。
顺序图可以用来展示对象之间是如何进行交互的。顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。
7、协作图 和序列图相似，显示对象间的动态合作关系。可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。如果强调时间和顺序，则使用序列图；如果强调上下级关系，则选择协作图；这两种图合称为交互图。
8、构件图 （组件图） 描述**构件的物理结构以及各种构建之间的依赖关系。用来建模软件的组件及其相互之间的关系，这些图由构件标记符和构件之间的关系构成。在组件图中，构件时软件单个组成部分，它可以是一个文件，产品、可执行文件和脚本等。
9、部署图 （配置图） 是用来建模系统的物理部署。例如计算机和设备，以及它们之间是如何连接的。部署图的使用者是开发人员、系统集**员和测试人员。
一：这九种模型图各有侧重， 1:用例图侧重描述用户需求， 2:
类图侧重描述系统具体实现； 二：描述的方面都不相同， 1:类图描述的是系统的结构， 2:
序列图描述的是系统的行为； 三：抽象的层次也不同， 1：构件图描述系统的模块结构，抽象层次较高， 2：
类图是描述具体模块的结构，抽象层次一般， 3：对象图描述了具体的模块实现，抽象层次较低。 在有的文献书籍中，将这九种模型图分为三大类：
结构分类、动态行为和模型管理： 1：结构分类包括用例图、类图、对象图、构件图和部署图， 2：
动态行为包括状态图、活**、顺序图和协作图， 3：模型管理则包含类图。
用例图是需求分析还是概要设计与uml
4楼：uml专家
用例图在需求分析和概要设计中都会用到，只不过分析的层次和重点会有所不同。
如何应用uml用例图描述软件系统的用户需求
5楼：uml专家
用例图主要描述的就是业务需求，业务功能部分。
具体你可以参考这篇文章：uml2系列框图--用例图详解
http://****trufun.***/uml/umlwendang/2016/0719/168.html
软件需求分析师一定要会uml和原型设计图吗
6楼：青鸟中关村专家
是的，用图形描述需求和功能更直观和清晰，文不如表，表不如图
需求建模，分析建模和设计建模用到uml哪些图
7楼：若水小天
需求建模 ——做需求分析阶段 ，这个时候给出的是初步的类图(参与者什么的)、顶层用例，详细用例
分析建模 ——系统分析阶段，这时候给出的是分析类图 顺序图 协作图 状态图
设计建模——系统设计阶段给出 细化过程（包括顺序图 协作图 类图 等的细化和修改）、包图、组件图、部署图，再就是呈现数据库的设计图。
uml需求来自什么地方
8楼：uml专家
uml需求来自什么地方？这个问题有点奇怪！很容易引起歧义。
uml需求可以理解为对uml的需要，因为以前没有一个统一标准的规范，大家在各行各业的应用都有很多方式方法，各有所长，后来就被提炼出了uml，统一了各种规范，形成统一标准，大家都遵循这个标准，交流也方便，过程规范也方便。
在软件工程领域主要用于软件中的需求分析，分析设计等过程。
如下图，一个简单的分析设计类图。
9楼：匿名用户
我记得是根据功能需求分析来做的uml设计，不过小项目很少做这个东西来的
uml与系统分析设计复习题 软件需求**有哪些
10楼：比例吧啦哈哈
面向对象的程序
1.需求分析
2．总体设计
3．详细设计阶段
4．实现阶段
一、需求分析阶段：
以用例图为主，到类分析图为止。类图是源码的**。用例的主功能用序列图表示。
用例的状态可以用状态图标识， 注意活**要细化到与序列图相同程度。按照不同用户画出不同用例图。按照不同物理位置画出部署图；按照不同类型用户对程序进行分类，得到组件图。
从序列图得到协作图，并且进行简单类分析，得到类分析图。
序列图的消息变成操作，消息中的信息变成属性。
二、总体设计
为用户所见的系统计算机层面，包括界面。
每一个用例的完整序列图，包括主功能，备用功能，异常事件，错误输入与错误处理等序列图集，每一个分支一个序列图。用一个活**归并全部序列图，遇到分支用菱形框，得到用例的完整功能。细化用例图，比较每一个用例的活**，得到相同的部分，分解成包含用例；对于复杂功能的用例，分解成多个包含用例。
对有些功能进行模块化扩展，称为扩展用例。对用户与用例可以用继承关系。
从序列图得到协作图，进行简单类分析，特别是实体类。增加类：界面类，事务管理类。
画出系统状态图（有活动表达式），对重要的类画出类的状态图，从中得到新的属性与操作。
对增加的类重新画序列图，活**与协作图。分析类图。
细化状态图。
状态图为主，应用类图是重心，画出全部用户的细化用例图，说明与其它系统的接口。
画出系统总体设计图，根据应用类图与顺序活**。建立uml总体模型。
三、详细设计阶段
程序的内部结构与实现方案的详细
类图为主，重点是增加控制类。
从类图得到程序的结构，从顺序活**得到程序的过程（c++）．
重画有控制类的序列图、协作图、活**。
.用协作图将操作函数化，用返回值将属性变量化
.给出类状态图的活动表达式。状态图的事件是序列图的消息，是类的操作，活动表达式是转换事件的实现，因此是类的操作的实现。
分解活**，根据某一个操作。与活动表达式不同。
将应用类图变成设计类图，用具体的语言，
子系统的划分：类图，活**（模块图），组件图，部署图。
将类align到组件中，将组件到部署图中。
建立程序设计的完整模型。
四、实现阶段
建立并发视图。
组件图：可执行文件，配置文件。
部署图：进程，设置硬件，例如打印机
软件测试
产品阶段