前面我一直在反复强调这样一个观点，需求分析不是一蹴而就的，是一个反复迭代的过程。它将从第一次需求分析开始，一直持续到整个项目生命周期。为什么这样说呢？让我们一起来分析分析。
在第一次的需求分析阶段，我们在一段时期内需要与客户进行反复地讨论，这个过程往往是这样一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获••••••
需求捕获，就是我们与客户在一起开研讨会，讨论需求的活动。客户可能会描述他们的业务流程，这时我们在纸上绘制简单的流程草图，及时地记录下来；客户在描述业务的同时，可能会反复提到一些业务名词，详细询问这些名词的含义，以及它们与其它名词的关系，用类图或者对象图绘制简单的草图；客户在描述业务的同时，还会提出今后的软件希望实现的功能，如能够展示某个报表、能够导出文件，以需求列表的形式记录下来。一个功能，在需求列表中会有多个需求，而每个需求应当能够用1、2句话，在20个字以内就可以描述清楚。需求列表是客户提出的最最原始的需求，他不掺杂任何分析设计，是我们的每项功能必须实现的内容。需求列表是需求验证以及日后的用户验收测试的依据，不论我们今后如何分析和设计这些功能，都要能如实地实现这个列表中提出的需求。（需求列表应当如何编写，将在后面的章节详细描述。）
需求整理，就是在需求研讨会后，需求分析人员对研讨内容的分析和整理的过程。首先，需求分析人员应当通过用例模型，划分整个系统的功能模块，以及各个模块的业务流程。用例模型分析是一个由粗到细的过程，这样一个过程也是符合人类认识世界的思维习惯的一个过程。最先，我们应当对整个系统绘制用例图，设计用例场景，并依次对这些用例进行用例描述、流程分析、角色分析等分析过程。当然，在整体用例分析的同时，我们还应当进行一个整体的角色分析，绘制一个角色分析图，进行一个流程分析，绘制一个流程分析图（可以是传统的流程图、UML中的行动图，甚至一个简单的示意图，等等）。
然后，我们再在整体用例图的基础上，依次对每个用例绘制用例图。每个用例图中，会更细致地划分出多个用例，并依次进行用例描述、流程分析、角色分析等分析工作。如此这般地不断细化，直到我们认为需求已经描述清楚为止。
在一个系统中，用例需要细化几次，是由这个用例的业务复杂程度决定的。对于一个简单的用例，只需要细化一次就够了；而对于比较复杂的用例，则需要细化2~3次，甚至更多。
用例分析的过程，之所以称之为分析，它掺入了很多需求分析人员对业务的理解与设计：模块如何划分、流程如何设计、业务如何转换，等等。用例分析，还需要让需求分析员与架构师、设计师等技术人员共同协作来完成，因为用例分析还包含对业务需求的技术可行性分析。只有一份可行的需求分析，才能为后续的设计开发扫清障碍，有效降低项目风险。最后，需求分析员应当将需求列表中的内容，逐一地与用例进行核对，以避免分析人员忽略用户的某项业务需求。（后面将详细描述用例模型的搭建过程。）
在用例分析的同时，需求分析人员还需要对业务中的相关事物，制作领域模型。领域模型，是对用户业务领域中相关事物、相互关系、相互行为操作的描述，它是以对象图和类图的形式表达的。需求人员对领域模型的分析，对业务理解的深度，对日后软件的设计，以及软件的功能扩展、升级演化，都起到了至关重要的作用。（后面将更加详细地讲述领域模型。）
最后，当我们完成了一系列的分析整理并形成文档以后，应当对及时地与客户进行反馈，确认我们的理解是否正确，也就是需求验证工作。需求验证工作应当贯穿整个研发周期，并且在不同时期表现出不同的形式。首先，在需求分析阶段，需求验证工作表现为对需求理解是否正确的信息反馈。需求分析人员与客户再次坐在一起，一项一项描述我们对需求的整理和理解，客户则时不时地对一些问题进行纠正，或者更加深入地加以描述。我们则认真地记录，回来整理，并等待下一次的验证。在需求分析后期，我们还可以制作一些简单的原型，更加形象地描述我们对需求的理解，会使我们与客户的沟通更加顺畅。随后的设计开发阶段，我们则应当以迭代开发的形式进行。每开发完一个迭代周期，将开发的成果与客户反馈。这样做的结果是，客户可以及时地提出我们对需求理解的偏差，或者及时提出对我们设计不满意的地方，使我们存在的问题得到及时地发现与解决。问题及时的解决，使我们修复问题的代价得以降至最小。之后，当开发进入到验收测试阶段，我们则是与客户一道，一项一项地验证我们的软件是否满足需求列表中要求的业务需求。最后，当软件迎来下一次升级开发时，我们将开启另一次轮回。
因此，需求分析就是按照这样的过程，每次多理解一些，再多理解一些，更多理解一些，逐渐深入的过程。每深入一步，我们的软件就更接近客户的满意。
我们应当怎样做需求分析 我们应当怎样做需求调研：初识 我们应当怎样做需求调研：拜访 我们应当怎样做需求调研：研讨会 我们应当怎样做需求调研：需求研讨 我们应当怎样做需求调研：迭代 （续）