用例分析之用例规约样例
公司管理系统的用例规约
公司管理系统的用例规约用例名称：公司管理系统参与者：管理员、员工前置条件：管理员已登录系统用例描述：管理员通过公司管理系统对员工进行管理和操作。
基本流程：1. 管理员登录公司管理系统。
2. 系统验证管理员身份并登录成功。
3. 管理员选择需要进行的操作：包括新增员工、删除员工、修改员工资料等。
4. 管理员输入相应的员工信息（新增员工需要填写所有必要信息，删除和修改员工需要提供员工的唯一标识）。
5. 系统验证输入信息的合法性，如输入员工ID是否已经存在等。
6. 管理员确认提交操作。
7. 系统保存相关信息，并进行相应的操作（如新增员工、删除员工、修改员工资料等）。
8. 管理员成功完成操作，系统提示操作成功。
备选流程：- 如果管理员登录失败（用户名或密码错误），系统提示登录失败并重新要求管理员输入用户名和密码。
- 如果管理员输入的员工信息有误（如员工ID已经存在），系统提示相关错误信息，要求管理员重新输入。
- 如果管理员取消了操作，系统不进行任何保存和操作，提示取消操作。
后置条件：管理员退出系统。
异常流程：- 管理员登录失败：系统提示登录失败并重新要求管理员输入用户名和密码。
- 管理员输入的员工信息有误：系统提示相关错误信息，要求管理员重新输入。
- 管理员取消了操作：系统不进行任何保存和操作，提示取消操作。
特殊需求：- 系统需要保证管理员的登录信息和操作信息的安全性和权限控制。
- 系统需要支持对员工信息的搜索、排序和过滤等功能。
- 系统需要提供数据备份和恢复功能，以保证数据的安全性和可靠性。
网上书店——用例规约
如果管理员输入无效的用户名和（/或）密码，系统显示错误信息。管理员可以选择返回基流的起始点，重新输入正确的用户名和（/或）密码；或者取消登陆，用例结束
前置条件
无
后置条件
用例成功后，管理员登陆进入系统
扩展点
无
9．维护顾客信息
简要说明 本用例用于维护顾客信息。包括添加、修改和删除顾客信息
事件流
基本流
无。
2．个人信息管理
简要说明
本用例用于给顾客维护个人信息。包括修改本人的账号、密码和联系地址等信息。
事件流
基本流
当顾客查看并修改个人信息时，开始执行以下基本流：
（1）系统返回给当前顾客在系统数据库中目前存储的个人信息。
（2）顾客可以对本人信息的一项或几项进行修改。
（3）顾客向系统提交修改后的个人信息。
扩展点
无
进入图书信息修改界面，修改并保存图书信息
S-2：删除图书信息
管理员单击删除按钮，相应的图书被删除并更新数据库
S-3：添加图书信息
进入图书信息添加页面，添加并保存图书信息
特殊需求
无
前置条件
管理员登陆
后置条件
用例成功后，图书信息被添加、改变或删除
扩展点
无
11．订单管理
简要说明
本用例是管理员用来管理顾客订单信息之用。该用例接收从银联系统反馈来的关于某顾客的订单是否扣款成功的信息，然后把该信息以电子邮件的方式通知该客户。对于扣款成功的订单，通知物流系统给该订单的顾客配送所购书籍
备选流
顾客输入的新信息验证错误
如果系统检测到顾客输入的信息格式或内容有错（如输入新密码和确认输入新密码不一致等），会向顾客给予错误提示，并要求用户重新输入或取消修改的操作。
需求分析-用例图-用例规约
2a.1 游客重新注册 2b.游客输入密码过短
2b.1 游客重新注册
用例名:登陆 参与者:普通用户 事件流: 1.用户访问论坛首页，选择登陆按钮，进入登陆界面 2.用户输入用户名、密码，完成登陆 可选路径: 2a.用户输入用户名或密码错误
2a.1 系统提示出错，并要求用户重新输入用户名及密码
用例名:个人资料管理 参与者:普通用户 事件流: 1.用户登陆并进入个人中心
3a.1 系统提示待添加用户与已有用户重复 3b.相应版块版主设置数量达到上限
3b.1 系统提示该版块版主数量设置达到上限
用例名:报表管理 参与者:管理员 事件流: 1.管理员登陆管理系统 2.管理员查看报表，或打印报表
用例图
用例规约
用例名:浏览帖子 相关需求:选择相应版块、浏览帖子 参与者:游客、用户 前置信息:游客访问论坛首页并选择相应版块 后置信息:显示当前帖子 主成功场景的事件流: →1.用户访问论坛首页，选择版块 ←2.服务器响应点击事件，跳转页面 →3.用户浏览版块下的帖子
←3a.1 系统提示错误 →3a.2 游客重新输入注册信息 →3b.游客填写的密码过短 ←3b.1 系统提示错误 →3b.2 游客重新输入注册信息
用例名:登陆 相关需求:用户登陆论坛 参与者:用户 前置信息:用户点击登陆按钮进入登陆界面，输入用户名和密码 后置信息:登陆成功进入论坛 主成功场景的事件流: →1.用户点击登陆按钮 ←2.服务器响应点击事件，跳转到登陆界面 →3.用户输入用户名和密码 ←4.登陆成功，用户进入论坛页面 扩展事件流: →3a.用户输入错误的用户名或密码
图书管理系统用例规约
图书管理系统用例规约用例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.优先级高。
用例规约表格模板(基于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.退出该系统特殊需求无扩展点无备注无用户下单付款数据流图。
用例规约模板
用例模板
用例名称（用例名）
用例目标（用例在系统中的目标）
级别（概要任务/首要任务/子功能）
活动者（此用例的活动者）
状态（未定义路径/只定义了初始路径/路径定义完成）
前置条件（用例执行千系统应具有的状态）
后置条件（用例成功执行后系统应具有的状态）
主路径（用例主路径的名称）
可选路径（用例的可选路径）
例外路径（用例的例外路径）
举例：
用例名称修改密码
用例目标当用户修改自己的密码时用例开始。
它处理修改密码问题。
当用户结束修改市用例结束
级别子功能
活动者用户
状态只定义了初始路径
前置条件用户登录进入系统
后置条件用户的密码已得到修改
主路径用户修改密码，系统保存修改
可选路径用户修改密码，最后放弃对密码的修改
例外路径用户输入的原密码有误，或者两次输入的新密码不一致，系统显示错误信息。
用户可以选择返回主路径的起始点，重新输入正确的原
始密码以及两次一致的新密码；或者取消修改。
用例规约模板
ABC 医疗影像后处理系统 V2.0用例规约: Process Colon Series中文名称：分析结肠序列用例编号：CU-ABC-COLON-BASE-001主编:***Version 1.0 1.版本历史：2.目录1.版本历史： (1)2.目录 (1)3.简要说明 (1)4.执行者(ACTORS) (2)5.前置条件(PRE-CONDITION) (2)6.后置条件(POST-CONDITION) (2)7.涉众利益(STAKEHOLDER) (2)8.用例场景 (USE CASE SCENARIO) (2)8.1.基本流程（B ASE F LOW） (2)8.2.扩展流程： (2)9.特殊需求（SPECIAL REQUIREMENT） (3)3.简要说明处理数据，显示结肠的三维图像等。
具体包括：1、读取序列数据，2、自动结肠分割3、自动提取中心线，4、三维图展示，渲染效果；5、在三维图中显示中心线；4.执行者该用例由ABC中的《用例：Process Request Series》启动。
5.前置条件1、Process Request Series用例已经正确地获得了序列数据，并生成了体数据；2、命令已经被正确解析为COLON分析；6.后置条件序列被正确分析成结肠，完成结肠初步路径的提取显示和三维效果显示。
7.涉众利益8.用例场景8.1.基本流程（Base Flow）1.系统分析体数据，对数据进行处理，分割出结肠；2.系统对数据进行处理，提取中心线；3.系统显示数据到默认布局的界面（3D、ACS，ENDO，BAND视图）；4.系统显示结肠中心线到3D视图中；5.系统显示渲染效果。
6.如图所示：其中读取序列数据（包括自动生成数据由调用方提供）18.2.扩展流程：9.特殊需求1、结肠包括的视图有：3D,Axial, Coronal, Sagittal,3D Zoom,Axial Zoom, Coronal Zoom, Sagittal Zoom, Endo,Band,Cube。
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旅店管理系统⽤例图、⽤例规约
⼀.旅店管理系统⽤例图
⼆．⽤例规约
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．管理员只能在后台运行。
三、特殊要求无。
四、前置条件该会员必须是本网站已注册的成员。
用例分析之用例规约样例
2.当系统确认操作者具备导入权限时,进入采购信息导入界面。操作者选择将要导入的Excel文件（用本地浏览等方式），点击<确定>。如果要导入的采购信息在系统中已经存在（可以根据采购姓名和出生日期判断），那么系统提示：“该采购信息已经存在！”点击<确认>返回导入页面——单个导入的情况（或者，在系统提示并得到<确认>后，跳过此采购信息继续导入其余信息——多个导入的情况）。
3.导入完成后，系统提示：“采购信息导入成功！”
4.采购信息导入完毕后，系统自动调用用例3.1,记录采购信息导入现场记录，以便用例3.2使用。
5.当导入的采购属于业主时,通常会连带导入相应的物业信息。(其实这个步骤不必要，物业信息可以单独导入，并且在业主信息中设置有对应物业信息的检索)。
用例可选事件流
异常情况处理等非正常工作流程。
用例交系统存储,且得到确认无误后退出用例。
用例非功能性需求:
1.要求导入的Excel表的格式有固定的规范。
2.以各个分公司为单位的创建人所创建的采购信息只有该分公司的所属工作人员才有权利使用。哦年
3.关于供方信息和求方信息的分类，在采购信息属性中已经设置，所以在导入的时候不必特意分类。
修改历史
修改日期：8月3日
顺序图：PC3:UCk:SEQ1:批量导入采购信息正常流程顺序图
边界类原型：
类图：
用例主要参与者:
以各个分公司为单位的采购信息创建人,该创建人巳由分公司经理分配给创建采购信息的权限。
用例触发事件:
当某个分公司接收到填写于Excel表中的采购信息时，为了将此类信息以简捷的方式纳入系统管理范围，需要将采购信息直接导入系统。
用例规约例子
用例规约例子
以下是 6 条用例规约例子：
1. 咱就说，你去超市买东西，这不就是一个很常见的用例规约嘛！你知道自己要买啥，什么品牌、多少数量，这不就跟软件里的各种条件、步骤一样一样的嘛？比如说，你决定要买巧克力，然后选了某个牌子，接着看价格和重量，哎呀，这就跟程序里的各种设定和判断太像啦！
2. 你想想看，你每天早上起床后要做的一系列事情，也是个用例规约呀！刷牙、洗脸、换衣服，每一步都有先后顺序和特定的操作呢！就像软件运行时，一个步骤紧接着一个步骤，可不能乱了呀！比如你总不能先换衣服再刷牙吧，这多别扭呀！
3. 嘿，你知道煮饺子也是个好例子呢！先准备水，水开了下饺子，然后等饺子煮熟，捞出来，每一步都不能马虎呀！这在软件里不就相当于一个个明确的流程和规定嘛，水就像是输入，饺子煮熟就是输出，这过程多清晰啊！难道不是吗？
4. 你和朋友约着出去玩，这整个过程也是个用例规约呀！先商量去哪里，再确定时间，然后怎么碰面，一点都不能乱来呢！这不就跟程序里的流程规划一样嘛，一环扣一环的。
你再想想，如果商量不好，那可就玩不成啦，就像程序出错就运行不下去一样呀！真的好形象呀！
5. 哎呀，就连你写作业都是个典型的例子呀！先拿出本子和笔，再看题目，思考怎么做，然后开始写，最后检查。
这和软件中的用例规约简直如出一辙嘛！你可别小瞧这写作业的过程呢，像不像程序在一步步执行任务？
6. 你看那些运动员比赛，也是有他们的用例规约呀！比如跑步比赛，先站在起跑线，听口令，起跑，冲刺，每一步都很关键呀！这多像软件运行时的各种规定呀，每一个动作都得精确无误呀！不然怎么能赢得比赛呢，你说对吧？
我的观点结论就是：生活中到处都是用例规约的例子呀，真的太有意思啦！。
用例规约(实例)
课程注册系统用例规约版本<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.这样，学生就可以通过删除或者添加新课程来修改所选的课程。
学生从可选课程列表中选择要添加的课程。
学生也可以从目前的课程表中选择要删除的课程。
用例规约示例-ATM用例图-取款
用例包括：
1）存款：客户持银行卡（本行或其他行）从ATM存放现金
2）取款：客户持银行卡（本行或其他行）从ATM提取现金
3）查询：客户持银行卡（本行或其他行）在ATM上查询卡的帐户信息
4）转账：客户持银行卡码：客户持银行卡（本行或其他行）在ATM修改卡的密码
如果最后一次尝试输入的PIN码仍然错误，则该卡将被ATM机保留，同时ATM返回到准备就绪状态，本用例终止。
备选流5 -帐户不存在
在基本流步骤4中-验证帐户和PIN，如果银行系统返回的代码表明找不到该帐户或禁止从该帐户中提款，则ATM显示适当的消息并且在步骤9 -返回银行卡处重新加入基本流。
备选流6 -帐面金额不足
备选流3 - ATM内现金不足
在基本流步骤6中-输入金额，如果ATM机内金额少于请求提取的金额，则将显示一则适当的消息，并且在步骤6 -输入金额处重新加入基本流。
备选流4 - PIN有误
在基本流步骤4中-验证帐户和PIN，客户有三次机会输入PIN。
如果PIN输入有误，ATM将显示适当的消息；如果还存在输入机会，则此事件流在步骤3 -输入PIN处重新加入基本流。
3)输入PIN–ATM机提示并要求客户输入PIN码（4位）。
4)验证帐户代码和PIN–ATM机验证帐户代码和PIN以确定该帐户是否有效以及所输入的PIN对该帐户来说是否正确。对于此事件流，帐户是有效的而且PIN对此帐户来说正确无误。
5)ATM选项- ATM机显示在本机上可用的各种选项。在此事件流中，银行客户通常选择“提款”。
备选流2 - ATM内没有现金
备选流3 - ATM内现金不足
备选流4 - PIN有误
备选流5 -帐户不存在/帐户类型有误
业务用例规约示例
a.申请户名应无历史欠费记录
这一栏中可以用过程步骤的编号来引用相关的业务规则。若该规则仅作用于本用例，可以加上面例子直接书写。若该规则作用于多个业务用例，建议编写专门的业务规则文档,为每个业务规则编号。在这里引用编号即可。如
Rule001
涉及的业务实体(中英文对照)
Be_XXX(申请单)
5.勘察员现场勘察,填写现场勘察工作单,给出是否符合用电条件结论.符合条件执行6,不符合条件执行异常过程5.1.1
6.审批过程为并行过程,同时执行分支过程6.1.1和6.2.1.两个分支过程均需执行完毕并有审批结果.若两个分支过程审批都同意,执行7,若一方或两方都不同意.执行7,若一方或两方都不同意,执行异常过程6.3.1
2.成功建立收费帐户和结算帐户
3.成功建立抄表台帐
4.成功建立监察档案Fra bibliotek5.成功建立计量档案
主过程描述
1.用电用户到营业大厅填写用电申请表,提交营业柜台
2.营业员初步核实申请信息,查询该用户是否有欠费记录,符合条件则启动用例
3.营业员录入申请信息,产生用电申请单
4.业务班长审查申请单,产生现场勘察工作单,分配勘察员执行任务
Be_XXX(现场勘察单)
Be_XXX(业务收费清单)
Be_XXX(电表安装工作单)
Be_XXX(用户档案)
Be_XXX(收费帐号)
Be_XXX(抄表台帐)
Be_XXX(监察档案)
Be_XXX(计量档案)
这一栏中可以列出与该业务用例相关的业务实体。一般情况下，业务实体要在晚一些的过程中才能产生。这里为了示意特别列出。在正常建模过程中，这一栏的内容要等建立了业务对象模型以后才能确定。
业务用例规约示例
用例规约——精选推荐
学籍管理系统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名用户对其的同一时刻的访问。
模板-用例规约
密级：内部
缤纷视频网项目
用例规约
二零一三年七月
关于本文档
项目名称
×××项目
主 题
用例规约
说 明
该项目用于网上购物
适用对象
该项目适用于代替以往的购物方式，改为网上购买食品的用户。
修订历史
版本
章节
类型
日期
作者
说明
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、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
4.采购信息导入完毕后，系统自动调用用例3.1,记录采购信息导入现场记录，以便用例3.2使用。
5.当导入的采购属于业主时,通常会连带导入相应的物业信息。(其实这个步骤不必要，物业信息可以单独导入，并且在业主信息中设置有对应物业信息的检索)。
用例可选事件流
异常情况处理等非正常工作流程。
用例后置条件:
最后一个采购信息导入完成并提交系统存储,且得到确认无误后退出用例。
用例非功能性需求:
1.要求导入的Excel表的格式有固定的规范。
2.以各个分公司为单位的创建人所创建的采购信息只有该分公司的所属工作人员才有权利使用。哦年
3.关于供方信息和求方信息的分类，在采购信息属性中已经设置，所以在导入的时候不必特意分类。
修改历史
修改日期：8月3日
顺序图：PC3:UCk:SEQ1:批量导入采购信息正常流程顺序图
边界类原型：
类图：
2.当系统确认操作者具备导入权限时,进入采购信息导入界面。操作者选择将要导入的Excel文件（用本地浏览等方式），点击<确定>。如果要导入的采购信息在系统中已经存在（可以根据采购姓名和出生日期判断），那么系统提示：“该采购信息已经存在！”点击<确认>返回导入页面——单个导入的情况（或者，在系统提示并得到<确认>后，跳过此采购信息继续导入其余信息——多个导入的情况）。
用例触发事件:
当某个分公司接收到填写于Excel表中的采购信息时，为了将此类信息以简捷的方式纳入系统管理范围，需要将采购信息直接导入系统。
用例前置条件:
Excel表中的信息以固定的规范格式填写。
用例主事件流
1.操作者登录系统，指定采购信息导入功能，系统获取操作人员的权限。当系统确认操作者不具备采购信息导入权限时,显示“您不具备此操作权限！“后返回上一级操作页面。
用例卡
用例名称
批量导入采购名单
用例编号
P1:UC3
作者
苑志敏
创建时间
2007.7.11
修改时间
评审者
最终用户
测试者
测试工程师
版本号
1
用例简要描述:
导入格式固定的Excel表形式的采的采购信息创建人,该创建人巳由分公司经理分配给创建采购信息的权限。