1,如果说组织业务研讨会是项目经理的功底，那么讨论业务需求就是需求分析人员的功底。
2,以往我们常常认为，需求分析是一件最简单的事情。客户说他们需要做一个什么软件，有些什么功能，我们照着做就可以了，所谓的需求分析员就是需求的记录员。我要说，这是一个极大的错误，许多失败的软件项目，或者说软件项目中的需求问题，大多都源于此。经过人们多年的研究发现，在需求分析过程中，客户存在的最大问题就是提不出正确的需求，这表现为几种形式：
2.1. 由于对软件不了解，客户提不出需求，不知道软件最终会做成什么样子。这类客户在需求讨论过程中，往往只能描述目前自己手工管理的方式是怎样的，不知道计算机会怎样管理。
2.2 能提出一些业务需求，但当软件做出来摆在自己面前时，需求就变了。这类客户，他们能熟练使用电脑，对信息化管理是清楚的。他们提出的业务需求从整体上应当是八九不离十的。但是，由于没有实物，在软件中的一些具体操作并没有完全想清楚。因此，当软件真正做出来摆在自己面前时，甚至经过一系列流程操作以后，会对一些操作提出变更需求。他们正如那句经典的话说的：“I have changed when it saw it.”
2.3 能非常详细地提出业务需求，甚至有时候该怎么做的提出来了。这类客户，参与过很多软件信息化建设，甚至有些还是软件开发的半专业人士。但是他们提出的业务需求过于具体，甚至怎样实现都说出来了，但这些有时候不是最佳设计方案、可能在技术上难于实现，甚至有些就是过于理想化而不可实现。
3,我在进行需求研讨的时候，首先跟客户探讨的不是软件功能，而是客户现有的业务知识，用专业的话叫“业务领域分析”。客户现有的业务流程是什么样的，都有些什么操作？客户在业务中都有些什么事物，什么专用名词，都是怎样定义的，相互之间的关系是什么？客户在每一项操作中的目的是什么，为什么要这样做，他们制作的手工报表都说明了什么问题？后面我会更加详细地描述怎么进行业务领域分
4,在认识了客户的业务领域之后，我们才能去分析他们提出的所有原始需求。他们为什么要提出这项需求，提这项需求的目的是什么？只有经过这样的分析，我们才能深刻地理解需求，进而运用我们的专业知识，提出更加合理的技术方案。但非常遗憾，我们在需求分析中常常不是这样做的，甚至当软件都开发出来了，需求分析人员都说不出客户为什么要提出这个需求，更谈不上了解业务操作流程。一句经典的话是：“客户让我们这样做的。”
5,在客户提出的所有原始需求中那些与业务实现有关的需求都是无效的需求，它们仅仅只能作为我们的一个参考。什么是与业务实现有关的需求呢？比如要求做成什么界面，数据要求怎样处理，等等。为什么是无效的呢？因为客户毕竟是非专业，我们应当有这种自信，在理解客户真实意图以后，能够提出比客户更优的解决方案。
6,还有一些是技术难于实现或者根本就无法实现的需求，我们应当耐心地说服和引导客户，并给他提出一个更加合理的方案。注意最后一句话：“给他提出一个更加合理的方案”。苍白的拒绝客户往往会让客户产生抵触情绪，但当我们提出一个更加合理的方案时，客户往往会欣然接受，当然这是在我们对客户提出的业务需求的真实意图进行深入分析之后。认识到这一点非常重要，为了更加清楚地说明这一点
7,在第一次的需求分析阶段，我们在一段时期内需要与客户进行反复地讨论，这个过程往往是这样一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获••••••
8,需求捕获，就是我们与客户在一起开研讨会，讨论需求的活动。客户可能会描述他们的业务流程，这时我们在纸上绘制简单的流程草图，及时地记录下来；客户在描述业务的同时，可能会反复提到一些业务名词，详细询问这些名词的含义，以及它们与其它名词的关系，用类图或者对象图绘制简单的草图；客户在描述业务的同时，还会提出今后的软件希望实现的功能，如能够展示某个报表、能够导出文件，以需求列表的形式记录下来。一个功能，在需求列表中会有多个需求，而每个需求应当能够用1、2句话，在20个字以内就可以描述清楚。需求列表是客户提出的最最原始的需求，他不掺杂任何分析设计
9,需求整理，就是在需求研讨会后，需求分析人员对研讨内容的分析和整理的过程。首先，需求分析人员应当通过用例模型，划分整个系统的功能模块，以及各个模块的业务流程。用例模型分析是一个由粗到细的过程，这样一个过程也是符合人类认识世界的思维习惯的一个过程。最先，我们应当对整个系统绘制用例图，设计用例场景，并依次对这些用例进行用例描述、流程分析、角色分析等分析过程。当然，在整体用例分析的同时，我们还应当进行一个整体的角色分析，绘制一个角色分析图，进行一个流程分析，绘制一个流程分析图（可以是传统的流程图、UML中的行动图，甚至一个简单的示意图，等等）。
然后，我们再在整体用例图的基础上，依次对每个用例绘制用例图。每个用例图中，会更细致地划分出多个用例，并依次进行用例描述、流程分析、角色分析等分析工作。如此这般地不断细化，直到我们认为需求已经描述清楚为止。
10,用例分析的过程，之所以称之为分析，它掺入了很多需求分析人员对业务的理解与设计：模块如何划分、流程如何设计、业务如何转换，等等。用例分析，还需要让需求分析员与架构师、设计师等技术人员共同协作来完成，因为用例分析还包含对业务需求的技术可行性分析。只有一份可行的需求分析，才能为后续的设计开发扫清障碍，有效降低项目风险
12,在用例分析的同时，需求分析人员还需要对业务中的相关事物，制作领域模型。领域模型，是对用户业务领域中相关事物、相互关系、相互行为操作的描述，它是以对象图和类图的形式表达的
13,在软件需求捕获过程中，最根本、最容易犯错的问题是什么呢？我认为是一个态度的问题，是采用主动态度去捕获需求，还是采用被动的态度去捕获需求。如果需求分析人员总是诺诺诺，客户说什么，我们就记什么。客户处于非常强势的地位，给我们提出了非常多变态、技术难于实现的需求，而我们的需求分析人员却成为记录员，埋头记录客户说的每一句话，不加分析地就直接扔给了开发人员。这就是采用被动的态度去捕获业务需求的方式。毫无疑问，这样的需求分析必然将给项目开发的后期带来巨大的风险
14,什么是客户嘴中没有说出来的需求，并不是客户故意卖弄官子不愿说出来，而是在客户所在业务领域已经约定俗称，在他们看来已经是天经地义，根本就不用说出来的业务规则。然而，作为刚刚涉足该领域的需求人员，他们是不了解这些规则的。如果采用被动的方式去仅仅记录客户说出来的需求，毫无疑问会遗失这部分需求，这就是为什么直到项目后期，软件被研发出来即将交付使用，客户才提出说这不是我想要的软件，并提出大量变更需求的原因。
15,如何破解这样的问题呢？那就是要求我们在需求分析的整个过程，不断进行业务领域知识的学习。在我做需求访谈的初期，我往往不是跟客户谈需求，而是先跟客户谈业务。你们是怎样操作的？都经过些什么流程？谁来完成这些操作的？为什么这样操作？注意，在所有这些问题中，最后一个问题是最重要的。客户业务领域中的所有操作、所有流程都是有它存在的意义的，它体现了其内部的原因与作用。多问为什么，可以让我们深入地理解这些领域知识，站在客户的视角去思考问题，进而深入地理解客户为什么要提出他们的那些业务需求。当一个需求分析员能达到这样的水平，客户嘴中没有说出来的需求就会被源源不断地被发掘出来，最终做出来的需求分析才是完整的、准确的。
16,另一种就是客户压根儿没有想到的需求。也许你会提出这样的疑问，客户压根儿没有想到的需求我们还提出来做什么？这种压根儿没有想到的，实际是在业务需求阶段压根儿没有想到的，并不代表最终都没有想到。很多开发人员总在埋怨，说客户需求总是在软件项目的后期改来改去，为什么？客户并不是软件研发领域的专业人员。在业务需求阶段，由于没有可以展示和操作的实物，客户总是在空对空的凭空想象今后的软件应当做成什么样子。这就注定了客户会有很多自己压根儿没有想到的需求。那么为什么他们会在软件研发的后期提出来呢？因为软件研发的后期，客户能拿到那些研发成果的实物，去操作，可以看到。这时候，很多他们起初没有想到的需求就会源源不断地被提出来。但这时候，我们作为研发人员会很伤，我们付出的代价会很大。所以，以被动的态度去完成需求分析工作，必然会给项目研发带来巨大的风险。
17,如何解决这样的问题呢？首先，在需求分析阶段，虽然客户压根儿没有想到，但需求分析人员是软件研发领域的专业人员，他们应当在深入理解业务领域与需求的基础上，通过分析提前发现这些需求。作为需求分析人员，他们应当站在客户的角度去思考，我们的软件应当设计成什么样子，每个需求的真实意图是什么。站在这个基础上，再运用专业知识去整理、分析与设计。我前面谈到，客户描述的最原始的需求是编写在需求列表中的，而经过需求分析人员的整理、分析与设计，经过用例分析、领域建模，最终形成产品需求说明书（或称为产品规格说明书）。从需求列表到产品需求说明书，这之间要经过一段长长的路，这段路就是我们的分析与设计，而不是简单的记录与编写文档。只有经过这样的过程，最后得到的才是高质量的需求分析，才能有效地指导软件研发，避免项目的风险。所以说，好的需求分析人员就是软件项目的司命，掌握着项目的生死。
18,接下来，我们再回到那些从客户嘴里说出的需求。在需求分析人员中，比较普遍的一个看法就是，只要是从客户嘴里说出来的，就一定是对的，我们必须照着做的，这种看法是不正确的。因为客户在软件开发方面是非专业的，所以他们在提出需求的时候往往会考虑不够周全
19,最后，我不得不说，企业信息化管理实质就是一次改革，是企业摒弃手工操作，向信息化建设迈进的一次改革。既然是改革，就必须要改变过去不合理的管理流程，向更加合理和高效的管理流程迈进。因此，我们的需求捕获最初是源于企业现有的操作流程，但当我们深入理解了客户现有的操作流程以后，应当有意识地发现那些不合理的部分，并最终提出更加合理、更适于信息化管理的流程。如果需求人员能上到这样一个高度，我们的需求分析就进入了一个更加崭新的层面
20,对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。用例图是UML的4+1视图中的一种，准确地说就是那个“+1”。用例图是贯穿整个面向对象分析/设计（OOA/D）的核心视图，它描述的是系统到底为用户提供了哪些功能，以及到底是哪些用户在使用这些功能，是沟通用户与技术人员的桥梁。运用用例视图对业务需求进行分析、抽象、整理、提炼，进而形成抽象模型的过程称之为用例建模，而这个模型就是用例模型
21,功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。但仅仅进行功能角色分析是远远不够的，我们还需要在它的基础上做更加详尽的分析。
22,我们将从客户调研现场拿回来的需求，经过一番功能角色分析，整个系统的整体脉络与轮廓已经被勾画出来。在这个过程中，我们首先将系统划分成了几个功能模块（如果系统规模较大，还应先划分为几个子系统，然后再划分出各个功能模块）。然后，我们为每个功能模块绘制用例图。用例图是站在用户角度去观察的系统，即系统为用户提供了哪些功能，这就是功能分析。同时，这些功能是为哪些用户服务的，这就是角色分析。我们绘制的用例图应当能够为用户所理解，这也是UML其中的一项核心思想——与客户形成统一的、能够相互理解的语言，这对于需求分析过程中与客户的沟通是大有好处的。
23,形成对系统的整体轮廓，对于软件的需求分析来说是远远不够的。许多软件最终失败的非常重要的原因就是对需求分析过于草率、浮于表面，而没有深入细致地去分析，往往到了项目后期才把需求搞懂，才发现真正的需求与起初的认识大相径庭，才恍然大悟需求原来是这样，而往往那时已经追悔莫及了。这样的经历相信你也有过吧。所以，我们一定要沉下气来认真仔细地做需求分析，一定要做到位。
同样，细化需求也需要一定的方法与思路。一般来说，我们可以有两个方向细化需求：业务流程分析与业务领域分析
24,，我们进行业务流程分析，就是要分析业务流程中哪些是需要信息化管理的，而哪些则不需要。
25,务流程分析的另一个重要的分析内容就是流程差异化分析。不同的领导有不同的思路，不同的单位有不同的情况。因此，我们在进行流程分析的时候，常常面临流程差异化的问题。我们说企业信息化就是一次改革，这首先体现在业务流程的规范化操作，也就是消除这种流程差异。但不同的单位有不同的情况，这特别体现在不同地域和文化的不同，又常常造成这种流程差异不可避免。分与合，分治与一统，常常是一个都要兼顾的问题，非常微妙，我们要小心处理。在这个问题上你也许会问，使用工作流引擎就可以了嘛。工作流引擎不是万能的，它只能解决一部分问题，更多的问题还需要我们的分析人员去分析与处理
