写点什么呢？按照原先的设想，应该开始动手写如何从业务用例转化到概念用例和系统用例，不过老实说这一步需要的是经验居多，而很难找出一个普适的步骤来。先暂时放一放吧，以后一定会写到的。上一篇讲到用例分析的一般步骤和方法，也给出了一个实例，不过没有做更进一步的说明，所以这一篇，笔者决定先罗嗦罗嗦之前的内容，说说业务建模中各种图的用法，以及它们对需求的贡献。
在说明实例之前，再重复一下的需求，并提醒读者下载实例，本文下面只会从实例中挑选很少一部分来说明，对照实例读者将能更好的理解。好了，让我们先回头看看需求吧，图书馆主任是这么说的：
我们原本是一个传统的图书馆，传统的借书方式要求读者亲自来到图书馆，这显得非常不方便，而且随着藏书的增加和读者群的增长，尤其而且大量的读者到图书馆，使得图书馆的场地不足，工作人员也不够了。所以想到借助网络，让读者通过网络借/还书，这样可以省掉大量的场地维护和工作人员成本支出，同时计算机可以方便的检索目录，让读者可以足不出户借到需要的书。为了把书送到借阅人手里，我们已经联系了A特快专递公司和B城市物流公司，初步达成协议，由他们往返借阅人和图书馆之间把图书送出和收回。读者在网上出示和验证借书卡，找到他们需要的书，提交申请，图书管理员确认后，就会通知物流公司来取书，当读者拿到书之后，物流公司需要把读者的签单拿回来以证明读者已经拿到了书。当然这个过程中，读者是需要付费的。还书也是基本同样的过程。
用户视角：
从用户视角查看每个用户在系统中将参与什么业务。这个视图的意义在于，调研对象一眼就能看出来，这个模型是否已经涵盖了他所有需要做的事。
业务视角：
从业务的视角查看每项业务是由哪些用例和哪些角色参与完成的。这个视图的意义在于，需求研讨会上业务专家可以一眼看出这个模型是否已经能够完整的表达业务。
第三步，针对每项业务视图，应该绘制业务场景图，用活动图详细描述这些用户、用例是如何交互来完成这项业务的。就象下面这样:
借阅图书业务过程:
业务场景图可能不止一个。同样一项业务，会有很多种不同的业务实现方式，例如借阅图书业务，就有可能第一次借书，又还书又借书，VIP客户借书，借书时借证已经到期....等等许多种场景。对于这些场景来说，每一个都不能漏掉或省略，至少必须在文档中体现出来，除非已经很明确这个业务场景不包括在系统范围之内。这些业务场景图的意义在于，它已经绘制出了一份系统蓝图，将来的系统建设很大程度将依据这些场景图进行。
经过上面的三个步骤，我们得到了用户、业务用例以及业务场景。这三项工作成果已经形成了基本的需求框架，并圈定了业务范围。就笔者的工作习惯而言，在得到这三个成果后，就会暂停调研，而通过评审会，研讨会等形式充分论证这些成果的正确性和完备性。求得业务专家，用户代表，开发方，项目经理等各方的一致认可，将其作为第一份基线。笔者很少在这个基线形成之前深入细化需求，因为需求过程，或说用例过程是一个自顶向向下的过程，RUP中的每一个迭代实际上仍然是一个瀑布模型，大家都知道，如果上一步没有形成基线就进行下一步，对瀑布模型来说是无法控制的。
好了，这一篇就到此为止，下一篇继续讨论用例场景，用例文档等建模过程。
上一篇确定了业务用例，以及业务场景。该场景只描述了业务框架，接下来要对业务用例进行场景分析。用例场景分析要用到三种视图，业务用例实现视图、业务用例场景、业务实体模型（领域模型），每个业务用例还应当写一份用例文档，也称为用例规约（UseCaseSpecification）。若有非功能性需求，例如性能要求，吞吐量要求等，还应当写一份补充用例规约。
上一篇说到我们经过初步的业务分析，得到了用户、业务用例以及业务场景模型。这三项工作成果形成了基本的需求框架，并圈定了业务范围。这时应当做一份基线。
上一篇确定了业务用例，以及业务场景。该场景只描述了业务框架，接下来要对业务用例进行场景分析。用例场景分析要用到三种视图，业务用例实现视图、业务用例场景、业务实体模型（领域模型），每个业务用例还应当写一份用例文档，也称为用例规约（UseCaseSpecification）。若有非功能性需求，例如性能要求，吞吐量要求等，还应当写一份补充用例规约。用例规约将在下一篇描述。
经过以上的过程，我们得到了什么呢？往下看之前笔者建议您回想一下，总结一下。
第一、我们通用用例实现视图，从业务用例中找出了那些我们将在系统中实现的用例，并且记录了要在系统中实现的用例是如何映射到原始需求的。这提供了需求可追溯的验证。
第二、针对每个用例实现，我们引入了计算机，将实际的业务从人-机交互的角度模拟了执行过程。不仅得到了一个业务怎样在计算机环境下执行的概念模型，同时也给用户描述了他们将怎么和计算机交互以达到他们的目标。笔者提醒大家，用例场景非常非常的重要，后续工作就得靠它们了！！绝对要认真对待，深入调研，不可漏掉一个场景，也不可模糊不清。
第三、通过对场景的分析，给了我们重要的线索去发现业务实体。而我们发现了业务实体之后，又通过用例场景来验证这些实体是否支持了用例的实现。
先说说业务规则。笔者习惯将业务规则分为三种。
第二种是交互规则。这种规则产生于用例场景当中，例如当提交一份定单时，哪些数据是必须填写的，用户身份是否合法。当然也包括一般理解上的业务流程流转规则等，例如金额大于一万元的定单被定为VIP定单进入特殊流程等。这类规则一般要写到用例规约中。交互规则实际上还有两个是比较特殊的，一个入口条件，也称为前置条件，即actor满足什么条件才能启动用例;另一个是出口条件，也称为后置条件，即用例结束后会产生哪些后果。稍后参看示例。
第三种是内禀规则。所谓内禀规则是指业务实体本身具备的规则，并且不因为外部的交互而变化的规则。例如，每张定单至少要有一件商品，同一类商品数量不能大于5件等。同时也包括大家所熟悉的数据效验规则，例如身份证号必须是15或18位，邮编必须是6位等等。这类规则是业务实体的内在规则，因此应该写到领域模型文档中，稍后参看示例。
题外话说了不少，书归正传。业务规则分类以后，就应该按分类去调研了。
全局规则很难从用户处调研得来，通常这方面是用户的盲点。这主要是由有经验的系统分析员，或架构师以及客户方的IT部门(如果有的话)，从业务特点、应用环境、行业规定、法律规章等等方面去总结，再求得客户方的认可。
到这里，需求过程差不多也该结束了。但是我们的确还有一些工作要做。如果读者所工作的组织是用RUP来做需求的，而客户方或者监理方未必会对这种需求文档表示满意。他们会以国标来要求你。同时，到目前为止，我们产生的成果都是一些分离的图形和文档，对于客户来说，这的确是不好的文档结构。难道客户的采购清单里还需要包括RationalRose，这样才能阅读你提供的需求文档吗？显然这是不可能的，所以，给用户提供的文档还是以传统的《需求规格说明书》为好。下一篇就讨论一下如何将我们的分析成本集成到《需求规格说明书》中。顺带讨论一下用例补充规约和系统原型的产生以及它的作用。敬请期待。（8）--如何编写一份完整的UML需求规格说明书为了让我们的需求更完美，这一篇所要做的工作也是必不可少的。这一篇将要讨论到的内容包括：用例补充规约，系统原型，以及需求规格说明书
终于到了快结束的时候了，这将是用例分析系列的最后一篇，结果是得到需求规格说明书，以结束需求分析的过程。经过前面七篇的工作，我们从最初的业务用例获取入手，获得了业务用例模型，这是我们的业务范围；经过分析得到了业务场景，这是我们的业务蓝图；经过规划，得出用例实现视图，这是我们的系统范围；经过再次分析，得到了用例实现以及领域模型，包括用例规约，业务规则和业务数据，这是我们的概念模型。仅从需求所需的必要元素来说，我们基本上已经完成了需求分析的工作。诚如上一篇结尾所说，为了让我们的需求更完美，这一篇所要做的工作也是必不可少的。这一篇将要讨论到的内容包括：用例补充规约，系统原型，以及需求规格说明书
先说说用例补充规约。
之前我们得到的用例规约是功能性的，它们是针对Actor完成目标业务所需的功能性Feature的描述。然而我们所面对的系统除了功能性的Feature之外，总有一些是与业务功能无关的，这部分需求就是补充规约要涉及的内容。
什么样的需求与业务功能无关呢？一般来说，就是系统需求，例如可靠性，可用性，扩展性，易用性等等。用户提出，系统必须提供7*24小时的服务，它应该有一定随业务变化而适应的能力，系统的界面应当简单易学，具备基础计算机知识的人可以不经过培训就能使用它等等。这些需求与具体业务要求无关，哪怕一个不实现，系统也能Run起来。但是这些需求又是如此重要，它们是系统达到用户期望必不可少的。甚至在用户看来，某些补充规约要求比业务要求还重要，某个业务要求没做好，用户或许能宽容，如果你说系统不能提供7*24小时的服务，用户肯定是不能接受的。这些需求，就是要在补充用例规约里面说明的内容。
至于补充规约的格式就没那么重要了，只要将用户提出的，或者用户未提出，但作为系统建设者知道系统要很好运行就必须去加入的那些特性，都一一写明白了，就OK了。当然，有时某个补充要求的确只与一个特定的用例有关，例如交纳借阅费，有一个可能的补充要求是保障安全性，包括数据安全，传输安全。其它用例则没有必要进入安全通道。这时，专门为交纳借阅费用例写一个补充规约也是合理并且推荐的方式。
我们在做需求时所需的原型主要是辅助性的，将用例场景转化成可操作的原型，如果是做Web系统，则基本上就是静态html。第一，它能帮助系统分析员更好的与用户交流，同时让脑子湖涂的用户明白，哦，原来就是这样的啊......第二，这个原型能帮助用户深化需求，凭空想象用户很难提出具体而清晰的需求，当面对一个可以操作的界面时，往往文思泉涌。第三，这个原型能帮助系统分析员验证需求分析的结果，如果将用例场景的文字描述转化成界面以后难以操作，那就得回头修改用例场景了。
那么需求的系统原型是抛弃型的还是渐进型的呢？不一定。有的组织有快速页面生成工具，能很快的将需求转化成界面，这些界面简单，不能满足开发要求，需求结束后往往被抛弃；有的组织为了在需求过程中将用户LookandFeel的需求也一并收集，会精心开发界面原型，这些界面就成为将来的开发基础。的确大部分组织是将html开发完成后，由程序员填入动态代码而形成ASP,JSP等动态网页的。
我们的所有准备工作都完成了，即将交出工作成果--需求规格说明书。有的读者会奇怪，之前我们做的工作不都是需求说明吗？怎么又来一个需求规格说明书？原因是这样，我们之前的工作的确都是需求说明，但是，这些需求说明是零散的，组织不好的。就拿笔者给大家提供的实例来说，读者在看的时候感觉如何？没有章节，没有提纲，也看不出作者的组织思路，要看明白一个需求，要点好几个图，展开好几层。对系统分析员来说不是什么问题，但对用户而言呢？你能指望他们满意这样的文档而让你验收通过吗？另一个原因是，现在系统建设一般都会按照国标来要求文档提供，例如GB9385-88，尤其请了监理的用户更是如此。因此，写一份符合国标格式要求的需求文档是非常有必要的。
不必担心需求规格说明书会给你带来多大的工作量，其实所有的元素已经具备，需要做的工作不过是将这些元素组织到一起而已。笔者提供一个简单的例子以说明如何将他们组织起来。但这个例子并不是说明这是一个标准格式，你应当根据组织规范，用户要求来组织这些元素。笔者想说明的只是一个组织文档的思路和哪些元素是必须的以供参考。