<项目名称>
用例规范:<用例名称>
版本 <1.0>
[注意:以下模板供与 Rational Unified Process 一起使用。包含在方括号中以蓝色斜体(style=InfoBlue)显示的文本是用于向作者提供指导,在发布文档之前必须删除这些文本。在此样式之后输入的段落将自动设置为正常(style=Body Text)。]
修订历史记录
日期 |
版本 |
描述 |
作者 |
<dd/mmm/yy> |
<x.x> |
<详细信息> |
<名称> |
|
|
|
|
|
|
|
|
|
|
|
|
目录
用例规范:<用例名称>
[以下模板是为用例规范提供的,该规范包含用例的文本属性。本文档与需求管理工具(例如 Rational RequisitePro)结合使用,用于指定和标记用例属性中的需求。
用例图可以在可视建模工具(例如 Rational Rose)中进行开发。可以使用 Rational SoDA 来生成一个用例报告(带有全部属性)。有关更多信息,请参阅 Rational Unified Process 中的工具向导。]
[此描述简要表达了用例的目的。对于此描述,只用一个段落表述就足够了。]
[当参与者执行某操作时,本用例启动。参与者总是会启动用例。用例描述该参与者的操作和系统的响应。它需要以参与者和系统之间对话的形式进行表述。
用例描述了系统内部发生了什么,但没说明如何发生和为什么发生。如果交换了信息,则要详细了解来回传递了些什么。例如,说参与者输入了客户信息就不是很明确的说法。更好的说法是参与者输入了客户的名称和地址。一份术语词汇表通常有助于保持管理用例的复杂性。您可能要在词汇表中定义类似客户信息的内容,来使用例不陷于细节中。
简单的备用会和用例的文本一起表现出来。如果它仅用几句话描述了存在备选时所发生的事情,那么请直接在事件流节中处理。如果备选流较为复杂,请使用单独的节来描述它。例如,备选流子节解释了如何描述更为复杂的备选。
尽管清晰明了的短文无可替代,但一幅图片有时值一千个字。如果它能表达得更明确,则我们就能尽情地在用例中粘贴用户界面的图片、进程流或其他一些数字。如果一张流图表有助于展示一个复杂的决策过程,请无论如何使用它!类似地,对于依赖状态的行为来说,状态过渡图常比一页页文本更能清楚地说明系统的行为。请使用正确的表现介质来阐述您的问题,但是使用您的听众可能不理解的术语、表示法和数字时需谨慎。请记住您的目的是把问题说明白,而不是把它变得更含糊。]
[较复杂的备选会在单独一节中进行描述,它引用自事件流节中的基本流子节。试想备选流子节类似于备选行为 - 每个备选流常因在主流中发生的异常而表现出备选行为。为了能描述与备选行为关联的事件,它们有必要变得尽可能地长。当一个备选流结束时,事件的主流事件继续。]
[如果能提高清楚程度,可以依次将备选流分开到各个子节中。]
[用例中可能(而且很可能将会)存在大量备选流。保持每个备选流独立以使其更明确。使用备选流来提高用例的可读性。备选流也防止用例分解为各个层次的用例。记住,用例只是文本描述,它们的主要目的是以清楚、简明和易懂的方式记录系统的行为。]
[特殊需求通常是特定于某个用例的非功能性需求,但它不容易或不能自然地在用例事件流文本中指定。举例来说,特殊需求包括法律和规章需求、应用程序标准和待构建系统的质量属性(包括可用性、可靠性、性能或可支持性需求)。另外,其他需求(例如操作系统和环境、兼容性需求以及设计约束)也应该在本节中记录。]
[用例的前置条件是必须在执行用例之前出现的系统状态。]
[用例的后置条件是紧接用例完成之后,系统可以处于的一系列可能状态。]
[用例的扩展点。]
[事件流中扩展点位置的定义。]