（5）--用户、业务用例和业务场景

写点什么呢？按照原先的设想，应该开始动手写如何从业务用例转化到概念用例和系统用例，不过老实说这一步需要的是经验居多，而很难找出一个普适的步骤来。先暂时放一放吧，以后一定会写到的。上一篇讲到用例分析的一般步骤和方法，也给出了一个实例，不过没有做更进一步的说明，所以这一篇，笔者决定先罗嗦罗嗦之前的内容，说说业务建模中各种图的用法，以及它们对需求的贡献。

在说明实例之前，再重复一下的需求，并提醒读者下载实例，本文下面只会从实例中挑选很少一部分来说明，对照实例读者将能更好的理解。好了，让我们先回头看看需求吧，图书馆主任是这么说的：

我们原本是一个传统的图书馆，传统的借书方式要求读者亲自来到图书馆，这显得非常不方便，而且随着藏书的增加和读者群的增长，尤其而且大量的读者到图书馆，使得图书馆的场地不足，工作人员也不够了。所以想到借助网络，让读者通过网络借/还书，这样可以省掉大量的场地维护和工作人员成本支出，同时计算机可以方便的检索目录，让读者可以足不出户借到需要的书。为了把书送到借阅人手里，我们已经联系了A特快专递公司和B城市物流公司，初步达成协议，由他们往返借阅人和图书馆之间把图书送出和收回。读者在网上出示和验证借书卡，找到他们需要的书，提交申请，图书管理员确认后，就会通知物流公司来取书，当读者拿到书之后，物流公司需要把读者的签单拿回来以证明读者已经拿到了书。当然这个过程中，读者是需要付费的。还书也是基本同样的过程。

还记得上一篇是怎么说的吗？第一步骤是从涉众中找出用户。并定义这些用户之间的关系。 这里的用户是指将与要建设的系统发生关系的那些涉众。通过下图表示。这张图里要绘出所有用户，以及它们之间的关系。需要说明的是，这里的用户指的是业务用户，并非将来系统中的“角色”，虽然将来它们可能就是。这张图的意义在于，清楚的表明将来的系统是为谁在服务，他们都是干什么的，有什么特点，有什么关系。对用例方法来说，这是最基本的出发点。用例，是以人为本的。

第二步，找出每个用户要做的事，即业务用例。业务用例来自于系统分析员对上一步中所有用户的访谈，总结和归纳（笔者正在考虑写一写系统分析员调研技巧方面的文章，会对访谈技巧，归纳方法有所描述）。笔者建议从每个用户的角度以及从每项业务的角度来绘制业务用例图，就象下面这样：

用户视角：

从用户视角查看每个用户在系统中将参与什么业务。这个视图的意义在于，调研对象一眼就能看出来，这个模型是否已经涵盖了他所有需要做的事。

业务视角：

从业务的视角查看每项业务是由哪些用例和哪些角色参与完成的。这个视图的意义在于，需求研讨会上业务专家可以一眼看出这个模型是否已经能够完整的表达业务。

第三步，针对每项业务视图，应该绘制业务场景图，用活动图详细描述这些用户、用例是如何交互来完成这项业务的。就象下面这样:

借阅图书业务过程:

业务场景图可能不止一个。同样一项业务，会有很多种不同的业务实现方式，例如借阅图书业务，就有可能第一次借书，又还书又借书，VIP客户借书，借书时借证已经到期....等等许多种场景。对于这些场景来说，每一个都不能漏掉或省略，至少必须在文档中体现出来，除非已经很明确这个业务场景不包括在系统范围之内。这些业务场景图的意义在于，它已经绘制出了一份系统蓝图，将来的系统建设很大程度将依据这些场景图进行。

经过上面的三个步骤，我们得到了用户、业务用例以及业务场景。这三项工作成果已经形成了基本的需求框架，并圈定了业务范围。就笔者的工作习惯而言，在得到这三个成果后，就会暂停调研，而通过评审会，研讨会等形式充分论证这些成果的正确性和完备性。求得业务专家，用户代表，开发方，项目经理等各方的一致认可，将其作为第一份基线。笔者很少在这个基线形成之前深入细化需求，因为需求过程，或说用例过程是一个自顶向向下的过程，RUP中的每一个迭代实际上仍然是一个瀑布模型，大家都知道，如果上一步没有形成基线就进行下一步，对瀑布模型来说是无法控制的。

