1楼：匿名用户
在我们进行一系列需求调研工作的同时，我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司，我们就应当对需求调研的成果进行一次需求分析。
当下一次开始进行需求调研时，我们应当首先将上次需求分析的结果与客户进行确认，同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。
但是，当我们经过一番忙碌，将需求中的第一手资料从调研现场捕获回来以后，我们应当怎样进行分析呢？不少团队对此都比较迷茫，没有一个统一和有效的方法，往往采用想到**做到**的方式。一些问题想到了就做了，没有想到则忽略掉了。
实际上，需求分析不应当是太公钓鱼，而应当是拉网排查。任何一个疏忽都可能对项目研发带来风险。因此，我们应当采用一套成熟而完整的分析方法，稳步而有序地完成这部分工作。
不同类型的软件项目其分析方法可能存在差异，但一般来说，信息化管理类软件项目通常从这几个方面着手分析：功能角色分析、业务流程分析与业务领域分析。
需求分析不是一项一蹴而就就可以完成的工作，它需要一个长期的过程，而这个过程是一个由粗到细的过程，它体现了人类认识事物的客观规律。在需求分析的初期，我们对需求的认识往往是整体的、宏观的，随着分析工作的逐渐深入，一步步细化。按照这个思路，我们对需求的分析，首先应当从功能角色分析开始。
所谓功能角色分析，就是从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底是提供给哪些角色使用。
对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。用例图是uml的4+1视图中的一种，准确地说就是那个“+1”。用例图是贯穿整个面向对象分析/设计（ooa/d）的核心视图，它描述的是系统到底为用户提供了哪些功能，以及到底是哪些用户在使用这些功能，是沟通用户与技术人员的桥梁。
运用用例视图对业务需求进行分析、抽象、整理、提炼，进而形成抽象模型的过程称之为用例建模，而这个模型就是用例模型。
一般地，在一个用例图中通常有三种元素：参与者（actor）、用例（use case）与系统边界（boundary）。用例描述的是系统为用户提供的功能，也就是系统能为用户做什么，通常被绘制成一个椭圆；参与者，我认为称为角色更加合适，也就是系统为哪些类型的用户提供服务，他们都各自承担哪些不同的职责，通常被绘制成一个小人儿；最后是系统边界，也就是系统是对现实世界哪个范围的内容进行的模拟，它涉及到软件设计的工作范围与工作量，通常被绘制成一个方框。
但是，通常情况下系统边界只是一个概念而不用真正绘制出来，因为被绘制成用例的必然是系统内部的功能，被绘制成参与者的必然是系统外部事物。从这个意义上讲，用例图中的参与者不仅包括人，还包括那些外部系统和自动触发器。根据这样一个思路，我以往常常将外部系统和自动触发器绘制成一个小人，这常常令客户感到困惑。
随后我改变了思路，将外部系统和自动触发器绘制成另一种表达形式——类元符号表示法，并在构造型上标注为actor。
上图是一个考核系统中一个子模块的用例图。图中的用例就是这个系统提供给用户的各项功能。注意，这里仅仅是在罗列功能而不表示它们之间诸如流程调用等相互关系，这是一些初学者常常犯的毛病。
参与者与用例通过实线关联起来，代表的是一种使用关系。箭头代表的是一种导航，即动作施与的方向。在这个用例图中，普通用户执行查询操作，查询系统提供的“预警监控单项查询”、“预警监控汇总查询”等查询报表；每日自动触发器触发自动考核功能，自动考核功能从“税收征管系统”这样一个外部系统中采集数据。
在绘制用例图时一个值得思考的细节是，用例是怎样通过分析获得的。这个问题，在一些客户对信息化管理比较有经验的项目中不存在问题，因为在客户提供给我们的需求文档中就清晰地划分出了一项一项的功能。这些功能可能会在日后的需求分析工作中有所调整，但它从整体上形成了一个雏形，成为我们进行用例分析进而形成用例的依据。
有人说，我们绘制的用例图拿给客户看不懂。这样一个清晰明了的用例图，辅之以我们对图形的描述，客户怎么会看不懂呢？关键问题在于，我们没有将用例图的精髓弄明白，再加上出现一些常见问题，使得用例图画得不伦不类，客户当然就看不明白了。
现在我们看看用例绘制都有些什么常见问题。
1. 没有正确理解用例图的视角。前面我反复强调了，用例图的视角是用户，也就是说，站在用户的角度来观察的我们需要设计的系统。
从这个视角，用户看到的系统是什么呢？当然是一项一项的功能，这些功能是客户能够理解的、具体的、对客户存在价值的功能。从这个意义上说，那些技术性的功能不应当出现在这里，或者应当描述为用户可以理解的文字，比如“自动考核”。
而那些应当绘制的用例，在取名时也应当站在用户角度去取名。举个简单的例子，一个员工档案信息系统，以往我们总爱将用例取名为“添加员工信息”、“更新员工信息”、“删除员工信息”，这就是典型的技术人员编写的用例。“添加员工信息”对于用户来讲应当是做什么呢——填写新员工资料；“更新员工信息”对于用户来讲又是做什么呢——更改员工资料；“删除员工信息”又是什么呢——员工注销。
不论是“填写新员工资料”、“更改员工资料”，还是“员工注销”，对于客户都是日常工作中需要完成的操作，将用例命名为这些名字必然为用户所理解。同时，每一个用例对于用户来说应当是有价值的，也就是说，用户使用这个功能是要完成一项操作，或获得什么信息。比如上图的“自动考核”会产生一批考核结果，执行“预警监控单项查询”可以获得预警监控结果数据。
2. 图形绘制杂乱无章。一个系统，特别是一个大型系统，提供给用户的功能是繁杂的。
如果你想将所有的功能，不管粗的细的，都试图绘制在一个用例图中，几乎没人看得懂。我们之所以将分析设计图形化，是因为图形能给人形象立体的感官，使人立即就明白了其中的意思，但前提是，这个图形是主题清晰的、形象生动的。因此，我们绘制用例图要学会拆分，由粗到细地一个一个绘制。
先整体的绘制，再划分成各个模块一个一个详细绘制，再进一步细化。所以，描述一个系统应当有许许多多的用例图。
3. 用例是一个场景。在现实世界中，我们常常面对的是一个个长而复杂的操作流程，但在软件世界里，我们要将它们拆分成一个个的用例，怎样拆分？
一个用例必须有一个场景，也就是时间相近、地点单一的一系列操作，并且这些操作最终应当有一个明确的结果。
如上所示这个用例图，“申辩申请”就是过错责任人填写了一张申辩申请单，最终的结果是将申辩申请单提交给考核管理员；“申辩受理”就是考核管理员接收了过错责任人的申辩申请单并予以受理，当然另一个结果是对其不予受理，该申请单被退回给过错责任人。每个用例都有确定的场景，明确的目的和结果。
功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。但仅仅进行功能角色分析是远远不够的，我们还需要在它的基础上做更加详尽的分析。
我们应当怎样做需求分析：功能角色分析与用例图
2楼：uml专家
需求分析，就是要确认那些为系统需要实现的具体需求，剥离无需系统实现的伪需求。
功能角色则很容易被勾画出来，就是在系统中要进行执行或者操作的使用者（包括人、硬件或者其他系统）。
uml2用例图详解可以参考下面的内容http://****trufun.***/uml/umlwendang/2016/0719/168.html
有详细的用例图元素、关系以及案例讲解。
我们应当怎样做需求分析：用例说明求解答
3楼：2杭瓷
当我们进行业务流程分析时，只空对空而不落到纸面上是不可以的。过去，在面向过程的时代，我们绘制dfd图、流程图，以及编写流程说明来描绘这一部分分析；而现在，在面向对象的时代，我们则是绘制行**、状态图，以及编写用例说明来完成这部分工作。
毫不疑问，做用例分析首先是要绘制出用例图（前面已经说过了）。图形的最大优势是能够形象生动地描述我们的分析，但它最大的缺点是会遗失许多的细节信息，因此我们必须要对它进行进一步的文字描述。
由于不同的人对用例的理解不同，格式也不尽相同，但一些基本的元素是一样的。以上**是我采用的用例说明格式，其中用例名称、用例描述、参与者、前置条件、事件流、后置条件是公认的、用例说明的基本元素。
用例标识：就是用例的编号，一般采用“项目编号-子系统编号-模块编号-序号”来编号。
用例名称：没啥可说的，就是用例图中该用例的名称。注意用例的命名规则：
用例名称通常是一个动词短语或短句，而不是一个名词短语。它可以是一个动词（如：自动考核），一个动宾短语（如：
提取存款），一个被动句（如：发票填报），或者一个主谓句（如：用户提款，这个不推荐，因为主语就是参与者，显得有些多余）。
参与者：用例图中该用例的参与者，通常是业务操作的触发者和施与对象（如外部系统）。
前置条件：在触发该用例相关操作前必须达到的条件。
事件流：这是用例说明中最重要的部分，它详细描述了该用例可能出现的所有流程。
1. 基本流程：另一个名称更能表达它的意义：
最佳流程（the best flow）。它描述的是该用例以最佳的、最正常的方式流转，没有出现任何异常，并且最终成功完成操作的流程。基本流程在编写时，应当通过数字对流程中的每一步进行编号。
2. 扩展流程：或者叫“分支流程”，它描述的是基本流程在流转过程中可能出现的所有分支。
扩展流程最大的特点就是，它应当是在基本流程的某一步骤发生的分支，因此它的编号规则是“基本流程号+序号”。基本流程号就是发生分支的那一个基本流程的编号。在同一个基本流程上发生多个分支时，它们的序号从1依次开始编号。
另一种情况是，某个扩展流程本身拥有多个步骤，这时应当在“基本流程号+自身序号”的基础上再添加序号，如“2.1.1”。
扩展流程在描述时，应当首先描述进入这个分支的条件，即“如果××则××”、“当××时××”。
3. 异常流程：就是发生异常情况时的处理流程。
注意，用例说明是站在用例角度进行的说明，因此这里并不是我们通常一样的发生程序异常的处理流程，而是用户在处理业务操作时发生的异常情况，如：如果顾客不能提供身份证，则616161616161
后置条件：又称为“成功保证”，就是执行基本流程获得成功以后所达到的状态（条件）。后置条件往往体现的是执行该用例的最终目的。如：完成用户档案的填写并提交。
非功能需求：简称为“urps+”，即可用性（usability）、可靠性（reliability）、性能（performance）、可支持性（supportability）以及其它（+）。这一部分的需求分析相当重要而又最容易被忽略，后面我们再详细讨论。
假设与约束：就是隐藏于业务功能中的各项规则与条件，如各种逻辑条件、计算公式、环境限制等等。
除此之外，我还往往在每一个用例说明的后面与该用例相关的需求列表，便于需求跟踪。用例分析实质是需求人员的一份设计。既然是设计就可能出现偏差，最终偏离原始的需求（这种情况特别容易出现在日后的升级维护中）。
因此，将需求列表附在用例后面，便于日后的需求评审与确认。当每次需要升级时，则添加上新的需求，或对以往的需求进行更新。
我们应当怎样做需求分析我们应当怎样做需求调研：初识我们应当怎样做需求调研：拜访我们应当怎样做需求调研：
研讨会我们应当怎样做需求调研：需求研讨我们应当怎样做需求调研：迭代我们应当怎样做需求调研：
需求捕获（上）我们应当怎样做需求调研：需求捕获（下）我们应当怎样做需求分析：功能角色分析与用例图我们应当怎样做需求分析：
业务流程分析（上）我们应当怎样做需求分析：业务流程分析（下）我们应当怎样做需求分析：查询报表分析我们应当怎样做需求分析：
子用例与扩展用例我们应当怎样做需求分析：行**和状态图我们应当怎样做需求分析：业务领域分析我们应当怎样做需求分析：
原文分析法我们应当怎样做需求分析：领域驱动设计我们应当怎样做需求分析：非功能需求我们应当怎样做需求确认：
需求列表我们应当怎样做需求确认：一个需求列表的实例我们应当怎样做需求确认：快速原型法我们应当怎样做需求确认：
需求规格说明书我们应当怎样做需求确认：评审与签字确认会（续）