2016用例描述模板.docVIP

实验一 编写用例（以下给出用例描述模板），并画出用例图（编写时可参照下面的实例） 用例描述模板 是一种被广泛使用的用于发现和记录需求(特别是功能需求)的机制。写出用例是一种最好的理解和描述需求的技巧。 注意：这个模板列出可以定义用例的典型标题，但应当强调的是，实用上更重要的是专注于写出完整的可理解的事件路径，而不是按指定的模板填写每个部分。 名称 用例的名称应当用简短的动词短语表达，说明用户使用用例完成的任务。 概述或简要描述 单列一节概述该用例完成什么通常是有益的。 参与者 列出此用例涉及的参与者和负责发起此用例执行的主要参与者。 触发器 触发器是开始此用例的事件。触发者并不必须向该系统输入事件，例如，在预约系统示例中，“预约”用例的触发者可能是“一个潜在的客户打给餐馆的一个预约电话”。而在另一种情况下，触发者可能是此用例中第一个系统事件。 前置条件 前置条件概述在用例可以开始前，什么必须为真。通常前置条件说明在指定的一个用例运行前，另一个什么用例必须运行。典型的前置条件可以是“用户已成功登陆”。 后置条件 后置条件概述当用例完成时什么是真。在许多情况下，这将依赖于在一个特定用例实例中发生的确切的一系列交互。区分“最低保证”和“成功保证”可能是实用的，前者描述在所有情况下发生什么和不发生什么，后者描述如果正常的事件路径成功地完成将会发生什么。 事件路径或脚本 基本的或正常的事件路径，通常应当作为不中止的交互序列出现。对事件路径中的交互通常加以编号，以便于以后的参考。 可选和例外事件路径 可选和例外事件路径可以完整地写出。然而通常只须在基本事件路径中的分叉点简单地指明可选事件流，对行为可能改变的位置予以编号，并指明导致分叉的事件。 扩展点 这一节应当列出在事件路径中可能发生扩展的位置，并给出确定扩展是否发生的条件或事件。扩展本身应当作为单独的用例写出；否则，可以指明可选的事件路径。 例如，订餐系统中“记录未预约顾客”的用例可以作为“记录达到”用例的扩展。（因为在“记录未预约顾客”中指定的交互不是在每次执行“记录达到”时都执行） 包含 这一节简单地概述包含在已定义的用例中的用例。在哪些地方包含发生应当在事件路径中指明。 例如，订餐系统中“显示用例”包含在“记录预约”用例中， 以下给出了网上零件管理系统中，开发一个使用POS机处理销售的一个用例描述 用例文档参考示例 UC1 检索零件 用例描述 Actor根据零件的类别、编号以及几何特征（如形状、大小），检索出所需零件的详细信息和价格。 参与者 潜在会员（首要），会员 前置条件 Actor访问系统 后置条件 Actor查询到所要的零件 基本路径 Actor提交零件的类别、编号、几何特征等查询条件 系统按查询条件检索零件信息和价格信息 系统显示搜索到零件的编号、类别、 Actor选中某个零件 系统显示该零件的详细信息 扩展点 2a 系统没有检索到所需零件 2a1. 系统显示“没有找到合适条件的零件” 补充说明 几何特征包括内径、外径、螺距、形状等，不同类型的零件，表征所用的几何特征不同。 零件的详细信息包括：领教 编号、库存量、类别、几何特征、价格。 UC2：注册 用例描述 潜在会员注册成为会员。 参与者 潜在会员（首要） 前置条件 Actor访问系统 后置条件 系统记录会员信息，等待经理开放账户 基本路径 Actor请求注册。 系统显示注册界面。 Actor提供会员信息。 系统检查信息是否充分。 系统保存会员信息。 系统显示“注册成功，等待开放账户”信息。 扩展点 2a. Actor提供的信息不充分。 2a1. 系统提示输入剩余信息 补充说明 会员信息包括：公司名、联系人、电话、传真、Email，以及若干个联系地址。 一个会员可以有多个联系地址，其中一个为首选联系地址。联系地址包含以下信息：州、城市、街道、邮编。 会员订单的送货地址可以从会员联系地址中获取。 UC3会员登录 用例描述 会员提供身份信息以通过系统验证。 参与者 会员（首要） 前置条件 Actor访问系统 基本路径 Actor提交用户名，密码。 系统验证用户名和密码。 系统显示带有会员信息（姓名、账户余额）的检索零件界面。 扩展点 2a. Actor提供的用户名不存在。 2a1. 系统显示“用户名不存在”信息，询问Actor是否注册。 2a2. Actor注册 2b. Actor提供的密码错误。 2b1. 系统显示“密码错误”信息。 补充说明 UC4 购物 用例描述 会员购买某种零件 参与者 会员 前置条件 会员已经