好了，这一篇就到此为止，下一篇继续讨论用例场景，用例文档等建模过程。

（6）--用例实现、用例场景和领域模型

上一篇确定了业务用例，以及业务场景。该场景只描述了业务框架，接下来要对业务用例进行场景分析。用例场景分析要用到三种视图，业务用例实现视图、业务用例场景、业务实体模型（领域模型），每个业务用例还应当写一份用例文档，也称为用例规约（UseCase Specification）。若有非功能性需求，例如性能要求，吞吐量要求等，还应当写一份补充用例规约。

上一篇说到我们经过初步的业务分析，得到了用户、业务用例以及业务场景模型。这三项工作成果形成了基本的需求框架，并圈定了业务范围。这时应当做一份基线。

当然，第一份基线所包括的内容是非常粗的，要达到完整的需求说明还有更多工作要做。这一篇就来说说详细的需求过程和产出物，以及这些成果对需求的贡献。在开始之前，还是提醒读者下载实例，本文下面只会从实例中挑选很少一部分来说明，对照实例读者将能更好的理解。

上一篇确定了业务用例，以及业务场景。该场景只描述了业务框架，接下来要对业务用例进行场景分析。用例场景分析要用到三种视图，业务用例实现视图、业务用例场景、业务实体模型（领域模型），每个业务用例还应当写一份用例文档，也称为用例规约（UseCase Specification）。若有非功能性需求，例如性能要求，吞吐量要求等，还应当写一份补充用例规约。用例规约将在下一篇描述。

• 首先是业务用例实现视图。并非所有的业务用例都一定要最终在系统中实现，因此，这个视图的含义是表达由需求范围到系统范围的映射关系。这个视图没什么技巧，也可以省略，不过笔者建议不要省略。需求应当保持过程的连续和可追溯性，这是软件过程可控的重要保证。

  业务用例实现视图：
  

• 针对每个业务用例实现，应当对用例的实现过程进行场景模拟。上一篇是业务场景，而用例实现既然已经谈到“实现”，则应当将计算机包括进来，从人-机交互的视角来模拟业务场景。这是概念模型的一种，表达用户的实际业务在计算机环境下是如何实现的，给用户一个初步印象，告诉他们将来他们将怎样来做业务。请注意，虽然计算机已经参与需求描述，但是要尽量避免使用计算机术语，因为这时的文档仍然属于需求文档，是要与用户交流的，太多的计算机术语会大大降低用户对需求的理解能力。霍金在写时间简史时曾经说过，在书中加入哪怕一个数学公式，都会让书的销量减半。业务用例场景是概念模型的一种，但不是概念模型的全部。概念模型本篇不打算讨论，简单说一下，概念模型主要包括业务架构和系统原型。
  应当在业务用例实现里添加活动图用以描述用例场景，下图为示例，用活动图绘制。如果有多个场景，则应当绘制多个场景图。

  业务用例场景(借书过程)：
  

• 用例场景有另一个重要意义，是帮助系统分析员发现和定义业务实体。业务实体一般来说就是调研时用户所提供的各类表单或报表，但在很多情况下，并非每一份表单就是一个业务实体，所有业务表单也不一定涵盖全了所有业务实体。很多系统分析员声称业务实体的发现过程是全凭经验的，到底有哪些业务实体，靠经验进行提取。笔者要说，经验固然重要，但经验有一个最大的缺陷---不能重复和验证。即，这些实体是怎么从业务中提取出来的？它们是怎样参与业务的？这些实体已经足够支持业务了吗？凭经验分析者无法通过文档将这个提取过程记录下来，而脑子里的东西是无法共享和传承的，越大的团队，越复杂的项目，尤其是横向结构的项目组结构下，这个缺陷越严重。很多人觉得用UML和RUP描述的需求总是一块块分离的，不知道是怎么出来的，觉得很乱，原因就在于此。实际上，RUP做需求，每一步都是可验证和回溯的。用例实现视图是一个例子，这里也是一个例子。
  让我们看看上面的业务场景视图，每一个活动都有类似的命名：出示借阅证、查找需要的图书、放入借书栏.....看出什么来了吗？每个活动都是一个动作加上一个动作的受体。受体正是我们要寻找的业务实体，这些名词就是实体的来源。在需求阶段，系统分析员不要去考虑什么抽象，什么模式，别急，那是系统模型做的事情。抽象了，还弄一堆什么Factory模式，Builder模式之类的出来，用户能看懂吗？别忘了我们正在做的是需求文档，是做给用户看的。
  观察上面的用例场景，分析出现的名词，我们得到一个个业务实体，再根据场景分析这些业务实体之间的关系。实际上就是大家都熟悉的ER模型，但是与数据库建模的视角还是有所差别的。数据库ER模型要受到数据关系范式的限制，而业务实体ER模型则不必理会这种限制。只要与现实物体符合就OK。好了，罗嗦了一大堆，我们终于得到了我们的成果。

  借阅图书过程业务实体视图：
  

