在我们进行一系列需求调研工作的同时，我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司，我们就应当对需求调研的成果进行一次需求分析。当下一次开始进行需求调研时，我们应当首先将上次需求分析的结果与客户进行确认，同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。
但是，当我们经过一番忙碌，将需求中的第一手资料从调研现场捕获回来以后，我们应当怎样进行分析呢？不少团队对此都比较迷茫，没有一个统一和有效的方法，往往采用想到哪里做到哪里的方式。一些问题想到了就做了，没有想到则忽略掉了。实际上，需求分析不应当是太公钓鱼，而应当是拉网排查。任何一个疏忽都可能对项目研发带来风险。因此，我们应当采用一套成熟而完整的分析方法，稳步而有序地完成这部分工作。不同类型的软件项目其分析方法可能存在差异，但一般来说，信息化管理类软件项目通常从这几个方面着手分析：功能角色分析、业务流程分析与业务领域分析。
需求分析不是一项一蹴而就就可以完成的工作，它需要一个长期的过程，而这个过程是一个由粗到细的过程，它体现了人类认识事物的客观规律。在需求分析的初期，我们对需求的认识往往是整体的、宏观的，随着分析工作的逐渐深入，一步步细化。按照这个思路，我们对需求的分析，首先应当从功能角色分析开始。所谓功能角色分析，就是从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底是提供给哪些角色使用。
对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。用例图是UML的4+1视图中的一种，准确地说就是那个“+1”。用例图是贯穿整个面向对象分析/设计（OOA/D）的核心视图，它描述的是系统到底为用户提供了哪些功能，以及到底是哪些用户在使用这些功能，是沟通用户与技术人员的桥梁。运用用例视图对业务需求进行分析、抽象、整理、提炼，进而形成抽象模型的过程称之为用例建模，而这个模型就是用例模型。
一般地，在一个用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary）。用例描述的是系统为用户提供的功能，也就是系统能为用户做什么，通常被绘制成一个椭圆；参与者，我认为称为角色更加合适，也就是系统为哪些类型的用户提供服务，他们都各自承担哪些不同的职责，通常被绘制成一个小人儿；最后是系统边界，也就是系统是对现实世界哪个范围的内容进行的模拟，它涉及到软件设计的工作范围与工作量，通常被绘制成一个方框。但是，通常情况下系统边界只是一个概念而不用真正绘制出来，因为被绘制成用例的必然是系统内部的功能，被绘制成参与者的必然是系统外部事物。从这个意义上讲，用例图中的参与者不仅包括人，还包括那些外部系统和自动触发器。根据这样一个思路，我以往常常将外部系统和自动触发器绘制成一个小人，这常常令客户感到困惑。随后我改变了思路，将外部系统和自动触发器绘制成另一种表达形式——类元符号表示法，并在构造型上标注为Actor。
上图是一个考核系统中一个子模块的用例图。图中的用例就是这个系统提供给用户的各项功能。注意，这里仅仅是在罗列功能而不表示它们之间诸如流程调用等相互关系，这是一些初学者常常犯的毛病。参与者与用例通过实线关联起来，代表的是一种使用关系。箭头代表的是一种导航，即动作施与的方向。在这个用例图中，普通用户执行查询操作，查询系统提供的“预警监控单项查询”、“预警监控汇总查询”等查询报表；每日自动触发器触发自动考核功能，自动考核功能从“税收征管系统”这样一个外部系统中采集数据。
