用例规约：
[以下提供的模板用于用例规约，它包含以文本表示的用例特征。该文档和需求管理工具（如 Rational RequisitePro）一起使用，用于详细说明用例特征中的需求，并对这些需求进行标记]
[用例图可在可视化建模工具（如 Rational Rose）中开发。用例报告（具有所有特征）可用 Rational SoDA 生成。有关详细信息，请参见 Rational Unified Process 中的工具向导。] 1.
1.1 用例名称 简要说明
[此说明应该简要介绍该用例的作用和目的。一个段落即足以作此说明。]
2.
2.1 事件流 基本流
[当主角有所行动时，此用例随即开始。总是由主角来带动用例。用例应说明主角的行为及系统的响应。应按照主角与系统进行对话的形式来逐步引入用例。
用例应说明的是系统内发生的事件，而不是事件发生的方式和原因。如果进行了信息交换，则需指出来回传递的具体信息。例如，只表述主角输入了客户信息就不够明确。最好明确地说主角输入了客户姓名和地址。通常可以利用词汇表让用例的复杂性保持在可控范围内 − 您最好在词汇表中定义客户信息等内容，使用例不至于陷入过多的细节。
简单的备选流可以在用例文本中提供。 如果只需几句话就可说明存在备选流时将发生的事件，则可以直接在事件流一节中说明。 如果备选流较为复杂，则需要用另外一节来单独说明。 例如，备选流小节解释如何说明较复杂的备选流。
虽然清晰明了的叙述性文字是无可替代的，但有时一幅图要比千言短文更具说明性。 只要表达得简洁明了，您就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。 如果流程图有助于描述复杂的决策流程，那么一定要充分利用它！ 同样，对于与状态相关的行为，状态转移图通常比数页文字更能清晰地描述系统的行为。 根据问题来选用妥当的表示方法，但应慎用您的读者可能不太明了的术语、符号或图形。 请切记，您的目的是要阐明问题，而不是混淆问题。]
2.2 备选流
2.2.1
[较复杂的备选流应单独说明，这已在事件流一节的基本流小节中提及。 将备选流小节当作备选行为 − 在许多情况下，由于主事件流中发生异常事件，这时每个备选流都可代表备选行为。 这些备选流的长度可以是说明与备选行为相关的事件所需的长度。 当备选流结束时，除非另外说明，主事件流的事件将重新开始。]
2.2.1.1
[如果能使表达更明确，备选流又可再分为多个支流。]
2.2.2
[在一个用例中很可能会有多个备选流。 为了使表达更清晰，应将各个备选流分开说明。 使用备
选流可以提高用例的可读性，并防止将用例分解为过多的层次。 应切记，用例只是文本说明，其主要目的是以清晰、简洁、易于理解的方式记录系统的行为。]
3. 特殊需求
[特殊需求通常是非功能性需求，它为一个用例所专有，但无法在用例的事件流文本中较容易或较自然地进行说明。特殊需求的示例包括法律或法规方面的需求、应用程序标准和所构建系统的质量属性（包括可用性、可靠性、性能或支持性需求）。此外，其他需求，如操作系统及环境、兼容性需求和设计约束，也应在此节中记录。]
3.1
4. 前置条件
[用例的前置条件是执行用例之前必须存在的系统状态。]
4.1
5. 后置条件
[用例的后置条件是用例一执行完毕系统可能处于的一组状态。]
5.1
6. 扩展点
[此用例的扩展点。]
6.1
[扩展点在事件流中所处位置的定义。]
用例规约：
[以下提供的模板用于用例规约，它包含以文本表示的用例特征。该文档和需求管理工具（如 Rational RequisitePro）一起使用，用于详细说明用例特征中的需求，并对这些需求进行标记]
[用例图可在可视化建模工具（如 Rational Rose）中开发。用例报告（具有所有特征）可用 Rational SoDA 生成。有关详细信息，请参见 Rational Unified Process 中的工具向导。] 1.
1.1 用例名称 简要说明
[此说明应该简要介绍该用例的作用和目的。一个段落即足以作此说明。]
2.
2.1 事件流 基本流
[当主角有所行动时，此用例随即开始。总是由主角来带动用例。用例应说明主角的行为及系统的响应。应按照主角与系统进行对话的形式来逐步引入用例。
用例应说明的是系统内发生的事件，而不是事件发生的方式和原因。如果进行了信息交换，则需指出来回传递的具体信息。例如，只表述主角输入了客户信息就不够明确。最好明确地说主角输入了客户姓名和地址。通常可以利用词汇表让用例的复杂性保持在可控范围内 − 您最好在词汇表中定义客户信息等内容，使用例不至于陷入过多的细节。
简单的备选流可以在用例文本中提供。 如果只需几句话就可说明存在备选流时将发生的事件，则可以直接在事件流一节中说明。 如果备选流较为复杂，则需要用另外一节来单独说明。 例如，备选流小节解释如何说明较复杂的备选流。
虽然清晰明了的叙述性文字是无可替代的，但有时一幅图要比千言短文更具说明性。 只要表达得简洁明了，您就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。 如果流程图有助于描述复杂的决策流程，那么一定要充分利用它！ 同样，对于与状态相关的行为，状态转移图通常比数页文字更能清晰地描述系统的行为。 根据问题来选用妥当的表示方法，但应慎用您的读者可能不太明了的术语、符号或图形。 请切记，您的目的是要阐明问题，而不是混淆问题。]
2.2 备选流
2.2.1
[较复杂的备选流应单独说明，这已在事件流一节的基本流小节中提及。 将备选流小节当作备选行为 − 在许多情况下，由于主事件流中发生异常事件，这时每个备选流都可代表备选行为。 这些备选流的长度可以是说明与备选行为相关的事件所需的长度。 当备选流结束时，除非另外说明，主事件流的事件将重新开始。]
2.2.1.1
[如果能使表达更明确，备选流又可再分为多个支流。]
2.2.2
[在一个用例中很可能会有多个备选流。 为了使表达更清晰，应将各个备选流分开说明。 使用备
选流可以提高用例的可读性，并防止将用例分解为过多的层次。 应切记，用例只是文本说明，其主要目的是以清晰、简洁、易于理解的方式记录系统的行为。]
3. 特殊需求
[特殊需求通常是非功能性需求，它为一个用例所专有，但无法在用例的事件流文本中较容易或较自然地进行说明。特殊需求的示例包括法律或法规方面的需求、应用程序标准和所构建系统的质量属性（包括可用性、可靠性、性能或支持性需求）。此外，其他需求，如操作系统及环境、兼容性需求和设计约束，也应在此节中记录。]
3.1
4. 前置条件
[用例的前置条件是执行用例之前必须存在的系统状态。]
4.1
5. 后置条件
[用例的后置条件是用例一执行完毕系统可能处于的一组状态。]
5.1
6. 扩展点
[此用例的扩展点。]
6.1
[扩展点在事件流中所处位置的定义。]