上图中画那么多虚线连接到业务用例实现是用来表示业务实体与业务用例实现之间的追溯关系的，这些线虽然麻烦，但是笔者强烈建议不要图省事。因为业务实体通过它们可以追溯到原始需求，再次重申，软件过程要可控，需求可追溯是需要时时谨记的。当然，如果嫌麻烦，您也可以用下面的这种形式，是不是简洁得多呢？

经过以上的过程，我们得到了什么呢？往下看之前笔者建议您回想一下，总结一下。

第一、我们通用用例实现视图，从业务用例中找出了那些我们将在系统中实现的用例，并且记录了要在系统中实现的用例是如何映射到原始需求的。这提供了需求可追溯的验证。

第二、针对每个用例实现，我们引入了计算机，将实际的业务从人-机交互的角度模拟了执行过程。不仅得到了一个业务怎样在计算机环境下执行的概念模型，同时也给用户描述了他们将怎么和计算机交互以达到他们的目标。笔者提醒大家，用例场景非常非常的重要，后续工作就得靠它们了！！绝对要认真对待，深入调研，不可漏掉一个场景，也不可模糊不清。

第三、通过对场景的分析，给了我们重要的线索去发现业务实体。而我们发现了业务实体之后，又通过用例场景来验证这些实体是否支持了用例的实现。

现在请读者思考一下，如果记不清了，可以翻翻之前的文章。到现在为止，我们的需求是不是一步一步推出来的？从粗到细，从模糊到清晰，从原始需求到计算机的引入，是不是每一步都是可以追溯的呢？每一步的分析结果是不是都有方法来验证正确性和完备性呢？如果您之前迷惑于需求的各个阶段无法关联，也说不清分析结果是否是正确的，那么建议您再从头看看笔者目前已经完成的文章，找出这些线索来，相信您会对UML和RUP的理解提高一个层次的。

这篇文章该结束了。可是等等，到目前为止，虽然我们已经得到了不少产品，或可交付物，或成果，或deliverable...不管叫什么吧，我们已经做了很多工作了。不过作为需求来说，好象还缺点什么吧？对了，我们还缺少业务规则和业务实体的详细属性，这两个需求必不可少的内容，将在下一篇中讨论。敬请期待。

（7）--用例规约的编写--业务规则和实体描述

先说说业务规则。笔者习惯将业务规则分为三种。

一种是全局规则，这种规则一般与所有用例都相关而不是与特定用例相关，例如actor要操作用例必须获得相应的授权，用例的操作与授权级别相关，或者用户在系统中的所有操作都要被记录下来等等。这类规则笔者习惯于，并且也建议将它们写到用例的补充规约里面去，因为它们一般与具体的业务功能性要求没有直接关系。有时候，这类规则也被写到软件架构文档中。关于用例补充规约以后再讨论。

第二种是交互规则。这种规则产生于用例场景当中，例如当提交一份定单时，哪些数据是必须填写的，用户身份是否合法。当然也包括一般理解上的业务流程流转规则等，例如金额大于一万元的定单被定为VIP定单进入特殊流程等。这类规则一般要写到用例规约中。交互规则实际上还有两个是比较特殊的，一个入口条件，也称为前置条件，即actor满足什么条件才能启动用例;另一个是出口条件，也称为后置条件，即用例结束后会产生哪些后果。稍后参看示例。

