产品用例文档[编辑]

简介

产品用例文档模板是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。用例是贯穿整个系统开发的一条主线。同一个用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用。

建模

系统建模有许多种方法，每种建模方法可以满足不同的目的。然而，用例模型最重要的作用是将系统行为传达给客户或最终用户。因此，模型必须易于理解

用途说明

可能与该系统交互的用户和任何其他系统都是主角。由于主角代表了系统用户，它们协助界定系统并提供十分明确的系统用途说明。编写用例依据主角的需求来进行。这样就确保该系统成为用户期望得到的系统。

用例模型如何演进

主角和用例都是通过将客户需求及潜在用户当作重要的信息查找到的。找到这些用例和主角后，应对它们作简要说明。在详细说明这些用例之前，客户应复审该用例模型以核实所有的用例和主角都已经找到，并且它们可以提供客户所需要的东西。在迭代开发环境中，您可以选择用例的子集以便在每个迭代中详细描述。另请参见活动：确定用例的优先级。主角和用例找到后，需要详细说明每个用例的事件流。这些说明指出系统与主角交互的方式以及在各个独立用例中系统执行的有关操作。最后，对已完成的用例模型（包括用例说明）进行复审，开发人员和客户使用该模型对系统应执行的操作达成一致意见。

避免功能分解

用例模型退化导致系统功能分解的情况并不罕见。为避免发生这种情况，必须注意以下故障现象：“小”用例，即对事件流的说明只有一个或少数几个句子。 “许多”用例，即用例的数量有好几百，而不是好几十。用例名的构造类似于“根据这一特定数据执行本操作”或“利用这一数据执行本功能”等。例如，“在 ATM 机上输入个人识别号”不应建模为 ATM 机的一个单独用例，原因是没有人会使用系统仅执行这一操作。用例是一个完整事件流，它可以产生对主角有价值的东西。为避免功能分解，您需要确保该用例模型有助于回答诸如以下的问题：系统的环境是什么？为什么要建立系统？用户在使用系统时希望获得什么？系统将给用户创造什么价值？

非功能性需求

不难发现，用例是一个很好的获取系统功能性需求的方法。但是对于非功能性需求，情况又如何呢？什么是非功能性需求，可以在何处获得它们？非功能性需求通常分为可用性需求、可靠性需求、性能需求以及可替换性需求（另请参阅概念：需求）。它们通常是指定需要符合任意法律法规要求的需求。它们也可以是由于所使用的操作系统、环境平台、兼容性或所采用的任何应用标准等问题产生的设计约束。通常，任何不允许有一个以上设计选项的需求都可以认为是一个设计约束。许多非功能性需求适用于一个单独的用例，并且可以在该用例的特征内获得这些需求。在这种情况下，这些需求可以在用例的事件流内获取，或者作为用例的一个特殊需求来获取。

参考资料：

好搜百科

扩展阅读：