用例规约(实例)

合集下载

公司管理系统的用例规约

公司管理系统的用例规约

公司管理系统的用例规约用例名称:公司管理系统参与者:管理员、员工前置条件:管理员已登录系统用例描述:管理员通过公司管理系统对员工进行管理和操作。

基本流程:1. 管理员登录公司管理系统。

2. 系统验证管理员身份并登录成功。

3. 管理员选择需要进行的操作:包括新增员工、删除员工、修改员工资料等。

4. 管理员输入相应的员工信息(新增员工需要填写所有必要信息,删除和修改员工需要提供员工的唯一标识)。

5. 系统验证输入信息的合法性,如输入员工ID是否已经存在等。

6. 管理员确认提交操作。

7. 系统保存相关信息,并进行相应的操作(如新增员工、删除员工、修改员工资料等)。

8. 管理员成功完成操作,系统提示操作成功。

备选流程:- 如果管理员登录失败(用户名或密码错误),系统提示登录失败并重新要求管理员输入用户名和密码。

- 如果管理员输入的员工信息有误(如员工ID已经存在),系统提示相关错误信息,要求管理员重新输入。

- 如果管理员取消了操作,系统不进行任何保存和操作,提示取消操作。

后置条件:管理员退出系统。

异常流程:- 管理员登录失败:系统提示登录失败并重新要求管理员输入用户名和密码。

- 管理员输入的员工信息有误:系统提示相关错误信息,要求管理员重新输入。

- 管理员取消了操作:系统不进行任何保存和操作,提示取消操作。

特殊需求:- 系统需要保证管理员的登录信息和操作信息的安全性和权限控制。

- 系统需要支持对员工信息的搜索、排序和过滤等功能。

- 系统需要提供数据备份和恢复功能,以保证数据的安全性和可靠性。

图书管理系统用例规约

图书管理系统用例规约

图书管理系统用例规约用例ID: 1角色:借书者,图书管理员用例说明:读者刷卡,系统检索并判断该读者图书数量及借阅期限权限能否再借阅,如可借阅,图书管理员通过读码器读取图书上的条形码进行登记。

前置条件:借书者提出要借的书名,图书管理员查找到该书还有库存基本事件流: 参与者动作系统响应1. 图书管理员选择“借阅登记”,提交“借阅登记”请求;3.借书者输入借阅登记信息2. 系统显示“借阅登记”空白窗口;4.系统列表显示出该读者在借图书信息和该读者借阅期限的权限;若借书者输入借阅登记信息非法,进入4.1.1,若借书者所需书籍不存在,进入 4.2.1若书籍数量不足,进入4.2.2其他事件流: 无异常事件流: 参与者动作系统响应4.1.1登记信息不合法4.1.2未填写登记信息4.2.1图书馆未收录该书籍4.2.2书籍数量不足4.1.1提示用户重新输入4.1.2提示用户输入登记信息4.2.1提示用户预订购买图书4.2.2提示用户预订借阅图书后置条件:用户借书成功用例ID: 2角色:借书者,图书管理员用例说明:读者刷卡,系统检索并显示出该读者在借图书信息和该读者已借阅的时间;前置条件:还书者之前在该图书馆借阅过书籍基本事件流: 参与者动作系统响应1. 图书管理员选择“还书登记”,提交“还书登记”请求;3.还书者输入借阅登记信息2. 系统显示“还书登记”空白窗口;4.系统列表显示出该读者在借图书信息和该读者已借阅的时间。

若超过借阅时限,进入4.1.1其他事件流: 无异常事件流: 参与者动作系统响应4.1.1超过借阅时限 4.1.1提示用户缴纳违约金后再进行还书后置条件:用户还书成功用例ID: 3角色:借书者,图书管理员用例说明:读者刷卡,系统检索并显示出该读者在借图书信息和该读者已借阅的时间;前置条件:图书馆缺少该图书基本事件流: 参与者动作系统响应1. 图书管理员选择“预订登记”,提交“预订登记”请求;3.还书者输入预订登记信息2. 系统显示“预订登记”空白窗口;4.系统列表显示出该读者想要预定的图书信息其他事件流: 无异常事件流: 参与者动作系统响应后置条件:用户预订成功用例ID: 4角色:借书者,图书管理员用例说明:读者刷卡,系统检索并显示出该读者预订图书信息前置条件:用户进行过图书预订基本事件流: 参与者动作系统响应1. 图书管理员选择“取消预订登记”,提交“取消预订登记”请求;3.借书者输入预订登记信息5.借书者选择取消预订2. 系统显示“取消预订登记”窗口;4.系统列表显示出该读者预订图书信息6若用户之前进行过预订,则取消成功。

用例技术-用例规约

用例技术-用例规约

用例技术-用例规约
1.用例名称:销户
2.简要说明:
帮助银行工作人员完成银行客户申请的活期账户销户工作
3.事件流
3.1基本事件流
1)银行工作人员进行“活期帐户销户”程序界面;
2)银行工作人员用磁条读取设备刷取活期存折磁条信息;
3)系统自动显示此活期帐户的客户资料信息和帐户信息;
4)银行工作人员核对销户申请人的证件,并确认销户;
5)系统提示客户输入取款密码;
6)客户使用密码输入器,输入取款密码;
7)系统校验密码无误后,计算利息,扣除利息税(调用计息用例),计算最终销户金额,
并打印销户和结息清单;
8)系统记录销户流水及其分账信息。

3.2扩展事件流
1)如果存折磁条信息无法读出,需要手工输入帐号;
2)如果销户申请人的证件与客户资料信息不符或其它因素,而不受理的,银行工作人
员直接退出。

3)如果系统密码校验错误,提示重新输入密码;密码校验失败超过3次,系统提示并
自动退出;
4.非功能需求:
申请受理处理的过程操作时间应在30少内;
打印的销户和结息清单应该清晰明了
5.前置条件:帐户为正常状态(即不是挂失、冻结或销户状态)。

6.后置条件
销户成功并将销户信息存入数据库,证件不符而退出,密码不符而退出。

7.扩展点无
8.优先级高。

用例规约范例

用例规约范例

