用例规约说明书-模版
用例规约说明书_模版
A1.其他事件流A1
在按“提交”按钮之前，负责人随时可以按“返回”按钮，文本框的任何修改内容都不会影响网站首页的公告
异常流程描述
[在达到执行者目标时，产生了违背执行者目标的流程处理。]
例如：UC001_网站公告发布
用例描述
[说明中应简要表达用例的作用和目的（即满足相关涉众的利益），一个段落即足以作此说明]
执行者（参与者）
[用例的触发者、操作人、系统或时间。]
前置条件
[用例的前置条件是执行用例之前必须存在的系统状态。]
后置条件
[用例的后置条件是用例执行完毕系统可能处于的一组状态。]
3．负责人可以在文本框上修改公告，也可以完全删除，重新写新的公告
4．负责人编辑完文本框，按“提交”按钮，首页公告就被修改
5．用例终止
备选流程描述
[描述用例执行过程中只在特定条件下才出现的流程]
No.1<备选流的触发条件>
<第一备选流>
[较复杂的备选流应单独说明。]
1.1.2<备选支流>
[如果能使表达更明确，备选流又可再分为多个支流。]
特殊要求
[描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。]
主要流程描述
[描述的是该用例最正常的一种场景，在基本流中系统执行一系列活动步骤来响应执行者提出的服务请求。]
例如：
1．负责人鼠标点击“修改公告”按钮
2．系统出现一个文本框，显示着原来的公告内容
其他事件流a1在按提交按钮之前负责人随时可以按返回按钮文本框的任何修改内容都丌会影响网站首页的公告异常流程描述在达到执行者目标时产生了违背执行者目标的流程处理
用例规约模板
用例规约模板
用例名称
项目唯一标识符
UC-IMSS-004
任务书章节
简要描述
用例目标简述：谁（主执行者）让系统干什么，系统让其他系统（辅助执行者）干什么，最后，系统输出了什么
参与者
主执行者：检测员
辅助执行者：XX信号IO、AD芯片、参数422芯片、XXX
涉众利益
涉众
利益
//该用例的上下游存在的涉众
从该用例获取的利益
前置条件
该用例开始前，系统需要满足的约束。
主流程
步骤
描述
//代表用例核心价值的路径
/、按照交互四部曲书写；
/、使用主动语句理清责任；
/、主语只能是主执行者或系统； /、使用核心域词语；
/、不要涉及交互设计的细节； /、不要写系统不能负责的事情
1
2
3
5
6
7
扩展流程
//对应流程中某个步骤中，系统要处理的意外和分支。
子流程
//对应主流程中多次重复的一组步骤集合。
后置条件
该用例结束后，系统需要满足的约束。
规则与约束
业务规则、数据约束、非功能需求/质量属性（可用性、可靠性、性能等）、设计约束
1、。
测试用例编写规范说明及模板
部门管理文档系列――*******公司测试用例编写标准及原则拟制日期审核日期批准日期修订历史记录目录1.引言 (5)1.1背景 (5)1.2目的 (5)1.3适用范围 (5)1.4缩写和术语 (5)2.测试用例 (5)2.1.概念 (5)2.2.用途 (6)2.3.设计依据 (6)2.4.编号规则 (6)2.5.用例内容 (6)2.6.用例设计方法 (7)2.6.1.等价类划分法 (7)2.6.2.边界值分析法 (8)2.6.3.错误推测法 (8)2.7.功能性测试方法 (8)2.7.1.输入非法数据 (8)2.7.2.输入默认值 (9)2.7.3.输入使缓冲区溢出的数据 (9)2.7.4.输出不符合业务规则的无效输出 (9)2.7.5.数据结构溢出 (9)2.7.6.文件内容受损 (9)2.8.软件环境兼容性测试 (10)2.8.1.与操作系统的兼容性 (10)3.用例设计步骤 (11)3.1.用例评审 (11)3.1.1.评审原因 (11)3.1.2.评审内容 (11)3.1.3.评审过程 (12)3.1.4.评审人员 (12)3.1.5.评审方式 (12)3.1.6.结束标准 (12)4.用例规范 (12)4.1.编写用例规范 (12)4.2.编写用例标准 (13)4.3.用例实例说明 (13)4.3.1.字段说明 (13)4.3.2.用例说明 (14)4.4.用例级别划分 (15)5.用例的维护 (15)6.风险分析 (16)7.测试用例模板 (16)1.引言1.1 背景为保证测试用例对需求的覆盖率，即对一个系统从整体功能到单个功能，都尽可能的高的覆盖。
而单个功能点主要强调的是不同的输入及其组合所带来的各种输入动作，系统是否都做了处理；测试用例设计首先要明确该系统存在多少功能点，要通过各种常用的测试方法来保证用例的完整性，然后再对各功能点的边界范围进行考虑。
所以要保证测试用例的设计按照一种合理的结构组织进行，这样才能够更有效的保证系统所有功能点的覆盖率。
业务用例规约
<公司名称><项目名称>业务用例规约：<业务用例名称>版本<1.0> [注：以下提供的模板用于 Rational Unified Process。
其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。
按此样式输入的段落将被自动设置为普通样式（样式=Body Text）。
][要定制 Microsoft Word 中的自动字段（选中时显示灰色背景），请选择 File>Properties，然后将Title、Subject 和 Company 等字段替换为此文档的相应信息。
关闭该对话框后，通过选择Edit>Select All（或 Ctrl-A）并按 F9，或只是在字段上单击并按 F9，可以在整个文档中更新自动字段。
对于页眉和页脚，这一操作必须单独进行。
按Alt-F9，将在显示字段名称和字段内容之间切换。
有关字段处理的详细信息，请参见 Word 帮助。
][注：如果您没有使用 Requisite Pro，就应使用此文档模板来记录实际的业务用例，其中包括该业务用例的工作流程、特殊需求和性能目标。
此文件应链接到 Rose 模型中的相应业务用例。
如果您在使用 SoDA，则可以将此文档用作对业务用例报告的输入，该报告将把此文档的内容与Rose 中的用例图结合在一起。
]修订历史记录目录1. 简介 41.1 目的 41.2 范围 41.3 定义、首字母缩写词和缩略语 41.4 参考资料 41.5 概述 42. 业务用例名称 42.1 简要说明 43. 目标 44. 性能目标 44.1<性能目标的名称> 45. 工作流程 45.1 基本工作流程 45.1.1<工作流程步骤的名称> 45.2 备选工作流程 55.2.1<工作流程步骤的名称> 56. 类别 57. 风险 58. 可能性 59. 流程拥有者 510. 特殊需求 510.1<特殊需求的名称> 511. 扩展点 511.1<扩展点的名称> 5业务用例规约：<业务用例名称>简介[业务用例规约的简介应提供整个文档的概述。
用例技术-用例规约
用例技术-用例规约
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. 扩展点。
用例规约示例
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.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.这样，学生就可以通过删除或者添加新课程来修改所选的课程。
学生从可选课程列表中选择要添加的课程。
学生也可以从目前的课程表中选择要删除的课程。
用例规约
网上书店系统用例规约姓名：廖杰学号：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)
班级：测绘工程学号：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。
软件工程-用例规约【范本模板】
1、登陆系统
系统中的所有参与者均可以使用本用例登陆系统，要求输入合法的用户名和密码。
登录系统用例规约
查询菜品信息的参与者是数据管理人员、顾客，用于查看酒店所有菜品的详细信息.
查询菜品用例规约
修改菜品信息的参与者是数据管理人员，用于修改酒店所有菜品的详细信息.
修改菜品用例规约
修改菜品信息的参与者是数据管理人员，用于增加酒店菜品的详细信息。
增加菜品用例规约
删除菜品信息的参与者是数据管理人员，用于删除酒店菜品的详细信息。
删除菜品用例规约
查询员工信息的参与者是数据管理人员，用于查看酒店所有员工的详细信息。
查询员工用例规约
修改员工信息的参与者是数据管理人员，用于修改酒店所有员工的详细信息。
修改员工用例规约
增加员工信息的参与者是数据管理人员，用于增加酒店所有员工的详细信息。
增加员工用例规约
删除员工信息的参与者是数据管理人员，用于删除酒店员工的详细信息。
删除员工用例规约
10、查询vip客户信息
查询vip客户信息的参与者是数据管理人员，用于查看酒店所有vip客户的详细信息。
查询vip客户信息用例规约
修改vip客户信息的参与者是数据管理人员，用于修改酒店所有vip客户的详细信息。
修改vip客户信息用例规约
增加vip客户信息的参与者是数据管理人员，用于增加酒店vip客户。
修改vip客户信息用例规约
删除vip客户信息的参与者是数据管理人员，用于删除酒店vip客户的详细信息。
删除vip客户信息用例规约。
用例规约模板
游泳馆管理系统用例规约：1.用例名称1.1简要说明指的是仓库保管员根据已经经过验收员验收合格的商品，进行商品正式入库的操作，入库之后将增加相应商品的库存数量。
2.事件流2.1基本流1.仓库保管岗登陆进入‘商品入库’页面。
2.系统根据系统当前时间生成开票日期和临时单据编号（单据编号＝临时标记＋系统日期＋2位顺序号。
例： ls2005101001）。
3.用户点击‘选择待入库单据’按钮。
4.系统弹出‘待入库单据选择’页面。
5.系统查询出已经经过验收员验收的单据信息，信息包括单据编号、业务员、进货单位、税号、地址、扣率等单据概要信息。
6.用户输入业务员、进货单位等查询条件。
7.系统查询出满足条件的采购开票单据列表。
8.用户选择需要进行入库操作的具体单据。
9.系统根据所选的单据的概要信息列出已验收合格的具体商品明细信息（商品条码、商品名、产地、生产厂家、单价和数量等）。
10.用户点击‘确认’按钮。
11.系统根据用户所选单据的信息填入入库单据的开票单据编号、业务员、进货单位、税号、地址、扣率等单据概要信息。
以及商品明细信息，商品条码、商品名称、规格、保质期、生产厂商、供应商、单价和数量等。
12.用户选择商品存放货位。
点击‘保存’按钮。
13.系统生成单据正式编号（单据编号＝单据类别＋年份＋6位顺序号。
例：rh2005000001）。
系统保存单据信息。
14.用户点击‘入库’按钮。
15.系统增加仓库库存记录(序列号、单据编号、商品编码、发生类别（0为入库类单据，1为出库类单据）、入库数量、发生日期、发生后数量)。
修改实时库存数为发生后数量。
2.2备选流2.2.1保管员对入库验收单据有异议时1.当基本流5发生后，保管员对已验收的单据有异议时，保管员选择需要入库的单据。
填写备注栏重新验收理由。
2.保管员点击‘保存’按钮保存意见信息，并通知验收员处理有异议商品。
3.特殊需求无4.前置条件采购验收通知单；5.后置条件生成入库单；6.扩展点无。
用例规约
被包含的用例
无
被扩展的用例
无
修改历史记录
无
用例图1-1
用例描述
删除线路信息，当线路管理员想要删除线路信息时可以将已经存在的线路信息删除。
参与者
线路管理员
优先级
1
前置条件
线路管理员登陆到系统
后置条件
将数据库的线路信息删除
基本操作流程
1.用户登陆系统
2.删除线路信息按钮
可选操作流程
X1.3.1线路信息不存在
可选操作流程
D1.1.1导游信息已经存在
D2.1.2提示信息已存在
被泛化的用例
无
被包含的用例
无
被扩展的用例
无
修改历史记录
无
用例描述
查看线路信息，当用户想了解有那些线路信息的时候可以通过系统来查看所有的线路信息。
参与者
游客，导游，线路管理员
优先级
1
前置条件
登陆到系统
后置条件
从数据库中调出线路信息，将信息显示在用户的窗口中。
基本操作流程
1.用户登陆系统
2.点击查看信息按钮
可选操作流程
无
被泛化的用例
无
被包含的用例
无
被扩展的用例
X2.3.2提示信息不存在，请确认！
被泛化的用例
无
被包含的用例
无
被扩展的用例
无
修改历史记录
无
用例图1-3
用例描述
查看导游信息，当导游想要添加导游信息时可以添加新的导游信息到数据库中。
参与者
导游
优先级
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名用户对其的同一时刻的访问。
模板-用例规约
密级：内部
缤纷视频网项目
用例规约
二零一三年七月
关于本文档
项目名称
×××项目
主 题
用例规约
说 明
该项目用于网上购物
适用对象
该项目适用于代替以往的购物方式，改为网上购买食品的用户。
修订历史
版本
章节
类型
日期
作者
说明
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.1.2修改会员信息
用例规约：
用例名称：
修改会员信息
用例ID：
1.2
涉众
会员
角色：
会员
用例说明：
会员进行注册信息的修改
前置条件：
已经注册为会员，并登录到系统前台
后置条件：
注册资料修改成功
基本事件流：
登录到前台页面，输入账号和密码，修改注册信息，成功
替代事件流：
无
异常事件流：
无
业务规则：
无
非功能性需求：
要保证数据的安全性和可靠性，提高系统的性能。
其他：
无
2.2.3管理订单
用例规约：
用例名称：
管理订单
用例ID：
1.8
涉众
订单管理员
角色：
订单管理员
用例说明：
对订单进行查看，受理，结单，删除
前置条件：
输入账号和密码，登录到系统后台
后置条件：
对订单进行查看，受理，结单，删除成功.
用例规约：
用例名称：
注册会员
用例ID：
1.1
涉众
普通用户。
角色：
普通用户。
用例说明：
对用户名进行检测，通过后成为会员，即卖家。
前置条件：
登录到系统前台。
后置条件：
成为会员。
基本事件流：
登录到前台页面，输入注册信息，成为会员。
替代事件流：
无。
异常事件流：
系统提示：注册失败。
业务规则：
用户名、密码、会员地址不能为空。
前置条件：
输入账号和密码，登录到系统后台
后置条件：
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
备选流程描述
［描述用例执行过程中只在特定条件下才出现的流程］
No.1＜备选流的触发条件＞
＜第一备选流＞
［较复杂的备选流应单独说明。］
1.1.2＜备选支流＞
［如果能使表达更明确，备选流又可再分为多个支流。］
例如：
A1.其他事件流A1
在按“提交”Leabharlann 钮之前，负责人随时可以按“返回”按钮，文本框的任何修改内容 都不会影响网站首页的公告
［用例的触发者、操作人、系统或时间。］
前置条件
［用例的前置条件是执行用例之前必须存在的系统状态。］
后置条件
［用例的后置条件是用例执行完毕系统可能处于的一组状态。］
特殊要求
［描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操 作系统、开发工具等）O］
主要流程描述
［描述的是该用例最正常的一种场景，在基本流中系统执行一系列活动步骤来响应执行者提出的服务请求。］例如：
1.负责人鼠标点击“修改公告"按钮
2.系统出现一个文本框，显示着原来的公告内容
3.负责人可以在文本框上修改公告，也可以完全删除，重新写新的公告
4.负责人编辑完文本框，按“提交"按钮，首页公告就被修改
异常流程描述
［在达到执行者目标时，产生了违背执行者目标的流程处理。］
XX
修订历史记录
日期
版本
说明
作者
＜日/月/年＞
<x.x>
＜详细信息＞
＜姓名＞
用例图:
<cUse
用例名称
［动词+名词的简短用例名。］
在实际的项目中可加“编号”前缀以管理用例。 例如：UC001网站公告发布
用例描述
［说明中应简要表达用例的作用和目的（即满足相关涉众的利益），一个段落即足以作此说明］
执行者（参与者）