二、我们应当怎么做需求分析
2.1功能角色与用例图
对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。运用用例视图对业务需求进行分析、抽象、整理、提炼，进而形成抽象模型的过程称之为用例建模，而这个模型就是用例模型。
2.2业务流程分析
形成对系统的整体轮廓，对于软件的需求分析来说是远远不够的。许多软件最终失败的非常重要的原因就是对需求分析过于草率、浮于表面，而没有深入细致地去分析。在现实世界中，企业是按照怎样的流程来管理，我们的软件就应当去模拟这样的流程。我们进行流程分析，就是要求分析哪些是系统之内的，哪些是系统之外的。
2.3用例说明
用例描述：对该用例的功能定义、要实现的业务需求，以及谁（参与者）应该如何使用进行描述。同时，这部分还可以整体概述实现业务需求的主要流程，以及与其它用例、其它外部系统的关系。通过用例描述，阅读者可以对该用例有一个整体的认识。
2.4查询报表分析
对于有些功能来说总感觉不对劲，感觉不对劲的，就是那些查询、汇总与报表功能。对于这部分功能，需要我们描述的不是什么操作流程，而更重要的是那些数据项、数据来源、报表格式、数据链接，以及使用者、使用频率的说明。查询报表的需求分析与一般的业务操作的需求分析存在着巨大的差异。而许多需求分析人员没有认识到这一点，这往往导致对查询报表的分析不到位，为项目的研发带来风险。
2.5子用例与扩展用例
在基本流程中，可能有些步骤是多个用例都共有的，可以相互共享的流程。将这部分流程提取出来形成的就是子用例。子用例应当是在逻辑上相对独立的一系统流程组成的用例。另外，在用例中还存在许多扩展流和异常流。当系统在运行到基本流程中某个步骤时，由于满足了某个分支条件或异常条件，这时系统就从基本流程流转到了扩展流或异常流中。
2.6行动图和状态图
行动图（Active Diagram），比较类似于我们过去绘制的流程图，是UML中描述流程与分支的视图。在使用状态图时，一个非常关键的概念就是，一定是对某个关键对象的状态变化的描述，而这些状态变化一定是在某个业务流程的大背景下进行的。
2.7业务领域分析
业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。系统中应当有哪些实体，这些实体都有哪些属性，被赋予了哪些行为，它们之间的相互关系是怎样的，就成为了业务领域分析的重要内容，而业务领域分析也就成为了对系统进行的一种静态分析。
2.8原文分析法
原文分析法（Textual Analysis），是在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。在进行原文分析的时候，我们首先要做的事情就是对用例说明中事件流部分的文字描述，提取其中的名词。其次，系统之内的事物转化到领域模型中，可能会变成两种东西：实体与实体中的属性。另外一个非常重要、值得我们着重关注的地方是名词的多义性。
2.9领域驱动分析
在领域驱动设计思想中，有许多是涉及到需求分析领域的先进方法，可以把它归纳为有效建模、统一语言和持续学习。
2.10非功能需求
需求分析人员最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技术，是设计，是实现，是架构师关注的内容，是需求人员最不擅长的方面，这也是非功能需求为什么常常被忽略的重要原因。