广州大学华软软件学院
华软管理系统
学籍管理子系统用例规约:学位资格查看
版本1.0
修订历史记录
目录
1.奖励查看4
1.1简要说明4
2.事件流4
2.1基本流4
2.2备选流4
3.特殊需求4
3.1界面信息显示需求4
4.前置条件4
5.后置条件4
6.扩展点4
用例规约:学位资格查看
1. 学位资格查看
1.1 简要说明
系统提供查看学位资格的功能;
角色:各系教务员
2. 事件流
2.1 基本流
1、用户选择“学位资格查看”功能启动该用例;
2、系统打开‘学位资格查看主界面’,该界面分为查询条件区和结果显示区;
3、用户在查询条件区输入学号、年级、专业、学位资格(有/无)、和认定时间,然后选择‘查询’;
4、系统刷新‘学位资格查看主界面’,在结果显示区显示符合查询条件的记录,显示年级、专业、
学号、姓名、学位资格、认定时间;
5、用户选择‘退出’,该用例结束。

2.2 备选流
3. 特殊需求
3.1 界面信息显示需求
4. 前置条件
1.系统中已已设置了学生信息;
2.系统中已设置了用户信息;
5. 后置条件
6. 扩展点。

用例规约(小组)

用例规约(小组)

1.用例UC1:挂号2.主要参与者:挂号负责人3.受益人及其利益:1)挂号负责人:正确输入病人信息、选择科类信息、选择医生信息。

2)病人:可以快速的拿到挂号凭证单4.前置条件:挂号负责人正确登陆系统5.后置条件:登记病人信息,选择科类,选择医生,确认信息,打印挂号凭证。

6.主要成功场景:1)挂号负责人成功登陆系统2)病人到挂号处挂号3)挂号负责人输入病人信息4)挂号负责人成功选择科类和医生5)打印机打印出挂号单6)病人成功取得挂号凭证单住院管理用例前置条件:开始这个用例前,系统已正常启动,并工作者顺利进入系统。

参与者:病人,财务工作人员,病房工作人员。

主事件流如下:①如果病人提出入院登记申请执行子事件a②如果病人提出住院预缴执行子事件b③如果病人提出出院结算执行子事件c④如果病人提出药品查询执行子事件d子事件a:①病人接到住院通知;②病人提供相关身份证明和病历;③由病人提供的信息工作人员登记住院患者的基本信息;④向病人开出住院单。

子事件b:①病人提供住院单;②工作人员核实单据;③单据核实后向病人开出住院缴费单据;④病人预缴住院费用;⑤工作人员收取,向系统提交修改信息。

子事件c:①医生开出出院证明;②病人提供出院证明和相关资料;③向病人开出出院结算单据;④病人全额缴纳住院费用。

子事件d:①查询病人入院详细信息;②查询病人住院预缴信息;③查询病人出院结算信息。

后置条件:如果用例成功结束,推出用例.药房管理用例:病人通过药房付费取药,接触只有一个用例;药库是对药房里药品的供给补充,由医院工作人员负责管理,医院工作人员可同时接触药房管理、药库管理2个用例。

仓库管理系统用例①如果管理员登录执行事件a②如果管理员需要药品入库执行事件b③如果管理员需要药品出库执行事件c④如果管理员需要填写药品汇总表执行事件d事件a登陆用例:完成仓库采购员登陆功能。

事件b1.按照入库单仓库管理员进行药品管理2.仓库管理员对入库的药品进行核对事件c:1.管理员根据领料单核对信息.2.按照领料单发放药物事件d:1.查看药品是否充足2.如果供不应求,则填写采购单。

用例规约示例

用例规约示例
6)输入金额-客户输入要从ATM机中提取的金额。对于 此事件流,客户需选择预设的金额(10美元、20美元、50美元或100美元)。
7)授权-ATM机 通过将卡ID、PIN、金额以及帐户信息作 为一笔交易发送给银行系统来启动验证过程。对于此事件 流,银行系统处于联机状态,而且对授权请求给予答复, 批准完成提款过程,并且据此更新帐户余额。
如果PIN输入有误,ATM将显示适当的消息;如果还 存在输入机会,则此事件流在步骤3 -输入PIN处重新加入 基本流。
如果最后一次尝试输入的PIN码仍然错误,则该卡将被
ATM机保留,同时ATM返回到准备就绪状态,本用例终止。
备选流5 -帐户不存在
在基本流步骤4中-验证帐户和PIN,如果银行系统返回 的代码表明找不到该帐户或禁止从该帐户中提款,则ATM显示适当的消息并且在步骤9-返回银行卡处重新加入基本 流。
8)出钞-ATM机清点并向客户提供现金。
9)返回银行卡-ATM机将客户的银行卡返还。
10)收据-ATM机打印收据并提供给客户。ATM机 还相应地 更新内部记录。
[用例结束]
备选流1 -银行卡无效
在基本流步骤2中-验证银行卡,如果卡是无效的,则卡被 退回,同时会通知相关消息。
备选流2 -
ATM内没
有现金
系统用例规约:
用例名称:
ATM取款
描述:
客户持银行卡(本行或其他行)从ATM提取现金
actors:
客户和银行主机
前置条件:Байду номын сангаас
ATM处于准备就绪状态。
后置条件:
用例结束时ATM又回到准备就绪状态。
基本流:
1)准备提款-客户将银行卡插入ATM机的读卡机。
2)验证银行卡-ATM机从银行卡的磁条中读取帐户代码, 并检查它是否属于可以接收的银行卡。

用例规约表

用例规约表
用例规约表
用例规约表是一个用来描述软件系统用例的表格,它包含了一系列关于用例的详细信息。下面是一个用例规约表的示例:
用例编号
用例名称
参与者
前提条件
正常流程异常流程后置件UC1用户登录
用户
用户已注册账户,且未登录
用户输入用户名和密码,系统验证通过后登录成功
用户输入的用户名或密码错误,系统提示错误信息,并返回登录页面
用户登录成功后,系统记录用户已登录状态
UC2
浏览商品列表
用户
用户已登录
用户进入商品列表页面,查看商品列表信息
无异常流程
无后置条件
UC3
购买商品
用户
用户已登录,且选择要购买的商品加入购物车
用户提交购买请求,系统处理购买请求并完成交易
无异常流程
购买成功后,系统更新购物车状态和库存状态
UC4
支付订单
用户
用户已登录,且订单已生成
用户选择支付方式并提交支付请求,系统处理支付请求并完成支付
无异常流程
支付成功后,系统更新订单状态和支付状态
在上述示例中,用例规约表包含以下列:
用例编号:用例的唯一标识符。
用例名称:用例的简短描述。
参与者:与该用例相关的参与者或角色。
前提条件:执行用例之前必须满足的条件。
正常流程:用例的详细执行步骤。
异常流程:可能的异常情况及处理步骤。
后置条件:用例执行完毕后的状态或结果。

