用例规约
系统用例规约
系统用例规约
系统用例规约是指对系统用例进行规范化描述的文档，包括用例的名称、编号、参与者、前置条件、后置条件、基本流程、扩展流程、异常流程等内容。
具体而言，系统用例规约需要包含以下内容：
1. 用例编号：每个用例都应该有一个唯一的编号，以便于管理和跟踪。
2. 用例名称：简短明了的用例名称，能够清晰地表达用例的功能。
3. 参与者：用例所涉及的各方参与者，包括主要参与者和次要参与者。
4. 前置条件：执行该用例之前必须满足的条件，如必须登录系统、必须有特定权限等。
5. 后置条件：执行该用例之后的系统状态，如生成订单、更新数据等。
6. 基本流程：用例的主要流程，包括各个步骤和参与者的交互。
7. 扩展流程：用例的可能扩展流程，通常用于描述一些特殊情况的处理方式。
8. 异常流程：用例的异常情况处理流程，包括可能出现的错误、异常和失败情况的处理方式。
总之，系统用例规约是一份详细描述系统用例的文档，能够帮助开发者更好地理解和实现系统功能，同时也能够让用户和参与者更清
晰地了解系统的功能和运行方式。
uml用例规约
uml用例规约UML（统一建模语言）用例规约是指对系统中某一特定功能或行为的详细说明和定义。
用例规约被用来描述系统中所需的所有输入、输出、前置条件、后置条件和用例执行步骤等信息。
在UML中，用例规约通常被用来描述用例的所有方面，包括预期的行为和系统响应。
下面将详细介绍一下UML用例规约。
UML用例规约通常包含以下几个方面：1. 名称：用例规约必须具有唯一的名称，以便与系统中的其他用例区分开来。
2. 概述：用例规约需要简要描述该用例的作用和目的。
3. 前置条件：描述执行该用例前必须满足的条件，这些条件可以是系统状态、数据要求、前置操作等。
4. 后置条件：描述执行该用例后的状态。
即系统状态、数据状态、后置操作等。
5. 执行步骤：用例规约必须描述用例的详细执行步骤，包括所有输入和输出。
6. 异常情况：描述当某个步骤失败或者出现错误时，应该采取的措施。
7. 优先级：描述该用例的优先级，以便团队能够确定该用例的重要性。
在编写UML用例规约时，需要遵循一些规则：1. 用例规约必须与用例图中的用例匹配。
2. 确保用例规约中包含所有必要的信息，以便其他团队成员能够理解和实现该用例。
3. 用例规约必须是准确的和一致的，以便与其他用例规约和系统文档相匹配。
在编写UML用例规约时需要注意以下几点：1. 用例规约应该易于理解和阅读，以便其他团队成员能够理解该用例的目的和执行步骤。
2. 用例规约应该尽可能清晰和简明，同时包含所有必要的信息。
3. 用例规约应该是一致的，遵循团队的规范和标准，以便与其他文档相匹配。
总之，UML用例规约是系统中描述某一特定功能或行为的详细说明和定义。
编写UML用例规约需要遵循一些规则和注意事项，以便其他团队成员能够理解和实现该用例。
公司管理系统的用例规约
公司管理系统的用例规约用例名称：公司管理系统参与者：管理员、员工前置条件：管理员已登录系统用例描述：管理员通过公司管理系统对员工进行管理和操作。
基本流程：1. 管理员登录公司管理系统。
2. 系统验证管理员身份并登录成功。
3. 管理员选择需要进行的操作：包括新增员工、删除员工、修改员工资料等。
4. 管理员输入相应的员工信息（新增员工需要填写所有必要信息，删除和修改员工需要提供员工的唯一标识）。
5. 系统验证输入信息的合法性，如输入员工ID是否已经存在等。
6. 管理员确认提交操作。
7. 系统保存相关信息，并进行相应的操作（如新增员工、删除员工、修改员工资料等）。
8. 管理员成功完成操作，系统提示操作成功。
备选流程：- 如果管理员登录失败（用户名或密码错误），系统提示登录失败并重新要求管理员输入用户名和密码。
- 如果管理员输入的员工信息有误（如员工ID已经存在），系统提示相关错误信息，要求管理员重新输入。
- 如果管理员取消了操作，系统不进行任何保存和操作，提示取消操作。
后置条件：管理员退出系统。
异常流程：- 管理员登录失败：系统提示登录失败并重新要求管理员输入用户名和密码。
- 管理员输入的员工信息有误：系统提示相关错误信息，要求管理员重新输入。
- 管理员取消了操作：系统不进行任何保存和操作，提示取消操作。
特殊需求：- 系统需要保证管理员的登录信息和操作信息的安全性和权限控制。
- 系统需要支持对员工信息的搜索、排序和过滤等功能。
- 系统需要提供数据备份和恢复功能，以保证数据的安全性和可靠性。
网上书店——用例规约
如果管理员输入无效的用户名和（/或）密码，系统显示错误信息。管理员可以选择返回基流的起始点，重新输入正确的用户名和（/或）密码；或者取消登陆，用例结束
前置条件
无
后置条件
用例成功后，管理员登陆进入系统
扩展点
无
9．维护顾客信息
简要说明 本用例用于维护顾客信息。包括添加、修改和删除顾客信息
事件流
基本流
无。
2．个人信息管理
简要说明
本用例用于给顾客维护个人信息。包括修改本人的账号、密码和联系地址等信息。
事件流
基本流
当顾客查看并修改个人信息时，开始执行以下基本流：
（1）系统返回给当前顾客在系统数据库中目前存储的个人信息。
（2）顾客可以对本人信息的一项或几项进行修改。
（3）顾客向系统提交修改后的个人信息。
扩展点
无
进入图书信息修改界面，修改并保存图书信息
S-2：删除图书信息
管理员单击删除按钮，相应的图书被删除并更新数据库
S-3：添加图书信息
进入图书信息添加页面，添加并保存图书信息
特殊需求
无
前置条件
管理员登陆
后置条件
用例成功后，图书信息被添加、改变或删除
扩展点
无
11．订单管理
简要说明
本用例是管理员用来管理顾客订单信息之用。该用例接收从银联系统反馈来的关于某顾客的订单是否扣款成功的信息，然后把该信息以电子邮件的方式通知该客户。对于扣款成功的订单，通知物流系统给该订单的顾客配送所购书籍
备选流
顾客输入的新信息验证错误
如果系统检测到顾客输入的信息格式或内容有错（如输入新密码和确认输入新密码不一致等），会向顾客给予错误提示，并要求用户重新输入或取消修改的操作。
用例规约怎么写？
⽤例规约怎么写？
UC001-发布公告
UC001（⽤例编号）-发布公告（⽤例名称）
⽤例描述
统标⼈员根据项⽬发⾏需求，发布债券发⾏公告
执⾏者
统标⼈员、交易员
前置条件
......
后置条件
......
基本路径
1.交易员输⼊债券项⽬信息，请求发布
2.系统校验项⽬信息充分
3.系统⽣成发布信息
...
扩展路径
1a.交易员输⼊债券项⽬信息，请求发布
2a.系统校验项⽬信息充分
补充约束
字段列表
1.债券基础信息=债券代码+债券简称+债券类型{国债|地⽅政府债|政策性⾦融债...}+票⾯利率+.....
业务规则
2.保留2位⼩数
质量需求
1.可⽤性
2.性能
3.可靠性
4.可⽀持性
设计约束
设计约束是在实现系统时必须要遵守的⼀些约束，包括界⾯样式、报表格式、平台、语⾔等。
用例技术-用例规约
用例技术-用例规约
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.用户输入基本信息（登录名和密码），点击确定按钮2.系统查找数据库，看该用户是否在数据库中。
若存在则进入主页面。
备选事件流： 1.输入无效的用户名或密码，提示用户名或密码不能为空或者提示用户名或密码不正确。
后置条件：登录成功特殊需求：没有和本用例有关的特殊需求。
扩展点：没有和本用例有关的扩展点。
添加学生用例简要说明：本用例说明管理员如何添加学生用户到系统。
角色：管理员前置条件：拥有初始化用户名脚本基本事件流：1.管理员通过脚本等方式初始化以确定的用户名，执行脚本。
2.系统查找数据库，看该用户是否在数据库中。
若不存在则随机生成密码并插入数据库,显示的返回用户名及密码；若用户名存在，则直接返回以待修改。
备选事件流： 1.输入用户名无效，则返回无效的用户名并统计。
后置条件：没有和本用例有关的后置条件。
特殊需求：没有和本用例有关的特殊需求。
扩展点：没有和本用例有关的扩展点。
删除学生用例简要说明：本用例说明管理员如何从系统中删除学生用户。
角色：管理员前置条件：已经成功登陆到系统。
基本事件流：1.管理员输入要删除的学生学号或学号范围，执行删除功能。
2.系统查找数据库，看该用户是否在数据库中。
若存在则删除对应学生信息。
备选事件流： 1.未找到对应学号的学生，系统提示未找到该用户。
后置条件：删除成功。
特殊需求：没有和本用例有关的特殊需求。
扩展点：没有和本用例有关的扩展点。
增加设备用例简要说明：本用例说明管理员如何增加设备并记录进入系统。
角色：管理员前置条件：已经成功登陆到系统。
基本事件流：1.管理员填写设备各种信息，确定添加。
2.系统把对应信息写入数据库，更新数据库。
备选事件流： 1.输入了已存在的设备编号，系统提示编号中已存在。
后置条件：增加成功。
特殊需求：没有和本用例有关的特殊需求。
用例规约示例
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机从银行卡的磁条中读取帐户代码， 并检查它是否属于可以接收的银行卡。
软件工程-用例规约
软件⼯程-⽤例规约
1、登陆系统
系统中的所有参与者均可以使⽤本⽤例登陆系统，要求输⼊合法的⽤户名和密码。
查询菜品信息的参与者是数据管理⼈员、顾客，⽤于查看酒店所有菜品的详细信息查询菜品⽤例规约
修改菜品信息的参与者是数据管理⼈员，⽤于修改酒店所有菜品的详细信息修改菜品⽤例规约
修改菜品信息的参与者是数据管理⼈员，⽤于修改酒店所有菜品的详细信息修改菜品⽤例规约
修改菜品信息的参与者是数据管理⼈员，⽤于增加酒店菜品的详细信息增加菜品⽤例规约
删除菜品信息的参与者是数据管理⼈员，⽤于删除酒店菜品的详细信息
查询员⼯信息的参与者是数据管理⼈员，⽤于查看酒店所有员⼯的详细信息查询员⼯⽤例规约
修改员⼯信息的参与者是数据管理⼈员，⽤于修改酒店所有员⼯的详细信息修改员⼯⽤例规约
修改员⼯信息的参与者是数据管理⼈员，⽤于修改酒店所有员⼯的详细信息修改员⼯⽤例规约
增加员⼯信息的参与者是数据管理⼈员，⽤于增加酒店所有员⼯的详细信息增加员⼯⽤例规约
9、删除员⼯信息
删除员⼯信息的参与者是数据管理⼈员，⽤于删除酒店员⼯的详细信息
查询vip客户信息的参与者是数据管理⼈员，⽤于查看酒店所有vip客户的详细信息查询vip客户信息⽤例规约
修改vip客户信息的参与者是数据管理⼈员，⽤于修改酒店所有vip客户的详细信息修改vip客户信息⽤例规约
修改vip客户信息的参与者是数据管理⼈员，⽤于修改酒店所有vip客户的详细信息修改vip客户信息⽤例规约
增加vip客户信息的参与者是数据管理⼈员，⽤于增加酒店vip客户
修改vip客户信息⽤例规约
删除vip客户信息的参与者是数据管理⼈员，⽤于删除酒店vip客户的详细信息。
用例规约(实例)
课程注册系统用例规约版本<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.这样，学生就可以通过删除或者添加新课程来修改所选的课程。
学生从可选课程列表中选择要添加的课程。
学生也可以从目前的课程表中选择要删除的课程。
uml用例规约
uml用例规约UML (Unified Modeling Language) 是一种广泛应用于软件工程领域的建模语言，它通过图形化的方式描述软件系统的不同方面。
其中，用例规约是 UML 中用例模型的一部分，用于详细定义系统的功能需求。
用例规约中包含了用例名称、参与者、前置条件、后置条件、基本流程以及可选的替代流程等内容。
下面将详细介绍用例规约的结构和各个部分的含义。
一、用例名称用例名称应简洁明确地描述该用例的功能。
例如，对于在线购物系统，一个用例的名称可以是“用户下单”。
二、参与者参与者是指与系统进行交互的实体，可以是人、其他系统或外部设备等。
在用例规约中，列出参与者的名称和对其的简要描述，以便清楚地了解使用该用例时所涉及的角色。
三、前置条件前置条件是指执行该用例前必须满足的条件。
例如，对于“用户下单”的用例，前置条件可能包括用户已登录到系统并选择了要购买的商品。
四、后置条件后置条件是指执行该用例后的系统状态或结果。
例如，对于“用户下单”的用例，后置条件可能包括生成订单并跳转到支付页面。
五、基本流程基本流程描述了用例的主要执行步骤。
通常按照时间顺序，从开始到结束依次描述每个步骤。
在描述基本流程时，可以使用活动图或流程图等图形工具来更好地展示。
六、可选的替代流程替代流程描述了在特定情况下，用例的执行可能会走不同的流程路径。
例如，在“用户下单”的用例中，用户可能会取消订单或选择使用优惠券等。
这些情况可以在替代流程中进行描述。
除了上述几个部分外，用例规约还可以包含其他内容，如预置条件、扩展点、例外处理和相关文档等。
这些内容可以根据具体的需求和项目进行适当的扩展。
在编写用例规约时，需要注意以下几点：1. 确保用例规约的准确性和清晰性，避免模糊或歧义的描述。
2. 用例名称应该简明扼要，能够准确地传达该用例的功能。
3. 参与者的身份和角色应该明确定义，以便准确描述用例的执行者和相应的交互。
4. 前置条件和后置条件应该具体明确，并确保执行用例时满足前置条件，可以达到预期的后置条件。
用例规约
用例规约描述变更记录填表说明本文档的目的是依据《需求规格说明书》和系统原型，建立用例模型，并对用例模型进行具体描述。
用例规约描述是面向对象分析和设计的重要步骤。
用例规约描述需要进行评审。
1引言文档（《用例规约描述文档》）是描述项目小组对项目进行需求分析得到的关于用户和系统之间交互作用的文本性描述文档。
目的用例是关于用户和系统之间相互作用的文本性描述，从外部角度描述系统的行为，表达系统应该做什么。
本文档通过用例规约描述，来进一步说明该系统需求，是下一阶段系统设计的基础，也是测试用例的重要依据。
定义概述ERMS用来对企业员工人力资源进行管理，主要功能包括员工资料管理、部门资料管理、请假事务管理、加班事务管理、考勤情况管理、薪金资料管理、业绩评定、用户权限管理。
因本系统包括桌面和WEB两个部分，各角色在使用系统时，因职责会有所偏重。
ERMS包括六种角色（Actor）：SystemUserDMUDEUERACEOSuperUserERM2用例描述2.1 桌面子系统2.1.1 员工资料管理模块ERAERM2.1.1.1 新增员工信息用例规约：2.1.1.2 删除员工信息用例规约：2.1.1.3 更新员工信息用例规约：2.1.1.4 查询员工信息用例规约：2.1.2 部门资料管理模块ERAERM2.1.2.1 新增部门信息 用例规约：2.1.2.2 删除部门信息用例规约：2.1.2.3 更新部门信息用例规约：2.1.2.4 查询部门信息用例规约：2.1.2.5 调动员工用例规约：2.1.3 假期管理模块ERMERA2.1.3.1 设置假期策略用例规约：2.1.3.2 更新假期策略用例规约：2.1.3.3 撤消假期用例规约：2.1.3.4 汇总部门休假用例规约：图-18 WIN -JXGL-4 汇总部门休假结果页面2.1.3.5 汇总员工休假用例规约：2.1.4 考勤管理模块ERMERA2.1.4.1 设置考勤策略用例规约：2.1.4.2 更新考勤策略用例规约：2.1.4.3 查询/删除当日考勤记录用例规约：2.1.4.4 查询/删除历史考勤记录用例规约：2.1.5 加班管理模块2.1.5.1 核实加班有效性用例规约：2.1.5.2 查询员工加班记录用例规约：2.1.5.3 部门汇总用例规约：2.1.6 薪金管理模块ERM2.1.6.1 薪金计算 用例规约：2.1.6.2 查看员工薪金 用例规约：2.1.6.3 部门汇总用例规约：2.1.6.4 薪金设定用例规约：2.1.7 系统用户管理模块SuperUser2.1.7.1 新增角色用例规约：2.1.7.2 更新角色用例规约：2.1.7.3 删除角色用例规约：2.1.7.4 查询角色用例规约：2.1.8 登陆模块2.1.8.1 登陆用例规约：。
软件工程-用例规约
系统中的所有参预者均可以使用本用例登陆系统，要求输入合法的用户名和密码。
登录系统用例规约用例编号UC-01用例名称登录系统用例描述系统验证用户身份合法性后进入系统参预者数据管理人员、后厨助手、收银员前置条件无后置条件用户登陆成功，进入系统主界面涉众利益1、用户希翼登陆后能按要求访问权限范围内的功能2、客户希翼系统安全可靠，非法用户不能进入系统基本路径 1 、参预者启动系统2 、系统显示登录信息填写界面3 、参预者填写用户名、密码4 、参预者提出登陆请求5 、系统检测信息的充分性6 、系统核查用户身份的合法性7 、系统查看用户登录的次数8 、参预者登陆成功，进入系统主界面扩展点 1 、登陆信息的不充分性，返回登陆界面2 、用户身份不合法，返回登陆界面3 、用户第一次登录系统，提示需设置数据库服务器参数字段列表业务规划非功能需求补充说明查询菜品信息的参预者是数据管理人员、顾客，用于查看酒店所有菜品的详细信息。
查询菜品用例规约用例编号UC-02用例名称查询菜品用例描述查询菜品的详细信息参预者数据管理人员、顾客前置条件参预者已经登陆系统后置条件返回菜品的详细信息涉众利益查看菜品时不能浮现删除或者修改等误操作基本路径 1. 参预者提出查询请求2. 系统显示菜品信息界面3. 参预者选择一个菜品请求查看菜品的详细信息4. 系统返回指定菜品的详细信息字段列表业务规划非功能需求补充说明修改菜品信息的参预者是数据管理人员，用于修改酒店所有菜品的详细信息。
修改菜品用例规约用例编号UC-03用例名称修改菜品用例描述修改菜品的详细信息参预者数据管理人员前置条件参预者已经登陆系统后置条件成功修改菜品涉众利益菜品发生变化时可及时修改基本路径 1. 参预者请求维护菜品信息2. 系统列出所有菜品的详细信息3. 参预者选择一条菜品信息4. 参预者请求修改菜品信息5. 系统返回修改菜品信息界面6. 参预者修改菜品信息7. 系统检查所修改的菜品信息的充分性8. 系统修改选中信息扩展点 1. 输入信息的不充分性2. 提示信息不充分，要求谨慎字段列表菜品信息=菜品编号+菜品名称+图片+类型+食材+备注业务规划非功能需求补充说明增加菜品用例规约用例编号UC-04用例名称增加菜品用例描述增加菜品的详细信息参预者数据库管理人员前置条件参预者已经登陆系统后置条件成功增加菜品涉众利益为酒店增加新的菜品基本路径1、参预者请求管理菜品信息请求2、系统显示菜品信息界面3、参预者请求增加菜品信息4、系统返回菜品信息界面5、参预者填写菜品信息6、系统验证菜品信息的充分性7、系统增加菜品扩展点1、输入信息的不充分性2、提示信息不充分，要求重新输入字段列表菜品信息=菜品编号+菜品名称+图片+类型+食材+备注业务规划非功能需求补充说明删除菜品用例规约用例编号UC-05用例名称删除菜品用例描述删除菜品的详细信息参预者数据管理人员前置条件参预者已经登陆系统后置条件成功删除菜品涉众利益菜品发生变化时可及时删除基本路径1、参预者选择一条菜品信息请求删除2、系统请求确认删除选中信息3、系统删除选中信息字段列表1、参预者选择撤销删除命令2、系统撤销信息删除业务规划非功能需求补充说明查询员工用例规约用例编号UC-06用例名称查询员工用例描述查询员工的详细信息参预者数据管理人员前置条件参预者已经登陆系统后置条件返回员工的详细信息涉众利益查看员工信息时不能浮现删除或者修改等误操作基本路径1、参预者提出查询请求2、系统显示员工信息界面3、参预者选择一个员工请求查看员工的详细信息4、系统返回指定员工的详细信息字段列表业务规划非功能需求补充说明修改员工用例规约用例编号UC-07用例名称修改员工用例描述修改员工的详细信息参预者数据管理人员前置条件参预者已经登陆系统后置条件成功修改员工信息涉众利益员工信息发生变化时可及时修改基本路径1、参预者请求维护员工信息2、系统列出所有员工的详细信息3、参预者选择一条员工信息4、参预者请求修改员工信息5、系统返回修改员工信息界面6、参预者修改员工信息7、系统检查所修改的员工信息的充分性8、系统修改选中信息扩展点1、输入信息的不充分性2、提示信息不充分，要求谨慎字段列表员工信息=姓名+性别+出生年月日+家庭住址+电话+籍贯+学历+照片+备注业务规划非功能需求补充说明增加员工用例规约用例编号UC-08用例名称增加员工用例描述增加员工的详细信息参预者数据管理人员前置条件参预者已经登陆系统后置条件成功增加员工信息涉众利益为酒店新进员工增加用户基本路径1、参预者请求管理员工信息请求2、系统显示员工信息界面3、参预者请求增加用户4、系统返回员工信息界面5、参预者填写员工信息6、系统检查所增加的员工信息的充分性7、系统增加用户扩展点1、输入信息的不充分性2、提示信息不充分，要求重新输入字段列表员工信息=姓名+性别+出生年月日+家庭住址+电话+籍贯+学历+照片+备注业务规划非功能需求补充说明删除员工信息的参预者是数据管理人员，用于删除酒店员工的详细信息。
用例规约模板
用例模板
用例名称（用例名）
用例目标（用例在系统中的目标）
级别（概要任务/首要任务/子功能）
活动者（此用例的活动者）
状态（未定义路径/只定义了初始路径/路径定义完成）
前置条件（用例执行千系统应具有的状态）
后置条件（用例成功执行后系统应具有的状态）
主路径（用例主路径的名称）
可选路径（用例的可选路径）
例外路径（用例的例外路径）
举例：
用例名称修改密码
用例目标当用户修改自己的密码时用例开始。
它处理修改密码问题。
当用户结束修改市用例结束
级别子功能
活动者用户
状态只定义了初始路径
前置条件用户登录进入系统
后置条件用户的密码已得到修改
主路径用户修改密码，系统保存修改
可选路径用户修改密码，最后放弃对密码的修改
例外路径用户输入的原密码有误，或者两次输入的新密码不一致，系统显示错误信息。
用户可以选择返回主路径的起始点，重新输入正确的原
始密码以及两次一致的新密码；或者取消修改。
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. 用例标识用例标识是对用例的唯一标识，一般使用一个简短的英文单词、短语或数字来表示。
用例标识的目的是方便人们对用例进行讨论和引用。
2. 用例名称用例名称是对用例的简要描述，通常使用一句话来描述用例的主要功能。
用例名称应该简明扼要，并能准确地表达用例的功能。
3. 参与者参与者是指与系统进行交互的人、角色或外部系统。
用例规约需要明确列出参与者，并对其进行详细的描述，包括参与者的名称、角色、职责等。
4. 前置条件前置条件是指在执行用例之前，系统必须满足的条件或者假设。
前置条件可以是某个系统状态、特定的数据或者其他的先决条件。
前置条件的描述应该清晰明确，方便开发人员和测试人员了解执行用例的背景。
5. 后置条件后置条件是指在执行用例之后，系统应该达到的状态或者结果。
后置条件描述了用例执行后的期望结果，可以是某个系统状态的改变、数据的更新或者其他的影响。
后置条件的描述应该清晰明确，并与前置条件相对应。
6. 基本流程基本流程是指用例的主要执行流程，描述了正常情况下用例的执行步骤。
基本流程应该是可读的、清晰的，并且能够准确地反映出用户对系统的需求和期望。
7. 异常流程异常流程是指用例在执行过程中可能出现的异常情况。
异常情况可以是系统错误、用户操作错误或者其他的异常情况。
异常流程应该根据具体的用例描述异常的类型、触发条件、处理方式等。
8. 预期结果预期结果是指用例执行完成后的期望结果。
预期结果应该是可验证的，可以根据具体的用例描述判断用例是否执行成功或失败。
9. 注意事项注意事项是对用例执行过程中需要特别注意的事项进行描述。
用例规约例子
用例规约例子
以下是 6 条用例规约例子：
1. 咱就说，你去超市买东西，这不就是一个很常见的用例规约嘛！你知道自己要买啥，什么品牌、多少数量，这不就跟软件里的各种条件、步骤一样一样的嘛？比如说，你决定要买巧克力，然后选了某个牌子，接着看价格和重量，哎呀，这就跟程序里的各种设定和判断太像啦！
2. 你想想看，你每天早上起床后要做的一系列事情，也是个用例规约呀！刷牙、洗脸、换衣服，每一步都有先后顺序和特定的操作呢！就像软件运行时，一个步骤紧接着一个步骤，可不能乱了呀！比如你总不能先换衣服再刷牙吧，这多别扭呀！
3. 嘿，你知道煮饺子也是个好例子呢！先准备水，水开了下饺子，然后等饺子煮熟，捞出来，每一步都不能马虎呀！这在软件里不就相当于一个个明确的流程和规定嘛，水就像是输入，饺子煮熟就是输出，这过程多清晰啊！难道不是吗？
4. 你和朋友约着出去玩，这整个过程也是个用例规约呀！先商量去哪里，再确定时间，然后怎么碰面，一点都不能乱来呢！这不就跟程序里的流程规划一样嘛，一环扣一环的。
你再想想，如果商量不好，那可就玩不成啦，就像程序出错就运行不下去一样呀！真的好形象呀！
5. 哎呀，就连你写作业都是个典型的例子呀！先拿出本子和笔，再看题目，思考怎么做，然后开始写，最后检查。
这和软件中的用例规约简直如出一辙嘛！你可别小瞧这写作业的过程呢，像不像程序在一步步执行任务？
6. 你看那些运动员比赛，也是有他们的用例规约呀！比如跑步比赛，先站在起跑线，听口令，起跑，冲刺，每一步都很关键呀！这多像软件运行时的各种规定呀，每一个动作都得精确无误呀！不然怎么能赢得比赛呢，你说对吧？
我的观点结论就是：生活中到处都是用例规约的例子呀，真的太有意思啦！。
用例规约
47
34/ 1
34/55
正式型（详细型）-扩展7
7b 用信用卡付账
1. 顾客输入他们的信用卡帐户信息 2. 系统向外部支付授权服务系统发出支付请求授权，
并请求支付批准
2a系统检测到和外部系统之间协作上的失败：
1.系统给出纳员发出一个出错信号 2.出纳员请顾客用其他方式付款
47
35/ 1
35/55
正式型（详细型）-扩展8
2. 销售人员：需要销售款得到更新 3. 顾客：需要购买并花费最小的精力得到快速的
服务，并需要支持退货功能
47
22/ 1
22/55
正式型（详细型）-3
3. 受益人及其利益：
4. 公司：需要精确地记录交易并满足客户的利 益。需要支付授权服务记录可接受的支付。 需要一些容错功能。需要账目和存货清单得 到自动的快速更新
o 如果一个用例的前置条件不执行，就不能执 行其他用例，可能意味着丢失了用例（例如： “管理订单”却没有“登录”用例）
47
11/ 1
写：可观测系 统的、 1. 动 作 2.改变
体现客户利益的
文字 4. 回 应
3.验证
47
12/ 1
一个正常的业务事件流描述 1. 只书写“可观测”的 2. 使用主动语句 3. 句子必须以参与者或系统作为主语 4. 不要涉及界面细节 5. 分支和循环
47
32/ 1
32/55
正式型（详细型）-扩展5
5a 系统检测到和外部税金计算系统之间的通 信失败
5b顾客说他们符合打折条件 5c 顾客说他们帐上的存款为此次销售付款 6a 顾客说他们想付钱但没有带足够的现金
47
33/ 1
33/55
用例规约——精选推荐
学籍管理系统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、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
用户登录用例图用例规约：用例名称：登录用例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；若输入格式错误，则进入4.2。
其它事件流：无异常事件流：参与者动作系统响应4.1.1.1若未添加姓名4.1.2.1.1若未添加Email项4.2.1.1 若Email格式不正确4.2.2.1 若输入固定电话格式不正确4.1.1.2 系统提示“必须输入姓名”4.1.2.2系统提示“必填”4.2.1.2 系统显示“邮件格式不正确”4.2.2.2 系统提示“8位电话号码”4.2.3.1若输入手机格式不正确 4.2.3.2 系统提示“只能输入数字”后置条件：添加联系人成功，返回主界面修改联系人用例图用例规约：用例名称：修改联系人用例ID：IBM_ESHOP_002.3角色：普通用户用例说明：该用例主要实现的功能是用户实现对联系人信息的修改操作前置条件：进入主界面基本事件流：参与者动作系统响应1.选择想要修改的联系人，然后点击“修改”按钮3.用户对联系人姓名、性别、出生日期、Email、职务、固定电话、手机、住址、备注信息进行修改，点击“确定”按钮2.系统响应点击事件，跳转至“修改联系人信息”界面5．系统对用户的输入进行判断，若合法，则弹出对话框，提示“修改联系人成功”其它事件流：无异常事件流： 5.1姓名未输入，系统给出提示对话框“必须输入姓名”5.2 Email未输入，系统给出提示对话框“必填”后置条件：修改信息成功，返回主界面删除联系人用例图用例名称：删除联系人用例ID：IBM_ESHOP_002.4角色：普通用户用例说明：该用例主要功能是删除联系人,用例起始用户点击“删除”按钮前置条件：进入主界面基本事件流：参与者动作系统响应1.用户确定要的联系人，然后点击“删除”3.1.1若确定删除联系人，点击“确定”按钮；3.1．1用户点击返回按钮。
3.1.2点击“取消”按钮，取消删除操作。
2.系统弹出对话框，给出提示信息“是否删除”3.1.2进入“删除联系人成功界面”3.2系统返回主界面其它事件流：无异常事件流：暂无后置条件: 删除联系人成功查找联系人用例图用例规约：用例名称：查找联系人用例ID：IBM_ESHOP_002.4角色：普通用户用例说明：该用例主要功能是从列表中查看联系人信息,用例起始用户点击“查找”按钮前置条件：进入主界面基本事件流：参与者动作系统响应1.用户点击“查找”按钮3．用户可以根据选择分组名称，填写邮箱、职位、姓名、手机。
生日任一项对查找人进行查找，2.系统跳转至“查找联系人界面”4．系统查找数据库中的信息，若找到，则返回查找到的信息，若没有找到，什么都不返回。
其它事件流：无异常事件流：暂无后置条件: 查找联系人成功统计联系人用例图用例名称：统计联系人用例ID：IBM_ESHOP_002.4角色：普通用户用例说明：该用例功能是统计联系人,用例起始用户点击“统计”按钮前置条件：进入主界面基本事件流：参与者动作系统响应1.用户点击“统计”按钮3．用户可以在此页面查看每个组的人数2.系统跳转至“统计联系人界面”其它事件流：无异常事件流：暂无后置条件: 统计联系人成功统计联系人用例名称：统计联系人用例ID：IBM_ESHOP_002.4角色：普通用户用例说明：用例起始用户想统计联系人前置条件：打开进入联系人维护页面基本事件流：参与者动作系统响应1．用户在维护联系人界面，点击“统计”按钮。
3.点击某个统计项按钮，如统计联系人，平均年龄按钮等5．用户给出统计所学的数据，点击“统计”按钮7．用户点击“返回”按钮2.系统显示统计界面4．系统显示某统计项界面6．系统显示统计结果8．系统返回联系人维护界面其它事件流：无异常事件流：暂无提醒生日用例图用例规约：用例名称：统计联系人用例ID：IBM_ESHOP_002.4角色：普通用户用例说明：用例起始用户点击“生日统计”按钮前置条件：进入统计界面基本事件流：参与者动作系统响应1.用户点击“生日统计”按钮3．用户可以查看此页面每个月份的过生日人数2.系统跳转至“生日统计界面”其它事件流：无异常事件流：暂无发送邮件用例图用例名称：发送邮件用例ID：IBM_ESHOP_002.4角色：普通用户用例说明：该用例主要是实现对联系人邮件的发送,用例起始用户选择成员后，点击“发送Email”按钮前置条件：进入主界面基本事件流：参与者动作系统响应1.用户通过复选框勾选收件人3．用户点击“发送Email”按钮2.系统显示勾选结果4.进入邮件发送系统其它事件流：参与者动作系统动作2.1若没有勾选接收人 2.2系统给出提示“请选择收件人”异常事件流：暂无后置条件: 发送邮件成功查看联系人用例图用例规约：用例名称：查看联系人用例ID：IBM_ESHOP_002.4角色：普通用户用例说明：该用例主要实现查看联系人,用例起始用户点击联系人的“查看”按钮前置条件：进入主界面基本事件流：参与者动作系统响应1.用户点击联系人后的“查看”按钮3.点击返回界面2.系统跳转“好友信息列表”4.系统返回主界面其它事件流：无异常事件流：暂无后置条件成功查看联系人显示全部联系人用例图用例规约：用例名称：显示全部联系人用例ID：IBM_ESHOP_002.4角色：普通用户用例说明：本用例主要实现的功能是查看全部联系人,用例起始用户点击联系人的“查看”按钮前置条件：进入主界面基本事件流：参与者动作系统响应1.用户点击联系人后的“查看”按钮3.点击返回界面2.系统跳转“好友信息列表”4.系统返回主界面其它事件流：无异常事件流：暂无后置条件：显示全部联系人成功创建分组用例图用例规约：用例名称：创建分组用例ID：IBM_ESHOP_002.4角色：普通用户用例说明：该用例主要实现分组的创建,用例起始用户点击联系人的“管理分组”按钮前置条件：进入管理分组界面基本事件流：参与者动作系统响应1.用户进入管理分组页面,点击”创建分组”3.用户填写创建信息，包括分组名称、分组描述5．用户点击“提交”按钮。
2.系统跳转“创建分组页面”4.系统显示用户填写信息6．若成功，则返回主界面；不成功，则到6.1其它事件流：无异常事件流：参与者动作系统响应6.1若未添加分组名称 6.2系统提示“请填写分组名后置条件：系统显示新增分组成功修改分组用例图用例名称：修改分组用例ID：IBM_ESHOP_002.2角色：普通用户用例说明：该用例主要用来实现修改分组的功能,用例主要实现对分组信息的修改前置条件：进入管理分组界面基本事件流：参与者动作系统响应1.进入界面，用户点击“维护分组基本信息”按钮。
3.用户修改分组名称，分组描述5．用户点击“提交”按钮2.系统响应点击事件，进入“更新分组信息”界面4．系统显示修改内容6.系统保存修改信息。
其它事件流：无异常事件流：无后置条件：修改分组成功，返回主界面删除分组用例图用例名称：删除分组用例ID：IBM_ESHOP_002.2角色：普通用户用例说明：该用例主要实现用户组的删除,用例主要实现删除分组信息前置条件：进入管理分组界面基本事件流：参与者动作系统响应1.进入界面，用户点击“删除分组”按钮。
3.1点击“确定”按钮。
4.1点击“取消”2.系统响应点击事件，弹出对话框，提示用户是否删除3.2系统将分组中的信息从数据库中删除4.2系统取消用户操作其它事件流：无异常事件流：无后置条件：删除分组成功，返回主界面显示全部分组信息用例图用例规约：搜索添加联系人搜索添加联系人用例图用例名称：搜索添加联系人用例ID：IBM_ESHOP_002.2角色：普通用户用例说明：用例主要实现根据用户的选择把成员添加到某一分组前置条件：进入管理分组界面基本事件流：参与者动作系统响应1.进入界面，用户点击“维护组内联系人”按钮。
3.用户在文本框中输入联系人姓名信息5.用户点击“确定”按钮7.用户根据复选框选择加入的分组成员7.1若仅添加一个成员，则直接点击“添加”按钮7.2若添加多个成员，则选中后点击“批量添加”按钮2.系统响应点击事件，跳转至“搜索联系人添加界面”4.系统显示用户输入信息6．系统显示不在本组的联系人信息8.系统给出提示信息，显示“向分组添加联系人成功”其它事件流：无异常事件流：无后置条件：搜索成功，显示搜索的详细信息。
显示组内联系人用例图用例名称：显示组内联系人用例ID：IBM_ESHOP_002.2角色：普通用户用例说明：用例主要实现查看某一分组的组内联系人前置条件：进入管理分组界面基本事件流：参与者动作系统响应1.进入界面，用户点击“维护组内联系人”按钮。
3.用户查看该组内所有联系人成员的详细信息2.系统响应点击事件，跳转至“搜索添加联系人”界面其它事件流：无异常事件流：无后置条件：查看联系人详细信息成功删除组内联系人用例图用例名称：删除组内联系人用例ID：IBM_ESHOP_002.2角色：普通用户用例说明：用例主要实现对某一组内成员的删除操作前置条件：打开并进入管理分组界面基本事件流：参与者动作系统响应。