第三种是内禀规则。所谓内禀规则是指业务实体本身具备的规则，并且不因为外部的交互而变化的规则。例如，每张定单至少要有一件商品，同一类商品数量不能大于5件等。同时也包括大家所熟悉的数据效验规则，例如身份证号必须是15或18位，邮编必须是6位等等。这类规则是业务实体的内在规则，因此应该写到领域模型文档中，稍后参看示例。

读者或许对把规则这么分类有不同的习惯和理解，可能会觉得麻烦。但是笔者这么做有充分的理由。首先，全局规则与具体用例无关，它实际是系统应该具备的特性，这些规则把它分出来目的就是为了让系统去负责这些特性的实现。读者可以结合实际考虑一下，通常授权，事务，备份等特性都是由系统框架去实现的，具体的功能中并不去实现它们。如果读者有过基于某个框架开发应用的经历的话一定会认同笔者的话。其次，交互规则是在用例场景当中产生的，它们规定了满足什么条件后业务将如何反应。通常，这部分规则是最复杂，也最不稳定，最容易变化的。大家所说的需求经常变更相信绝大部分就来自于此。因此将这些规则单独列出来并给予关注和管理是很有必要的。同时这部分规则通常在系统中以Control类去实现，MVC模式如此，SOA架构中的BPEL也是如此。如果需求无可避免的要变更，那么，将交互规则单独提取出来，并设计成为扩展性很强的结构就是一种有效的应对手段。第三，内禀规则与外部交互无关，不论谁，在什么情况下提交定单，必须有至少有一件商品；不论你在哪个国家，在什么公路上开车，刹车都是必不可少的。这种内在的性质让你想到了什么？面向对象的封装原则对吗？这类规则应该实现到你的实体类中去，不论你的业务实体是EntityBean,JavaBean,POJO还是COM+，根据面向对象的封装原则，内禀的逻辑一定不要让它暴露到外部去。

这么分类以后，对软件成熟度比较高的组织来说，提供了很好的Level Reference。如果你是架构师，应该关注的是全局规则；如果你是设计师，应该关注的是交互规则；如果你是程序员，应该关注的是内禀规则。

在这里笔者想说点题外话：）。笔者曾经看过一篇《架构师已死》的文章(很抱歉已经记不起出处和作者，如有冒犯之处请海涵)，作者的观点认为架构设计完成后，通常到最后改得面目全非，既然一开始不可能考虑到所有可能，何不如在开发过程中持续总结，重构，最后架构会自然而然出来的，如果这样，架构师有何用处呢？笔者认为这个说法是有一定道理的，不过要看软件组织架构和软件过程的定义，不可一概而论。《架》一文的作者是XP的fans，对XP软件过程来说，本来就不需要架构师这个角色，甚至连设计都不需要，开发，测试，改进，重构...，当然，从一开始就没打算按照一个stable的方法去做，架构师也就没有存在的必要。架构师在XP中已死，不过在RUP中还活着：）。软件界一直对XP和RUP有着争论，笔者无意在本文中界入这个争执，只是话已经到此，就顺便表达一下笔者观点。XP和RUP都是非常优秀的软件方法，只是它们各有各的适应范围。对于中小型公司和中小型软件来说，XP是非常有效的管理方法，它能大大降低管理、开发成本和技术风险。不过要是对于大公司和大型项目来说，XP就不适用了，这时RUP却非常适合。你能想象洛克希德·马丁公司用XP的方法来开发F-35战斗机会是一个什么情形吗？没有人清楚的知道将来的飞机整体是什么样，反正先造一架出来，摔了找找原因，改进改进，重构一下，再造一架....再摔了，没关系，咱们拥抱变更，再造就是了。呵呵，那XP什么情况下适用呢？如果你是一个杂货店的老板，不知道什么样的商品受欢迎，没关系，先各进一小批货，卖上一段时间，受欢迎的货品多进，不受欢迎的不进，跟顾客多交流，顾客喜欢什么商品咱就进什么，不断改进，最后一定会顾客盈门的。这时如果这个老板先做商业分析，客户关系分析，消费曲线分析....还没开业呢，估计就破产了。另外，RUP和XP也不是非此即彼的关系，在造F-35的过程中，对整体飞机来说，用RUP是适合的，具体到发动机的提供商，倒是大可XP一把，最终只要提供合格的发动机就OK了。