业务用例规约示例

业务用例规约示例
4.成功建立监察档案
5.成功建立计量档案
主过程描述
1.用电用户到营业大厅填写用电申请表,提交营业柜台
2.营业员初步核实申请信息,查询该用户是否有欠费记录,符合条件则启动用例
3.营业员录入申请信息,产生用电申请单
4.业务班长审查申请单,产生现场勘察工作单,分配勘察员执行任务
5.勘察员现场勘察,填写现场勘察工作单,给出是否符合用电条件结论.符合条件执行6,不符合条件执行异常过程5.1.1
异常过程描述
5.1.1不符合条件,营业员归档申请记录,停止申请过程,用例结束
6.2.1配电和用电两方至少一方不同意,营业员归档申请记录,停止申请过程,用例结束
业务规则
a.申请户名应无历史欠费记录
这一栏中可以用过程步骤的编号来引用相关的业务规则。若该规则仅作用于本用例,可以加上面例子直接书写。若该规则作用于多个业务用例,建议编写专门的业务规则文档,为每个业务规则编号。在这里引用编号即可。如
如abizrule001涉及的业务实体中英文对照bexxx申请单bexxx现场勘察单bexxx业务收费清单bexxx电表安装工作单bexxx用户档案bexxx收费帐号bexxx抄表台帐bexxx监察档案bexxx计量档案这一栏中可以列出与该业务用例相关的业务实体
业务用例规约示例
用例名称
Bu_申请永久用电
Rule001
涉及的业务实体(中英文对照)
Be_XXX(申请单)
Be_XXX(现场勘察单)
Be_XXX(业务收费清单)
Be_XXX(电表安装工作单)
Be_XXX(用户档案)
Be_XXX(收费帐号)
Be_XXX(抄表台帐)
Be_XXX(监察档案)
Be_XXX(计量档案)

用例规约

用例规约

网上书店系统用例规约姓名:廖杰学号:1208060324版本<1.0>订单管理管理员登录用户查看订单用例图删除书籍1.用户注册1.1简要说明本用例用于向顾客提供注册功能,每位顾客必须注册后才能够登录系统进行购物。

注册信息包括使用本系统的名称、账号、密码和电子邮件等。

注册完成后,系统保存这些信息到数据库,以方便管理员管理及联系用户。

1.2事件流1.2.1 基本流当用户进行注册时,开始执行以下基本流:(1)系统要求用户填写个人信息,包括使用本系统的账号、密码和电子邮件等。

(2)用户填写个人信息。

(3)系统验证用户信息。

1.2.2备选流1.2.2.1用户信息验证错误如果系统检测到用户输入的信息格式或内容有错,例如账号密码不匹配,会给以错误提示。

1.3前置条件用户必须首先访问网上购物的主页,然后点击注册。

1.4后置条件如果该用例成功,系统数据库中将增加一条该用户的信息,否则,系统维持现状。

1.5扩展点无。

2.个人信息管理2.1简要说明本用例用于给顾客维护个人信息。

包括修改本人的账号、密码和联系地址等信息。

2.2事件流2.2.1基本流当顾客查看并修改个人信息时,开始执行以下基本流:(1)系统返回给当前顾客在系统数据库中目前存储的个人信息。

(2)顾客可以对本人信息的一项或几项进行修改。

(3)顾客向系统提交修改后的个人信息。

2.2.2备选流2.2.2.1顾客输入的新信息验证错误如果系统检测到顾客输入的信息格式或内容有错(如输入新密码和确认输入新密码不一致等),会向顾客给予错误提示,并要求用户重新输入或取消修改的操作。

2.3前置条件顾客必须首先登录系统,然后才能进入本用例。

2.4后置条件如果本用例成功,顾客在系统数据库中的个人信息会被修改。

否则,系统维持原状。

2.5扩展点3.浏览图书信息3.1简要说明本用例用于维护3.2事件流3.2.1基本流当顾客进入网上书店系统之后,开始执行以下事件流:(1)在站内可以点击浏览本网上书店内的书籍。

用例规约表格模板(基于RUP)

用例规约表格模板(基于RUP)

班级:测绘工程学号:1201721193 姓名:杨宇功能需求:1.该系统必须允许注册用户(包括客户和商家)审查他们过去三年的用户历史订单记录或销售记录2.该系统允许用户通过关键字搜索店铺或菜品3.该系统必须允许用户通过销量、评分、距离等条件进行店铺优先级排序4.该系统必须允许登录客户在店铺未打烊且送餐距离合理的情况下下单5.该系统必须允许登录客户给下过的订单评价6.该系统必须允许登录客户下单时使用多种付款平台7.该系统必须保留客户订单记录3年8.该系统必须允许客户和商家两种角色登录该系统9.该系统必须允许商家接单10. 该系统必须允许商家处理订单非功能需求:1. 该系统应满足在ios及android系统运行2. 该系统在10:00-12:30以及5:30-7:00时间段内支800万用户并发使用,其他时间支持200万用户并发使用3. 该系统可以检测用户点评内容是否,若内容违规则可以进行删除。

4. 系统安全:用户在身份认证、授权控制、私密性等方面的要求。

5. 系统易用:系统操作界面美观、简便,通俗,便于操作。

6. 系统可维护:系统在出现故障时可以及时维修,使其数据恢复。

客户用例图:商家用例图系统管理员用例图(1)用例图(1)用例规约:用例编号UC-1 用例名称登录用例描述用户登录该系统主参与者用户前置条件无后置条件登录到系统级别基本事件流程:1.系统提示用户输入用户名和密码2.用户输入用户名和密码3.系统验证用户名和密码,若正确,则登入到系统中。

