终于到了快结束的时候了，这将是用例分析系列的最后一篇，结果是得到需求规格说明书，以结束需求分析的过程。经过前面七篇的工作，我们从最初的业务用例获取入手，获得了业务用例模型，这是我们的业务范围；经过分析得到了业务场景，这是我们的业务蓝图；经过规划，得出用例实现视图，这是我们的系统范围；经过再次分析，得到了用例实现以及领域模型，包括用例规约，业务规则和业务数据，这是我们的概念模型。仅从需求所需的必要元素来说，我们基本上已经完成了需求分析的工作。诚如上一篇结尾所说，为了让我们的需求更完美，这一篇所要做的工作也是必不可少的。这一篇将要讨论到的内容包括：用例补充规约，系统原型，以及需求规格说明书
先说说用例补充规约。
之前我们得到的用例规约是功能性的，它们是针对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里留言，以武会友就是专门为大家准备的。笔者保证每条留言都会回复的。谢谢大家。
小小预告一下，用例分析系列结束了，接下来笔者将开始系统分析和设计的系列文章，就是通常所说的OOD过程，这是将需求转化为代码的中间重要阶段，所面对的读者是OO系统设计师。希望继续得到大家的支持与鼓励。敬请期待。