题外话说了不少，书归正传。业务规则分类以后，就应该按分类去调研了。

全局规则很难从用户处调研得来，通常这方面是用户的盲点。这主要是由有经验的系统分析员，或架构师以及客户方的IT部门(如果有的话)，从业务特点、应用环境、行业规定、法律规章等等方面去总结，再求得客户方的认可。

交互规则从用例场景而来，每一个场景，场景中每一个交互的过程可能都隐含着规则。这就需要与客户多讨论。请参考本系列文章的第3篇关于涉众的讨论，交互规则最主要的来源是业务提出者和业务管理者，最好不要去找业务执行者。

内禀规则是针对业务实体的，因此要对每个业务实体的属性进行罗列，并找出它们的规则。内禀规则最主要的来源是业务执行者，需求人员应该更多的去与他们交流。

现在来谈谈业务实体的属性。业务实体的属性在这个阶段应该用业务术语来描述，而非计算机术语。调研范围是上一篇模型中得到的领域模型中的每一个实体，而属性的原始来源是客户的各类实际表单，以及在交流过程中客户提出的各种要求。如果业务实体有状态，并且是比较复杂的，那么在建模的时候应该有一个状态图来说明。请参看本系统文章提供的建模实例中'图书'业务实体下面的状态图。请读者注意，在本文后面提供的例子中，业务实体描述看上去象是一张数据表，但它绝对不是数据表。它是对业务中实体属性的业务角度描述。系统分析不是做设计，脑子里不要有任何关于设计或实现方法的想法，这些想法会误导你做出不适合的决定。你的职责是通过一个合理的模型完整的将业务描述出来，并求得客户方的认可。任何替客户和架构师，设计师甚至程序员“着想”的方法其实都是不恰当的。

最后本文提供一个用例规约的例子，每个用例都应该写一份用例规约。本文提供的这个例子基本上来自RUP提供的模板，不过在实际工作中笔者做了些修改，供读者参考。这个例子的蓝本还是本系统文章一直在使用的网上图书馆的实例。点这里下载用例规约例子，点这里下载建模实例。

到这里，需求过程差不多也该结束了。但是我们的确还有一些工作要做。如果读者所工作的组织是用RUP来做需求的，而客户方或者监理方未必会对这种需求文档表示满意。他们会以国标来要求你。同时，到目前为止，我们产生的成果都是一些分离的图形和文档，对于客户来说，这的确是不好的文档结构。难道客户的采购清单里还需要包括Rational Rose，这样才能阅读你提供的需求文档吗？显然这是不可能的，所以，给用户提供的文档还是以传统的《需求规格说明书》为好。下一篇就讨论一下如何将我们的分析成本集成到《需求规格说明书》中。顺带讨论一下用例补充规约和系统原型的产生以及它的作用。敬请期待。

（8）--如何编写一份完整的UML需求规格说明书

为了让我们的需求更完美，这一篇所要做的工作也是必不可少的。这一篇将要讨论到的内容包括：用例补充规约，系统原型，以及需求规格说明书

终于到了快结束的时候了，这将是用例分析系列的最后一篇，结果是得到需求规格说明书，以结束需求分析的过程。经过前面七篇的工作，我们从最初的业务用例获取入手，获得了业务用例模型，这是我们的业务范围；经过分析得到了业务场景，这是我们的业务蓝图；经过规划，得出用例实现视图，这是我们的系统范围；经过再次分析，得到了用例实现以及领域模型，包括用例规约，业务规则和业务数据，这是我们的概念模型。仅从需求所需的必要元素来说，我们基本上已经完成了需求分析的工作。诚如上一篇结尾所说，为了让我们的需求更完美，这一篇所要做的工作也是必不可少的。这一篇将要讨论到的内容包括：用例补充规约，系统原型，以及需求规格说明书