如果用户输入无效的的用户名和密码,系统显示错误信息,并返回重新提示用户输入用户名和密码或者取消登录候选事件流程:1.点击注册按钮,注册一个新账号特殊需求无扩展点无备注无(2)用例图(2)用例规约:用例编号UC-2 用例名称提交订单用例描述客户提交订单主参与者客户前置条件用户已经成功登入该系统后置条件无级别基本事件流程:1.成功登录系统2.通过查找将需要的菜品添加到购物车3.点击提交订单按钮候选事件流程:1.退出该系统特殊需求无扩展点无备注无(3)用例图2)用例规约:用例编号UC-3 用例名称接收订单用例描述商家接单主参与者商家前置条件商家成功登入商家版系统后置条件无级别基本事件流程:1.成功登录系统2.进入订单处理模块3.点击接单按钮候选事件流程:1.退出该系统特殊需求无扩展点无备注无(4)用例图4)用例规约:用例编号UC-4 用例名称增加菜品用例描述商家通过该系统增加店铺的菜品(包括菜品的名称数量上传图片等)主参与者商家前置条件商家成功登录商家版系统后置条件无级别基本事件流程:1.成功登录商家版系统2.进入管理模块3.点击菜品进入菜品管理模块4.添加菜品名称、相关促销信息以及上传菜品图片5.点击保存按钮候选事件流程:1.返回到主界面2.退出系统特殊需求无扩展点无备注无(5)用例图5)用例规约:用例编号UC-5 用例名称增加活动模块用例描述系统管理员根据需要增加美团外卖活动模块如“今日特价2折”模块主参与者系统管理员前置条件管理员成功登录该系统后置条件完成模块管理级别基本事件流程:1.管理员成功登录系统2.进入活动管理模块3.点击增加活动按钮4.输入相关活动信息(包括活动规则)5.确认、提交候选事件流程:1.退出该系统特殊需求无扩展点无备注无用户下单付款数据流图。

uml用例规约

uml用例规约

用户登录用例图用例规约:用例名称:登录用例ID:IBM_ESHOP_002.1 角色:普通用户用例说明:用例主要功能是实现登录,起始于普通用户的登录前置条件:启动程序,进入登录界面基本事件流:参与者动作系统响应 1. 用户输入基本信息(登录名和密码),点击确定按钮2.系统查找数据库,看该用户是否在数据库中。

若存在则进入主页面,若不存在,则进入2.1.1;若未输入,则进入2.2.2其它事件流:无异常事件流:参与者动作系统响应2.1.1未输入用2.2.1用户名不2.1.2未输入2.2.2密码不正确2.1.1 提示用户名或密码不能为空2.2.2提示用户名或密码不正确。

后置条件:登录成功添加联系人用例图用例规约:用例名称:添加联系人用例ID:IBM_ESHOP_002.2 角色:普通用户用例说明:该用例主要功能是添加联系人,用例起始于普通用户点击“添加”按钮前置条件:进入主界面基本事件流:参与者动作系统响应1.进入主界面,用户点击“添加”按3.用户添加联系人的相关信息,点击“确定”按钮2.系统响应点击事件,进入添加界面4.判断用户的输入是否合法,若合法,则返回主界面,若不合法:若输入信息为空,则其它事件流:无异常事件流:参与者动作系统响应4.1.1.1若未添加姓名4.1.2.1.1若未添加Emai4.2.1.1 若Email格式不正确4.2.2.1 若输入固定电话格式不4.2.3.1若输入手机格式不正确4.1.1.2 系统提示“必须输入姓名”4.1.2.2系统提示“必填”4.2.1.2 系统显示“邮件格式不正确”4.2.2.2 系统提示“8位电话号码”4.2.3.2 系统提示“只能输入数字”后置条件:添加联系人成功,返回主界面修改联系人用例图用例规约:3.用户对联系人姓名、性别、出生日期、Email、职务、固定电话、手机、住址、备注信息进行修改,点击“确定”按钮5.系统对用户的输入进行判断,若合法,则弹出对话框,提示“修改联系人成功”其它事件流:无异常事件流:5.1姓名未输入,系统给出提示对话框“必须输入姓5.2 Email未输入,系统给出提示对话框“必填”后置条件:修改信息成功,返回主界面删除联系人用例图用例规约:查找联系人用例图用例规约:用例名称:查找联系人用例ID:IBM_ESHOP_002.4 角色:普通用户用例说明:该用例主要功能是从列表中查看联系人信息,用例起始用户点击“查找”按钮前置条件:进入主界面基本事件流:参与者动作系统响应1.用户点击“查找”3.用户可以根据选择分组名称,填写邮箱、职位、姓名、手机。

软件工程-用例规约【范本模板】

软件工程-用例规约【范本模板】

1、登陆系统
系统中的所有参与者均可以使用本用例登陆系统,要求输入合法的用户名和密码。

登录系统用例规约
查询菜品信息的参与者是数据管理人员、顾客,用于查看酒店所有菜品的详细信息.
查询菜品用例规约
修改菜品信息的参与者是数据管理人员,用于修改酒店所有菜品的详细信息.
修改菜品用例规约
修改菜品信息的参与者是数据管理人员,用于增加酒店菜品的详细信息。

增加菜品用例规约
删除菜品信息的参与者是数据管理人员,用于删除酒店菜品的详细信息。

删除菜品用例规约
查询员工信息的参与者是数据管理人员,用于查看酒店所有员工的详细信息。

查询员工用例规约
修改员工信息的参与者是数据管理人员,用于修改酒店所有员工的详细信息。

修改员工用例规约
增加员工信息的参与者是数据管理人员,用于增加酒店所有员工的详细信息。

增加员工用例规约
删除员工信息的参与者是数据管理人员,用于删除酒店员工的详细信息。

删除员工用例规约
10、查询vip客户信息
查询vip客户信息的参与者是数据管理人员,用于查看酒店所有vip客户的详细信息。

查询vip客户信息用例规约
修改vip客户信息的参与者是数据管理人员,用于修改酒店所有vip客户的详细信息。

