充满诗意的联盟

我曾经看过许多关于需求分析的书籍，老外写的，国人写的，都有。但我总体就是一个感觉：累。各种各样的分析、各种各样的视图，让人眼花缭乱。为什么会这样呢？不得不说，需求分析是一个太宽泛的概念了，不同的行业（商业的、管理的、游戏的），不同类型的软件（底层的、桌面的、网络应用的），不同的设计方式（面向过程的、面向对象的），需求分析的过程都存在着巨大的差异。要制订放之四海而皆准的方法谈何容易。即使同一类型的软...

另一种就是客户压根儿没有想到的需求。也许你会提出这样的疑问，客户压根儿没有想到的需求我们还提出来做什么？这种压根儿没有想到的，实际是在业务需求阶段压根儿没有想到的，并不代表最终都没有想到。很多开发人员总在埋怨，说客户需求总是在软件项目的后期改来改去，为什么？客户并不是软件研发领域的专业人员。在业务需求阶段，由于没有可以展示和操作的实物，客户总是在空对空的凭空想象今后的软件应当做成什么样子。这就注定...

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

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

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

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

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

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

前面，我们耗费了大量的篇幅来讨论用例分析及用例图。用例图，无疑是功能分析、角色分析，以及流程分析的利器，它将我们要开发的系统，清晰而详尽地描述出来。但是，正如任何事物都有两面性，用例图也不例外，也有自己不利的一面。在我看来，这集中体现在两个方面：只见树木不见森林、不生动形象。什么叫“只见树木不见森林”呢？就是说，用例说明中对业务流程的描述，过早地将系统的整体流程，分散到了各个用例中了，丢失...

在需求分析工作中，最后一项分析工作就是业务领域分析啦。业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。前面我们谈到了功能角色分析，或者说用例分析，它是从整体的角度对整个系统人机交互的分析与整理。随后我们谈到了业务流程分析，它是在对系统人机交互的分析与整理的基础上，更加细致的去分析和整理那些业务流程，以及组成这些流程的一个个业务操作。业务流程分析是对系统进行的一种动态...

原文分析法（Textual Analysis），是在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。当我们完成了用例图的绘制，为每个用例编写出用例说明以后，原文分析的工作就可以开始了。要讲解原文分析，我们还是用一个实例更简单明了：[img]http://dl.iteye.com/upload/attachment/0066/7121/d4e78778...

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

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

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

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

需求分析是一个我们与客户不断沟通的过程，这个过程就如同我们与老板的一次对话。老板把你叫去，给你交待了一大堆任务。我们首先是仔细聆听任务的内容，然后整理个一二三四。然后我们复述一遍老板的意思：“老板，我复述一遍，您看看我理解得对不对。首先，您要求我×××，然后×××，最后×××。”老板：“恩，就是这意思，你照着办吧。”之后，我们开始了我们的工作。这个复述的步骤相当重要，因为人与人的沟通最大的问题就是...

现在我举一个具体实例来看看需求列表是怎样编写的吧。这是一个公司内部的评审系统，它分为制订评审计划、执行评审、制作评审报告与问题跟踪四部分。经过初次与评审人员的业务讨论以后，我们整理出这样一个需求列表：1．评审发起人填写一份评审计划，详细记录评审时间、评审内容、评审者、评审地点，制订评审组长，并预计评审工作量，发起一个评审任务。2．评审者在收到邮件后，进入评审任务中，对评审内容进行评审，...

常常听到许多朋友跟我埋怨，需求分析之难，就在于用户自身就常常弄不清楚自己的需求。起初在需求确认的时候说得好好的，一到软件上线的时候就不是那么回事了，这可没法整。但我们只要坐下来仔细分析就会发现，在需求分析的时候我们跟用户是在空对空地讨论问题。用户不是专业人士，他也搞不清楚软件到底会做成啥样，所以你跟他确认的时候他就点头了。但是，用户不是傻子，当你软件上线时，他拿到了实物了，知道软件做成啥样了，一旦...

曾经有项目组拿着用户编写的原始需求就开始开发，随后状况不断，一次令人崩溃的研发过程。拿着用户编写的原始需求，编写我们自己的需求规格说明书，之所以重要，就在于用户编写的原始需求，是脱离了技术实现，编写的一份十分理想的业务需求。理想与现实总是有差距，我们之所以要编写自己的需求规格说明书，就是要本着实事求是、切实可行的态度，去描述用户的业务需求。那些不可行的需求被摒弃，或者换成更加可行的解决方案。这就是...

时间过得真快，经过一系列需求研讨、需求分析和整理确认，我们整理出了需求列表，编写出了需求规格说明书，一切似乎该到结束需求分析阶段的时候了。但是，敏捷大师的一句话让我们彻底心凉到了骨头里。敏捷大师说了，我们不可能在需求分析阶段完成所有的需求分析工作，它将延续到设计、开发，甚至测试阶段。一直以来，我对这句话非常困惑。既然需求分析阶段不能完成所有的需求分析工作，那么完成多少才算结束呢？80%？6...

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

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

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

2007年，世界级的软件分析大师Eric Evans发表了他的经典著作《领域驱动设计》，进而形成了一套独特的软件分析与设计方法，简称为DDD（Domain-Driven Design）。在领域驱动设计思想中，有许多是涉及到需求分析领域的先进方法，我把它归纳为有效建模、统一语言和持续学习。有人说：大师所站的高度实在太高了，是生活在太空里的，所以我们要追随大师就只有因为缺氧而死掉。我认为这句话...