先说说用例补充规约。

之前我们得到的用例规约是功能性的，它们是针对Actor完成目标业务所需的功能性Feature的描述。然而我们所面对的系统除了功能性的Feature之外，总有一些是与业务功能无关的，这部分需求就是补充规约要涉及的内容。

什么样的需求与业务功能无关呢？一般来说，就是系统需求，例如可靠性，可用性，扩展性，易用性等等。用户提出，系统必须提供7*24小时的服务，它应该有一定随业务变化而适应的能力，系统的界面应当简单易学，具备基础计算机知识的人可以不经过培训就能使用它等等。这些需求与具体业务要求无关，哪怕一个不实现，系统也能Run起来。但是这些需求又是如此重要，它们是系统达到用户期望必不可少的。甚至在用户看来，某些补充规约要求比业务要求还重要，某个业务要求没做好，用户或许能宽容，如果你说系统不能提供7*24小时的服务，用户肯定是不能接受的。这些需求，就是要在补充用例规约里面说明的内容。

笔者自己有个习惯，在上一篇也有所提及，就是习惯于把全局规则也写到补充用例规约里面。比如，用户提出，所有系统使用者在系统中的任何操作，都要能够记录下来；如果数据被更改，不论是Modify,Add还是Delete，数据都要做一个备份；响应时间可能超过1分钟的功能，都要提供进度条等等...这些全局规则在实际情况中，一般都是由系统框架，或某个中间件来完成的，它们是系统架构的一部分。因此这些需求虽然也是功能性的，但笔者认为将它们作为补充需求，与可靠性之类的系统需求一起，由较高层次的设计师或者是架构师来处理它们更合适。

那么补充用例规约到底是一个用例写一份还是全部集中在到一起呢？RUP提供的模板是一个用例写一份，只要它们与该用例相关。笔者在实际工作中觉得集中在一份文档中似乎更合理。一是减轻很多的重复工作量，二是集中在一起更便于管理和验证。

至于补充规约的格式就没那么重要了，只要将用户提出的，或者用户未提出，但作为系统建设者知道系统要很好运行就必须去加入的那些特性，都一一写明白了，就OK了。当然，有时某个补充要求的确只与一个特定的用例有关，例如交纳借阅费，有一个可能的补充要求是保障安全性，包括数据安全，传输安全。其它用例则没有必要进入安全通道。这时，专门为交纳借阅费用例写一个补充规约也是合理并且推荐的方式。

再来说说系统原型。所谓系统原型根据目的不同，也分为好多种，本文无意深入探讨，大致说说，并只描述与需求过程相关的原型。例如，我们可能要使用一个全新的技术，为了验证其技术可行性，可能会开发一个小的原型，以掌握或证明我们能够使用这种技术，也证明这项技术能够支持后续的开发，这是一种验证性原型；我们有一个初步的想法，但不知往下能走多远，这个想法是否可行，也可以开发一个原型，这是一种探索型原型；我们要向别人说明某个产品，为了形象化，也可以开发一个原型，以显式的向别人展示以加深理解，这是一种辅助原型...目的不同，原型也有多种。另一种分类方法是将原型分为抛弃型的和渐进型的，所谓抛弃，就是用完了就扔了，渐进型的，则是将来会在它基础上逐步完善，乃至形成最终系统。

我们在做需求时所需的原型主要是辅助性的，将用例场景转化成可操作的原型，如果是做Web系统，则基本上就是静态html。第一，它能帮助系统分析员更好的与用户交流，同时让脑子湖涂的用户明白，哦，原来就是这样的啊......第二，这个原型能帮助用户深化需求，凭空想象用户很难提出具体而清晰的需求，当面对一个可以操作的界面时，往往文思泉涌。第三，这个原型能帮助系统分析员验证需求分析的结果，如果将用例场景的文字描述转化成界面以后难以操作，那就得回头修改用例场景了。

那么需求的系统原型是抛弃型的还是渐进型的呢？不一定。有的组织有快速页面生成工具，能很快的将需求转化成界面，这些界面简单，不能满足开发要求，需求结束后往往被抛弃；有的组织为了在需求过程中将用户Look and Feel的需求也一并收集，会精心开发界面原型，这些界面就成为将来的开发基础。的确大部分组织是将html开发完成后，由程序员填入动态代码而形成ASP,JSP等动态网页的。