修改vip客户信息用例规约
增加vip客户信息的参与者是数据管理人员,用于增加酒店vip客户。

修改vip客户信息用例规约
删除vip客户信息的参与者是数据管理人员,用于删除酒店vip客户的详细信息。

删除vip客户信息用例规约。

UML旅店管理系统用例图、用例规约

UML旅店管理系统用例图、用例规约

UML旅店管理系统⽤例图、⽤例规约
⼀.旅店管理系统⽤例图
⼆.⽤例规约
1.预定房间
1 .1简要说明
本⽤例允许客户预订旅店的未被预订的房间,系统提供未被预订的房间的信息列表。

1.2 先置条件
客户进⼊旅店管理系统,并选择预订房间功能。

1.3 事件流
(1)基本事件流
A 客户选择要预订的房间的类型,双⼈间或单⼈间。

B 根据客户选择的房间类型,从所有该类型房间中,筛选未被预定的房间,将这些房间的信息列表显⽰,供客户查询。

C 客户选定房间,并输⼊要预订的天数。

(2)备选事件流
A 客户所需要类型的房间已全部被预订,则提⽰客户,该类型房间已全部被预订,询问客户是否选择另⼀类型的房间。

B ⽤户选择预订的房间的时间段与已经预订了该房间的其他客户的时间
段发⽣冲突,则系统提⽰,该房间在哪些⽇期⾥已被预订,并询问当前客户是更换房间还是修改预订天数。

1.4 后置条件
A 客户选择房间和预订天数并确认后,系统要求客户输⼊客户信息,包括客户的姓名、地址、联系电话、有效证件号。

另外,系统将计算出客户需要缴纳
的定⾦和总费⽤,并显⽰出来。

B 客户重新选择房间类型,或修改天数,则刷新⽤户界⾯。

用例规约——精选推荐

用例规约——精选推荐

1.注册功能用例的用例实现一、简要说明游客可注册为网上订餐系统的用户。

注册时只要填写登录用户名、密码、联系电子信箱、联系电话以及安全问题和答案六项信息即可。

注册后,用户可以继续填写个人详细信息及收获人信息,同时可以修改密码、查询及维护订单。

二、事件流基本流:1. 游客选择注册。

2. 系统返回一个注册页面。

3. 游客根据提示输入相应的注册信息。

4. 系统验证游客输入成功。

5. 游客提交注册信息。

6. 系统提示注册成功并返回首页。

(默认已登录)备选流:1. 游客输入信息和系统验证不一致(如字段长度超过系统设置等),系统给出相应的提示信息并返回注册页面。

2. 游客输入用户名是已注册用户名,系统给出提示并返回注册页面。

3. 系统异常,无法注册,并给出相应的信息(如网站维护等)。

三、前置条件游客申请注册。

四、后置条件游客注册成功成为会员五、扩展点无。

2.登录\注销用例的用例实现一、简要说明用户:已经注册成功的用户可以通过登录页面登录进入该网站。

登录之后可以实现订餐系统的设定功能。

管理员:管理员必须通过后台进行登录,登陆以后,可以在前台或者后台之间切换,更方便地对系统进行管理及维护。

不提供管理员注册功能,管理员只能在数据库中添加,以保证系统的安全性。

登录后,可在前台或者后台选择注销,以便安全退出系统。

二、事件流基本流:1. 该会员选择登录。

2. 系统返回一个登录页面。

3. 会员输入用户名、密码和验证码并提交。

4. 系统进行系统验证,验证成功,记录该用户为登录用户并返回主页面。

(表明该会员已登录。

)5. 会员选择“注销”。

6. 系统提示用户成功注销并返回网站首页。

7.管理员修改管理员个人资料和账号信息。

备选流:1.用户忘记密码,选择“找回密码”功能,进入找回密码用例。

2. 系统验证用户登录信息有错,提示用户重新登录。

3. 系统处理异常,系统给出相应的提示信息.。

4.管理员只能在后台运行。

三、特殊要求无。

四、前置条件该会员必须是本网站已注册的成员。

用例规约例子

用例规约例子

用例规约例子
以下是 6 条用例规约例子:
1. 咱就说,你去超市买东西,这不就是一个很常见的用例规约嘛!你知道自己要买啥,什么品牌、多少数量,这不就跟软件里的各种条件、步骤一样一样的嘛?比如说,你决定要买巧克力,然后选了某个牌子,接着看价格和重量,哎呀,这就跟程序里的各种设定和判断太像啦!
2. 你想想看,你每天早上起床后要做的一系列事情,也是个用例规约呀!刷牙、洗脸、换衣服,每一步都有先后顺序和特定的操作呢!就像软件运行时,一个步骤紧接着一个步骤,可不能乱了呀!比如你总不能先换衣服再刷牙吧,这多别扭呀!
3. 嘿,你知道煮饺子也是个好例子呢!先准备水,水开了下饺子,然后等饺子煮熟,捞出来,每一步都不能马虎呀!这在软件里不就相当于一个个明确的流程和规定嘛,水就像是输入,饺子煮熟就是输出,这过程多清晰啊!难道不是吗?
4. 你和朋友约着出去玩,这整个过程也是个用例规约呀!先商量去哪里,再确定时间,然后怎么碰面,一点都不能乱来呢!这不就跟程序里的流程规划一样嘛,一环扣一环的。

你再想想,如果商量不好,那可就玩不成啦,就像程序出错就运行不下去一样呀!真的好形象呀!
5. 哎呀,就连你写作业都是个典型的例子呀!先拿出本子和笔,再看题目,思考怎么做,然后开始写,最后检查。

这和软件中的用例规约简直如出一辙嘛!你可别小瞧这写作业的过程呢,像不像程序在一步步执行任务?
6. 你看那些运动员比赛,也是有他们的用例规约呀!比如跑步比赛,先站在起跑线,听口令,起跑,冲刺,每一步都很关键呀!这多像软件运行时的各种规定呀,每一个动作都得精确无误呀!不然怎么能赢得比赛呢,你说对吧?
我的观点结论就是:生活中到处都是用例规约的例子呀,真的太有意思啦!。

作者用例规约

