u013456370的专栏

项目组经过一番努力，获得了一些初步的成果。首先是给客户留下了一个良好的印象，这是一个开端，但要在他们心目中树立自己的职业威信还要看你今后的表现。同时，我们与客户一起为项目制订了短期与长期目标。不要小看了这些目标，它们就是我们的尚方宝剑。正是因为有了它，今后项目中的有关各方就应当协助实现这个目标。我们应当清晰地向客户表达这样一个意思，要完成这样的目标，不是某一方的努力，而是双方共同努力的结果。这也是

用例模型作为UML中4+1视图中非常重要的一员，非常集中地体现了面向对象的分析与设计思想。用例模型将现实世界中连续的一个一个业务流程，按照场景划分到了一个一个的用例中。由于场景的出现，使得用例中的业务流程存在着高度的内聚性，从而成为了日后各种对象的雏形。同时，在用例分析中，又将那些存在于各个用例中的，相同或相近的业务操作提取出来，形成一个一个的子用例或扩展用例，又体现了面向对象设计中的复用性。现在

在我以往的用例分析中，使用这样格式的用例模式，对于大多数业务操作流程来说是得心应手的，但对于有些功能来说总感觉不对劲。感觉不对劲的，就是那些查询、汇总与报表功能。对于这部分功能，需要我们描述的不是什么操作流程，而更重要的是那些数据项、数据来源、报表格式、数据链接，以及使用者、使用频率的说明。而这些，在以往的用例说明格式中统统都没有，怎么办呢？俗话说“东西是死的人是活的”，把我们的用例格式改改吧。 

前面我们讨论了，需求分析工作是一个迭代的过程：需求捕获->需求整理->需求验证->再需求捕获······需求捕获是这个迭代过程的开始，也是整个需求分析工作中最重要的部分。没有捕获哪来后面的整理与验证工作？但是，非常遗憾，按照我以往的经验，需求捕获是我们最薄弱的环节。前面我提到的许许多多项目开发的问题都可以归结为需求分析的问题，而许许多多需求分析的问题又都可以归结为需求捕获不完整的问题。需求捕获是整

前面我们探讨了业务研讨会应当怎样组织，下面我们再具体讨论一下我们应当怎样与客户讨论业务需求。如果说组织业务研讨会是项目经理的功底，那么讨论业务需求就是需求分析人员的功底。 以往我们常常认为，需求分析是一件最简单的事情。客户说他们需要做一个什么软件，有些什么功能，我们照着做就可以了，所谓的需求分析员就是需求的记录员。我要说，这是一个极大的错误，许多失败的软件项目，或者说软件项目中的需求问题，

在我们进行一系列需求调研工作的同时，我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司，我们就应当对需求调研的成果进行一次需求分析。当下一次开始进行需求调研时，我们应当首先将上次需求分析的结果与客户进行确认，同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。 但是，当我们经过一

前面我们讨论了，需求分析工作是一个迭代的过程：需求捕获->需求整理->需求验证->再需求捕获······需求捕获是这个迭代过程的开始，也是整个需求分析工作中最重要的部分。没有捕获哪来后面的整理与验证工作？但是，非常遗憾，按照我以往的经验，需求捕获是我们最薄弱的环节。前面我提到的许许多多项目开发的问题都可以归结为需求分析的问题，而许许多多需求分析的问题又都可以归结为需求捕获不完整的问题。需求捕获是整

我们将从客户调研现场拿回来的需求，经过一番功能角色分析，整个系统的整体脉络与轮廓已经被勾画出来。在这个过程中，我们首先将系统划分成了几个功能模块（如果系统规模较大，还应先划分为几个子系统，然后再划分出各个功能模块）。然后，我们为每个功能模块绘制用例图。用例图是站在用户角度去观察的系统，即系统为用户提供了哪些功能，这就是功能分析。同时，这些功能是为哪些用户服务的，这就是角色分析。我们绘制的用例图应当

又到新年了，日历又要从2011年翻到2012年了，这使我有太多的感慨，进而勾起了对太多往事的回忆。过去的10年，毫无疑问是中国软件业发展最快的10年。当我们刚刚毕业的时候，还在使用VB、PB开发一些简单的数据库应用，而现在却几乎看不到它们的踪影，换来的是诸如J2EE和.NET这样的大型web应用。而这期间，RUP、XP、敏捷开发、持续集成••••••一个接一个的新概念层出不穷，令人眼花缭乱。现在想

经过一番努力，我们终于在客户中找到了一批人，可以解答困扰我们多时的业务问题了，真是不容易呀。但是，如何以合适的时间、合适的地点、通过合适的形式与客户研讨业务需求，是摆在项目经理面前的一道难题。在我所经历的项目中，业务研讨会没有一个是相同的。 我曾经做过一个政府机关的项目，在这个项目中，从总局到省、地市、区县，形成了一个多组织机构的管理系统。虽然全国管理流程大体相同，但各地因各地实际情况的不

很多需求分析的工作是从需求调研开始的，我们就从这里说起吧。需求调研是需求分析最重要的一环，也最集中地体现了需求分析的特点——既是一份体力活儿，更是一份技术活儿。它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。 在一个阳光明媚的下午，项目经理带领着项目组成员，参加了客户组织的见面会，一个新的软件研发项目就这样开始了。双方在一种友好的气氛中进行，相互寒暄，介绍与

另外，业务流程分析的另一个重要的分析内容就是流程差异化分析。不同的领导有不同的思路，不同的单位有不同的情况。因此，我们在进行流程分析的时候，常常面临流程差异化的问题。我们说企业信息化就是一次改革，这首先体现在业务流程的规范化操作，也就是消除这种流程差异。但不同的单位有不同的情况，这特别体现在不同地域和文化的不同，又常常造成这种流程差异不可避免。分与合，分治与一统，常常是一个都要兼顾的问题，非常微妙

前面我一直在反复强调这样一个观点，需求分析不是一蹴而就的，是一个反复迭代的过程。它将从第一次需求分析开始，一直持续到整个项目生命周期。为什么这样说呢？让我们一起来分析分析。 在第一次的需求分析阶段，我们在一段时期内需要与客户进行反复地讨论，这个过程往往是这样一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获•••••• 需求捕获，就是我们与客户在一起开研讨会，讨论需

当我们进行业务流程分析时，只空对空而不落到纸面上是不可以的。过去，在面向过程的时代，我们绘制DFD图、流程图，以及编写流程说明来描绘这一部分分析；而现在，在面向对象的时代，我们则是绘制行动图、状态图，以及编写用例说明来完成这部分工作。 在这部分工作中，编写用例说明应当是最主要的工作，之后在一些关键部分辅之以行动图、状态图。现在我们来看看用例说明应当怎样编写。 毫不疑问，做用例分析首