用例分析系列（8）--完整的UML需求规格说明书

作者: coffeewoo 先生

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





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

先说说用例补充规约。

之前我们得到的用例规约是功能性的，它们是针对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系统设计师。希望继续得到大家的支持与鼓励。敬请期待。