作者用例规约
作家登录
用例规约
用例名称:
登录
用例ID:
AUTHOR_0002.2
角色:
作者用户
用例说明
用例主要功能是实现登录,起始于作者登录
前置条件:
打开页面,进入登录界面
正常事件流:
参与者动作
系统响应
1、作者输入基本登录信息(登录名和密码)点解确认按钮
2、系统查找数据库,看该作者是否在数据库中。若存在则进入主页页面;若不存在,则进入2.1.1;若密码错误则进入2.2.1
6、系统对用户的输入信息进行验证,若验证成功,则提交修改后的信息到数据库并提示“修改成功”。
备选事件流:

后置条件
修改信息成功,返回个人信息浏览页面
作家查找书籍
用例图
用例规约
用例名称:
查找书籍
用例ID:
AUTHOR_0002.4
角色:
作者
用例说明
该用例主要是查找书籍,起始于作者点击“查找书籍”按钮
前置条件:
用例ID
AUTHOR_RENEW_0002
角色
作者
用例描述
用例主要功能是实现书籍章节的删除,始于书籍管理
前置条件
进入主界面
正常事件流
参与者动作
系统响应
1、进入书籍管理界面,点击“删除书籍章节”按钮。
3、作者选定需要删除的章节。
4、确定删除章节,作者点击“确定”按钮
2、系统响应点击事件,进入删除书籍章节界面。
3、作者选定添加书籍介绍的书。
4、需要保存书籍介绍,作者点击“响应点击事件,保存书籍介绍
备选事件流

后置条件
添加数据介绍章节成功,返回书籍管理浏览页面
5、系统响应点击事件,删除选定的章节

用例规约(实例)

用例规约(实例)

课程注册系统用例规约版本<1.0>查看成绩报告卡用例1.简要说明本用例允许学生查看他(她)刚结束学期的成绩报告卡。

本用例的Actor 是学生。

2.事件流当学生从主表格中选择“查看成绩报告卡”活动时,用例开始。

1.基本流—查看成绩报告卡1.系统检索出学生上个学期所修完的每门课程的成绩信息。

2.系统准备、排版并显示成绩信息。

3.当学生完成查看成绩信息后,选择“关闭”。

2.备选流1.没有可以查看的成绩信息如果在基本流中,系统不能找到这个学生上个学期的任何成绩信息,将会显示一个消息。

学生确认这条消息后,用例终止。

3.特殊需求没有和本用例有关的特殊需求。

4.前置条件1. 登录在本用例开始之前,学生要登录到系统。

5.后置条件没有和本用例有关的后置条件。

6.扩展点没有和本用例有关的扩展点。

课程注册用例1. 简要说明此用例允许学生登记当前学期的课程。

如果在学期开始的选/退课期间情况发生一些变化,那么学生也可以修改或删除自己所选的课程。

课程目录系统提供一个本学期所有课程的列表。

本用例主要的主角是学生。

课程目录系统是用例中包含的一个主角。

2. 事件流当学生从主窗体中选择“维护课程表”活动时,此用例就开始使用了。

1. 基本流—创建课程表1.学生选择“创建课程表”。

2.系统会显示一张空白课程表。

3.系统从课程目录系统中检索可选课程的列表。

4.学生从可选课程列表中选择 4 门主修课程和 2 门选修课程。

在完成选择后,学生选择“提交”。

5.在此步骤中为每一门所选课程执行“添加课程”子流程。

6.系统保存该课程表。

2. 备选流1. 修改课程表1.学生选择“修改课程表”。

2.系统检索并显示学生现在的课程表(例如,本学期的课程表)。

3.系统从课程目录系统中检索本学期所有可选课程的列表。

系统向学生显示该列表。

4.这样,学生就可以通过删除或者添加新课程来修改所选的课程。

学生从可选课程列表中选择要添加的课程。

学生也可以从目前的课程表中选择要删除的课程。

购物车用例规约

购物车用例规约

用例1 提交购物车
前置条件:用户登录系统。

基本事件流:
(1)用户在购物车查看页面,单击“结算”按钮时用例开始。

(2)提交购物车,购物车的内容进入审核。

备选事件流:
(1)在基本事件流步骤1中,如果用户会话信息过期,则跳转到用户登录页面,完成用户登录后转至基本事件流步骤2;
(2)在基本事件流步骤1中,如果购物车内容为空,则提示用户,并跳转到商品购买页面。

后置条件:提交购物车成功。

用例2 查看购物车
前置条件:用户登录系统。

基本事件流:
(1)用户访问购物车页面时用例开始。

备选事件流:
(1)在基本事件流步骤1中,用户访问购物车页面,如果用户没有购买任何的商品,则提示“没有任何商品”。

(2)在基本事件流步骤1中,如果购物车中的商品没有通过审核,则提示“商品没有通过审核”。

后置条件:显示购物车。

用例规约——精选推荐

用例规约——精选推荐

学籍管理系统1.术语表2.系信息管理(系统管理员)2.1用例规约2.11 查询系信息2.12删除系信息用例规约:2.13 修改系信息用例规约:2.14录入系信息用例规约:图SSM-XXXM-1图SSM-XXXM-2图SSM-XXXM-3图SSM-XXXM-4 3.补充规约补充规约3.1简介3.1.1目的本文档的目的是定义学籍管理系统的需求。

本补充规约列出了不便于在用例模型的用例中获取的系统需求。

补充规约和用例模型一起记录对系统的一整套需求。

3.1.2范围本系统适用于学校的学籍信息管理,使得管理员和教师从繁重的管理工作中解脱出来,轻松管理学生的相关信息。

3.1.3参考资料适用的参考资料包括:1.补充规约说明(百度文库)2.UML说明与Rose建模3.2功能3.2.1系统错误记录所有的系统错误都应当记录下来。

系统的致命错误会导致系统的有序关闭。

系统错误消息应包括错误的文本说明、操作系统的错误代码(如果适用于该错误)、检测错误状态的模块、数据戳和时间戳。

所有的系统错误都应保存在错误日志数据库中。

3.2.2在线操作学生可以在线查询和修改个人信息,导师可以查询学生的信息,并对其信息进行提出建议或修改,管理员对系统进行维护及时发布信息。