系统原型什么时候需要呢？虽然本系列文章到最后才来讨论它，但笔者的建议是从一开始就要开始原型的制作。很多人抱怨需求难做，用户讲不清又说不明，今天说的跟明天不一样，抱怨用户根本不懂计算机。有此抱怨是正常的，需求从来就不是容易的，但如果以这为借口而做不出好的需求，那就只能说明你不 是一个合格的系统分析员了。用户如果都懂计算机，还要你做什么？还好意思拿着"高薪"，号称"高新技术人才"么？把用户想说又说不出来，或者根本不想说的东西套出来，这就是系统分析员的职责。原型在这里将起到巨大的帮助作用，一个图形化的展示胜过千言万语，UML的诞生也是这个原因。在需求的初始阶段，界面原型或许还开发不出来，但是，用Word,Visio,Powpoint画几个简单的图示不困难吧？甚至在草稿纸上手工画画界面原型，也会对你跟用户的交流起到巨大的作用。

我们的所有准备工作都完成了，即将交出工作成果--需求规格说明书。有的读者会奇怪，之前我们做的工作不都是需求说明吗？怎么又来一个需求规格说明书？原因是这样，我们之前的工作的确都是需求说明，但是，这些需求说明是零散的，组织不好的。就拿笔者给大家提供的实例来说，读者在看的时候感觉如何？没有章节，没有提纲，也看不出作者的组织思路，要看明白一个需求，要点好几个图，展开好几层。对系统分析员来说不是什么问题，但对用户而言呢？你能指望他们满意这样的文档而让你验收通过吗？另一个原因是，现在系统建设一般都会按照国标来要求文档提供，例如GB9385-88，尤其请了监理的用户更是如此。因此，写一份符合国标格式要求的需求文档是非常有必要的。

不必担心需求规格说明书会给你带来多大的工作量，其实所有的元素已经具备，需要做的工作不过是将这些元素组织到一起而已。笔者提供一个简单的例子以说明如何将他们组织起来。但这个例子并不是说明这是一个标准格式，你应当根据组织规范，用户要求来组织这些元素。笔者想说明的只是一个组织文档的思路和哪些元素是必须的以供参考。

最后需要说明的一点是，在这个例子里，分了用户需求和系统需求两个部分，这对应着业务用例和用例实现。用户需求不一定是系统需求，某些用户需求是不必实现到系统中的，例如本系列文章示例中的图递送过程，缺了它用户需求就不完整，但实际上这是一个人工过程，不需计算机的参与；同时用户需求也未必全部包含系统需求，例如用户需求中未提及事务处理，操作记录，但作为一个健壮的系统，这些需求又是必不可少的。

后记...

前后经过大半年，关于系统分析员用例分析的文章到这里就结束了。期间承蒙网友们的支持与鼓励，才走到今天。系统分析和UML是一个庞大的话题，短短的八篇文章仅能够揭起冰山一角。实践比理论学习能更快的成长。就笔者自己而言，若要论及理论知识，未必及得上科班出身的系统分析员们。只是实践多了，就有些经验积累下来，以至能与诸位分享。笔者相信，理论--实践--理论，永远是一条不二的成长途径。只要本系列文章对大家还有些帮助，就不枉这半年多的笔耕了。

笔者不寄望于能在这短短八篇文章里将所有知识和经验都讲到，也不保证有需要的读者一定能在这里找到答案。但笔者的Blog还在，也还没有从此收山的打算，只是这一系列文章到了该结束的时候了。若读者有疑问，有指教，都可以在我的BLog里留言，以武会友就是专门为大家准备的。笔者保证每条留言都会回复的。谢谢大家。

作者coffeewoo 欢迎您访问文章原始出处 : http://coffeewoo.itpub.net ，阅读中有任何问题可以在BLOG上留言或发邮件到 coffeewoo@263.net，我将尽力为您解答。具有代表性的问题我会以 Q &A的形式收录到对应的文章之后。希望本系列文章对您有帮助。欢迎转载，敬请注明，谢谢 ^_^