[翻译]需求的用例文档管理

原文：http://searchsoftwarequality.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid92_gci1315460_tax306118,00.html

 

问题 ：

我需要为一个现存的应用系统建立一些用例。这个系统有大量的相关文档，其中一些已经规格化了，同时也仍有好些没有整理。那如何通过用例来描述这种状态比较好呢？

 

专家回答：

很好的问题。不管是新建的还是现存的，各式文档对于许多的应用系统来说都是十分重要的。

 

首先，来考虑一下文档到底是什么，而用例又用来做什么的。文档是一种信息的集合，这些信息能够被分割、组织以及以各种不同的方式进行传递（打印成册或网络等等）。用例是一项简单但却强大的技术，它揭示了用户需要完成的工作（当然，是在应用系统的帮助下）。这样，一个用例标识了一个用户的任务——如“检视客户信息”——经过整理最终形成文件或者网络文档。

 

虽然我是用例技术的大粉丝，因为它关注用户，但有效的需求定义需要有更多的手段。在一个用户需求如“检视用户信息”（一个用例）中包含有大量的我们并不容易捕获的信息。你必须把这些信息作为某个特定信息集合的元数据来思考。比如说，你可能需要整理出一份文档的定义，提供者和接收者，传阅频度，（传阅）时机，（传阅）条件，以及其他的一开始就需要确定的东西。

 

整理这些附加的文档信息并不等于将用例技术束之高阁，它实际上是在强调单纯地描述用户任务“监视客户信息”是不够的。一个常见的编制文档的方式是创建一份用于整理这些描述的信息的文档定义模板。但这种方法并不包治百病，它不能帮助我们从一堆文档中找出缺失或相互矛盾的信息，或者找出有助于文档统一的模式。首先，我来跟大家分享我使用的两种技术：文档用例模式以及文档定义列表。在概述中，我会使用这两项技术来回答上面的问题。

 

用例文档样本

我常常在寻找样本模式——词组模式、处理步骤模式等等。同时，我也发现一份文档实际上是一组_______的信息集合（根据实际情况进行填空），我也发现当用户要求“监视_______的信息”包含着一些特殊的处理步骤。这个会让你发出“啊~哈”的发现告诉我是时候为这些“监视_______的信息”的用例定义样本模式了。我发现这样本模式很简单，然而之前要我整理所有的信息之间的关系却让我心有余悸。（事后也往往证明，整理出来的这些所有文档间关系并不都是有用的。）记住，下面所说的样本只是一个开端，它将为用户任务的处理步骤的整理带来简易与一致。

 

 

文档定义列表

下面的文档定义列表是经过若干次文档讨论后得出的。你或许会发现在这里样例中，文档的信息在Excel电子表格中被进行了分类，并合拢了一些列。如果你手头上有其他（比Excel）更好的处理工具你也可以拿来使用，不过这种信息分组的原则还是适用的。 

 

花一点时间来粗略看看文档中的各项信息的标识吧。

 

 

现在，我们来展开样例中的各项分组。你应该会发现DEFINITION和PROVIDER-RECEIVER分组中几个信息列都填上了适当的内容。

 

 

注意：在CONTENT栏中有有些信息只是写了引用（自哪份文档），这是因为已经有人做了一份文档（Report Data Definition）对这些数据进行规格化了。他们也不需知道谁将要看这些文档。同样地注意一下DELIVERY的组织方式。

 

 

在FORMAT和CRITERIA栏中，有些列会来回叙述“是什么”及“如何”。当定义一个新的文档时，需求应该遵循某种公认的标准来撰写，但当这些需求是不言自明的时候是不需要规格化的。当你整理一份文档时，你拿到了这些（不言自明的）信息，那问一下自己详细叙述这些信息是否有用。如果确实有用，那就记录下来并对之进行组织整理。此外，还要注意CRITERIA栏的信息，如条件(filter)和分类(sort)，注明引用了用例文档样本中的哪些样本。

 

 

小结

最后，我建议你把目光放得更远些而不要囿于你手头上的工作，因为你要使你正在创建的文档有用。了解这份文档是如何使用，这毫无疑问是让你真正掌握它的各种潜在用处的不二之法。显然，这份文档不是用于开发一个新应用系统的，它是已经存在的。尽管如此，还是有一些潜在的应用价值可以利用这些用例及其相关的文档的，它们是：

• 撰写用户指南
• 培训新员工
• 回归测试依据
• 应用系统替换的需求

上述各项，整理“是什么”是必须要做的，而整理“如何”则可据情况而定（参考上面样例中的FORMAT栏）。如果你正在整理的需求（同时又是你在整理用例时需要整理的）是用于应用系统替换的，那么一些关于“如何”替换的并非必要的限制的论述是可以加上去的。

 

以上原则了然于心后，来考虑一下下面的这个文档整理方法：

• 粗略浏览一下文档定义列表，删除并不适用的描述，同时完善那些在你看来并不太准确的描述。
• 在文档定义列表中填上你手头的每一份文档，并用这个列表来作为指南来提问题。对于那些没有规格化的文档，在假设这些文档存在的基础上思考并给出可以找到关于这份文档的更多信息的引用索引。
• 为用例“检视_______信息”的用例命名。在你为每一份用例文档命名前，看看是否在文档定义列表中已有相关的文档信息。
• 如果能找到，填上“检视_______信息”用例文档，同时要记得要在文档定义列表中为此用例加上引用。
• 如果找不到，就在用例样本和文档定义列表中填上所有的关于用户任何及文档元数据的相关必要信息。

不管找到与否，信息都应当避免重复冗余，达到一处描述多处引用。