3.3可用性3.3.1Windows 兼容性桌面用户界面应与Windows XP/7 兼容。

3.3.2易于使用的设计学籍管理系统用户界面的设计应当着眼于易于使用,使具有一定计算机知识的用户群体不需要经过更多的培训就能够使用该系统。

3.4可靠性本节列出了所有的可靠性需求。

3.4.1 <可行性>该系统必须提供一个Windows XP /7 的用户交互界面。

3.4.2 <平均故障间隔时间>MTBF(平均故障间隔时间)需求将在下次迭代中定义。

3.5性能3.5.1<性能需求一>该用户的数据库应能够支持3000 名用户对数据库的同一时刻的访问,并且该系统的服务器应能够支持1000名用户对其的同一时刻的访问。

模板-用例规约

模板-用例规约
文档编号:5组
密级:内部
缤纷视频网项目
用例规约
二零一三年七月
关于本文档
项目名称
×××项目
主 题
用例规约
说 明
该项目用于网上购物
适用对象
该项目适用于代替以往的购物方式,改为网上购买食品的用户。
修订历史
版本
章节
类型
日期
作者
说明
1.0
C
说明:类型-创建(C)、修改(U)、删除(D)、增加(A);
评审记录
角色
er点击‘确认’按钮,删除商品信息
4.系统删除选中的商品信息,并更新商品信息列表
其它事件流:
第3步,user选择“取消”,系统将取消删除操作,并返回商品列表页面
异常事件流:
第4步,系统删除商品信息时出现系统故障,例如网络故障,数据库服务器故障,系统弹出系统异常页面,提示user删除失败
后置条件:
6.系统保存结账信息,并返回到商城主页面。
其它事件流:
第1步,user若没有登录系统,则提示用户先登录系统,同时若是用户没有注册账号,提示用户先注册账号
第2步.user选择‘修改’按钮,对已选购的商品信息进行修改
第2步.若用户是首次结账,需要填写送货地址,送货地址包括:姓名、本地/外地、通讯地址、邮政编码、电话号码。非首次结帐,显示上次购物时的送货地址,并默认为本次的送货地址。
其它事件流:

异常事件流:
第6步,系统保存商品数量时出现系统故障,例如网络故障,数据库服务器故障,系统弹出系统异常页面,提示user更改商品数量失败
后置条件:
系统更新商品数量信息。
2.1.4结账
用例描述:
用例名称:
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
登录用例
1.简要说明
本用例说明用户如何登录到课程注册系统。
启用此用例的主角为学生、教授和注册员。
2.事件流
当主角在登录表中键入他(她)的名字和口令时,本用例就开始了。
1.基本流-登录
1.系统验证主角的口令并允许他(她)登录到系统。
2.系统显示主窗体,同时用例结束。
2.备选流
1.无效的用户名/口令
如果在基本流中系统无法找到用户名或者口令无效,就会显示一个错误信息。主角可以键入新的用户名或者口令,或者选择取消本次操作,此时用例结束。
5.后置条件
没有和本用例有关的后置条件。
6.扩展点
没有和本用例有关的扩展点。
提交成绩用例
1.简要说明
本用例允许教授提交上个学期结束授课的一个或多个班的学生成绩。
本用例的主角是教授。
2.事件流
当教授从主窗体中选择“提交成绩”活动时,此用例就开始使用了。
1.基本流—提交成绩
1.系统显示教授上个学期所讲授课程的列表。
2.备选流
1.未讲授过课程
如果在基本流中教授在上一学期中没有讲授任何课程,系统显示错误信息同时用例结束。
2.取消课程
如果在补/退选阶段有非常多的学生退出某门课程,则在学期开始后该课程将被取消,系统就会显示一个错误信息。如果教授选择取消操作,则用例结束,否则将从基本流的第 2 步重新开始。
3.特殊需求
3.特殊需求
没有和本用例有关的特殊需求。
4.前置条件
1.登录
在本用例开始前,教授要登录到系统。
5.后置条件
没有和本用例有关的后置条件。
6.扩展点
没有和本用例有关的扩展点。
维护学生信息用例
1.简要说明
本用例允许注册员维护注册系统中的学生信息。其中包括添加、修改和从系统中删除学生信息。
本用例的主角是注册员。
本用例主要的主角是注册员。收费系统是本用例中包含的一个主角。
2.事件流
当注册员从主窗体中选择“结束注册”活动时,用例就此开始使用了。
1.基本流-成功结束注册
系统检查注册是否正在进行。如果是,将有一个消息显示给注册员,然后用例终止。如果注册正在进行,则结束注册处理将无法执行。
对每门开设的课程,系统检查是否有三名学生注册以及是否有教授登记讲授这门课。如果满足这个条件,系统将结束课程注册,并将每位选修课程的学生的事务发送到收费系统。
8.结束课程注册
如果在学生选择“维护课程表”时,本学期的注册就已经结束,学生将看到一条信息,同时用例结束。在本学期注册结束后,学生不能再注册课程。
3.特殊需求
没有和本用例有关的特殊需求,学生要登录到系统。
5.后置条件
没有和本用例有关的后置条件。
6.扩展点
没有和本用例有关的扩展点。
2.事件流
当教授从主窗体中选择“选择讲授课程”活动时,此用例就开始使用了。
1基本流—选择讲授课程
1.系统检索并显示本学期教授胜任教学的课程的列表。系统还检索并显示教授以前讲授过的课程的列表。
2.教授可以选择在新学期他(她)希望讲授的课程,或者取消选择。
3.对于被取消的课程,系统将教授的信息从该课程中删除。
6.未发现课程表
在“修改课程表”或“删除课程表”子流程中,如果系统无法检索到学生的课程表,将会显示一个的错误信息。学生确认这条错误信息后,用例重新开始。
7.课程目录系统不可用
如果经过一定次数的尝试之后,系统仍然无法与课程目录系统通信,那么系统将向学生显示一条错误信息。学生确认这条错误消息后,此用例终止。
如果系统在试图建立教授选择要任教的课程时,发现课程表有冲突,系统将会显示一条错误消息,指明课程表有冲突。系统还将指出哪些课程发生冲突。教授可以选择解决课程表冲突(例如,取消他选择任教的某门课程),也可以取消本次操作,此时任何选择都将丢失,同时用例结束。
3.结束课程注册
如果在教授选择“选择讲授课程”后,本学期的注册就结束了,教授会看到一条信息,同时用例结束。在本学期注册结束之后,教授不能变更他们要讲授的课程。如果在注册结束之后,教授需要更改课程,这将在系统范围外进行处理。
6.扩展点
没有和本用例有关的扩展点。
课程注册用例
1.简要说明
此用例允许学生登记当前学期的课程。如果在学期开始的选/退课期间情况发生一些变化,那么学生也可以修改或删除自己所选的课程。课程目录系统提供一个本学期所有课程的列表。
本用例主要的主角是学生。课程目录系统是用例中包含的一个主角。
2.事件流
当学生从主窗体中选择“维护课程表”活动时,此用例就开始使用了。
3.当学生完成查看成绩信息后,选择“关闭”。
2.备选流
1.没有可以查看的成绩信息
如果在基本流中,系统不能找到这个学生上个学期的任何成绩信息,将会显示一个消息。学生确认这条消息后,用例终止。
3.特殊需求
没有和本用例有关的特殊需求。
4.前置条件
1.登录
在本用例开始之前,学生要登录到系统。
5.后置条件
没有和本用例有关的后置条件。
一旦处理完该学期所有的课程安排,系统将通过邮件方式向所有学生通知他们课程表的变化(例如,取消或替换)。
3.所开课程无教授任教
如果在基本流中存在没有教授登记讲授某门课程,那么系统将取消这门课程。“取消课程”子流程此时将被执行。
4.收费系统无法使用
如果系统无法与收费系统通信,那么系统将尝试在经过一段指定的时间后重新发送请求。该系统不断地尝试重新发送直到收费系统变为可用为止。
3.特殊需求
没有和本用例有关的特殊需求。
4.前置条件
没有和本用例有关的前置条件。
5.后置条件
没有和本用例有关的后置条件。
6.扩展点
没有和本用例有关的扩展点。
选择讲授课程的用例
1.简要说明
本用例允许教授从课程目录里选择他(她)在新学期适合任教而且也愿意讲授的课程(课程的时间和日期将在以后安排)。
教授是开始本用例的主角。课程目录系统是用例中包含的一个主角。
2.备选流
1.所开课程少于三名学生
如果在基本流中,某门课程报名的学生少于三人,系统将取消该课程。“取消课程”子流程此时将被执行。
2.取消课程
系统取消课程。对于每一个登记了取消课程的学生,系统都将修改该学生的课程安排表。被取消的课程将被第一个可选的备选课程所代替。如果没有替代课程,就不进行替换。控制返回主要流程中以便对该学期下一门课程进行处理。
4.未发现学生信息
在“修改学生信息”或“删除学生信息”子流程中,如果指定 ID 号码的学生的信息不存在,系统将会显示一个“未发现学生信息”的错误消息。注册员可以键入另一个 ID 号码或者取消本次操作,此时用例结束。
3.特殊需求
没有和本用例有关的特殊需求。
4.前置条件
1.登录
在本用例开始前,注册员要登录到系统。
1.修改课程表
1.学生选择“修改课程表”。
2.系统检索并显示学生现在的课程表(例如,本学期的课程表)。
3.系统从课程目录系统中检索本学期所有可选课程的列表。系统向学生显示该列表。
4.这样,学生就可以通过删除或者添加新课程来修改所选的课程。学生从可选课程列表中选择要添加的课程。学生也可以从目前的课程表中选择要删除的课程。在完成编辑后,学生选择“提交”。
5.注册员选择“删除”。
6.系统会显示一个删除确认对话框以确认删除操作。
7.注册员选择“是”。
8.学生信息从系统中删除。
9.每删除一个学生信息,重复步骤 2-8。当注册员完成从系统中删除学生时,此用例结束。
3.学生信息已经存在
在“添加学生信息”子流程中,如果系统发现具有相同姓名的学生的信息已经存在,将会显示一个“学生信息已经存在”的错误消息。注册员可以修改姓名、选择创建另一个同名的学生的信息或者取消本次操作,此时用例结束。
2.事件流
当注册员从主窗体中选择“维护学生信息”活动时,用例就开始使用了。
1.基本流—添加学生信息
1.注册员选择“添加学生信息”。
2.系统会显示一张空白学生信息表。
3.注册员输入学生的下列信息:姓名、出生日期、社会保障号、目前状况和毕业日期。
4.系统验证数据以确保格式正确,并按照指定姓名来搜索系统中已有的学生信息。如果数据有效,系统将创建一个新的学生信息并分配一个由系统生成的唯一 ID 号。
4.添加课程
系统核实学生符合所需的先决条件并且该课程人数未满。然后系统将学生添加到所选的课程中。这样,该课程在课程表中标记为“已登记”。
5.先决条件不满足或课程已经满员
如果在“添加课程”子流程中,系统确定学生没有满足必要的先决条件或者所选择的课程人数已满,就会出现一个错误消息。学生可以选择另一门课程,也可以取消本次操作,此时用例重新开始。
课程注册系统用例规约
版本<1.0>
查看成绩报告卡用例
1.简要说明
本用例允许学生查看他(她)刚结束学期的成绩报告卡。
本用例的 Actor 是学生。
2.事件流
当学生从主表格中选择“查看成绩报告卡”活动时,用例开始。
1.基本流—查看成绩报告卡
1.系统检索出学生上个学期所修完的每门课程的成绩信息。
2.系统准备、排版并显示成绩信息。
5.在此步骤中为每一门所选课程执行“添加课程”子流程。
6.系统保存该课程表。
2.删除课程表
1.学生选择“删除课程表”活动。
2.系统检索并显示学生当前的课程表。
3.学生选择“删除”。
4.系统提示学生核实该删除操作。
5.学生核实删除操作。
6.系统删除课程表。
3.保存课程表
在任何时候,学生都可以不提交而选择“保存”来保存课程表。课程表将被保存,但是该学生的信息没有添加到所选课程中。所选的课程在课程表中标记为“已选”。
相关文档
最新文档