用例描述的写法
用例说明模板
角色
级别
概要
主执行者
登陆成功的用户鼠标点击角色删除
前置条件
角色管理
后置条件
无
触发事件
用户鼠标点击角色删除
描述
步骤
活动
1
用户鼠标点击选择菜单上的角色删除选项
2
3
扩展
步骤
分支动作
1
2
用例#
角色修改
使用语境
用户在角色管理界面下鼠标点击选择角色修改
范围
角色
级别
概要
主执行者
登陆成功的用户鼠标点击角色修改
前置条件
2
3
扩展
步骤
分支动作
1
2
用例#
用户增加
使用语境
用户在用户管理界面鼠标点击用户增加
范围
用户,角色
级别
用户目标
主执行者
用户在用户管理界面鼠标点击用户增加
前置条件
用户管理
后置条件
无
触发事件
用户鼠标点击用户增加
描述
步骤
活动
1
用户鼠标点击用户管理界面上的用户增加选项
2
3
扩展
步骤
分支动作
1
2
用例#
用户删除
使用语境
用户在用户管理界面鼠标点击用户删除
范围
用户,角色
级别
用户目标
主执行者
用户在用户管理界面鼠标点击用户删除
前置条件
用户管理
后置条件
无
触发事件
用户鼠标点击用户删除
描述
步骤
活动
1
用户鼠标点击用户管理界面上的用户删除选项
2
3
扩展
图书管理系统用例描述文档
删除图书新增图书用例名称：登录用例描述：本系统需要参与者输入帐号和密码进行系统登陆，该用例页面是系统起始页面。
用户帐号和密码是系统默认已经分配的。
参与者：图书馆工作人员。
前置条件：无基本路径：1.输入帐号，密码2.点击“进入系统”3.验证用户权限，进入主界面备选流程：1.点击“重新填写”，实现重填帐号密码功能。
2.输入帐号或密码不正确，重新登陆。
3.进入基本路径1用例名称：注销用例描述：图书管理员离开系统参与者：图书馆工作人员。
前置条件：已经进入系统基本路径：1.点击“注销”2.提示“确认退出”3.点击确认，退出系统备选流程：1.点击取消不退出系统用例名称：借阅管理用例描述：此用例用来供用户完成借阅管理工作，包括两个扩展用例——“新办借阅证”和“补办借阅证”。
参与者：图书馆工作人员。
前置条件：图书馆工作人员已经登录用例名称：新办借阅证用例描述：图书馆工作人员输入学生信息进行借阅证办理。
参与者：图书馆工作人员。
前置条件：图书馆工作人员点击“新办借阅证”基本路径：1.输入学生信息（学号，姓名，专业，班级，性别）2.点击“提交”3.显示添加的借阅证信息（借阅证编号，学号，姓名，专业，班级，性别）备选流程：1.点击“重新填写”，实现重填学生信息功能。
2.进入基本路径1用例名称：补办借阅证用例描述：图书馆工作人员输入学生信息进行借阅证补办。
参与者：图书馆工作人员。
前置条件：图书馆工作人员点击“补办借阅证”基本路径：1.输入学号2.点击“查询”3.显示该学生遗失的借阅证信息（借阅证编号，学号，姓名，专业，班级，性别）4.点击“补办”5.显示该学生新借阅证信息（借阅证编号，学号，姓名，专业，班级，性别）6.进入备选流程B备选流程：A：1点击“重新填写”，实现重填学号。
2进入基本路径1B：如果学生有借阅图书未归还，显示当前该学生借阅情况（书名,ISBN，借阅时间，应归还时间）用例名称：图书借阅用例描述：图书馆工作人员输入借阅证编号和图书编号来完成图书借阅。
用例描述文档模板
2. 必须要有的项目：时间＋地点＋专家＋主题
3. 邮件格式：
您好！[讲座时间]将举办[专家]主讲的[主题]讲座，
特殊需求（Special Requirement）
描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（指出所使用的操作系统、开发工具等）。
用例执行完毕后系Βιβλιοθήκη 可能处于的一组状态。涉众利益(Stakeholder)
说明涉众及涉众关心和担心的事情。如下：
1.开发人员-担心收到太多垃圾邮件
2.组织工作人员-希望操作方便，尽量减少手工劳动
用例场景 (Use-Case Scenario)
包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。
事件流 (Flow of Event)
基本流程（Base Flow）
1. 组织工作人员输入讲座信息，请求发布
2. 系统验证讲座信息充分
3. 系统保存讲座信息，生成讲座网页、讲座邮件
4. 系统发布网页到公司网站
5. 系统请求邮件列表系统发送邮件
6. 系统记录发布情况
7. 系统显示讲座消息已经发布
扩展流程（Extend Flow）
用例编号(Number)：UC_1_1用例名称(Name)：XXXXX
简要说明 (Brief Description)
简要介绍该用例的作用和目的。
执行者(Actors)
说明主要执行者和辅助执行者。
前置条件(Pre-Condition)
执行用例之前系统必须所处的状态。
后置条件(Post-Condition)
如：*1-7应在10秒之内
图书管理系统—用例描述
A1：读者无效
4. 管理员输入待借阅的图书条码号，检查图书有效性
A2：图书无效
5．系统登记一条新的借书信息
6．系统检查读者预定信息
A3:有预定
7．用例结束
其他事件流：
A1:读者无效
(1).系统显示读者无效的提示信息
(2).返回主事件流第3步
A2:
特殊需求：使用条码扫描仪和图书条码，预约一本书时间不超过30秒
(1). 系统显示图书无效提示信息
(2). 返回主事件流第4步
A3:有预定
(1). 系统提示预定信息，并取消预定
(2). 返回主事件流第7步
后置条件：系统成功写入一条借书信息，读者当前的借书数量加1
扩展点：
特殊需求：支持使用IC卡阅读器，输入读者证号，使用条码扫描仪和图书条码，借一本书时间不超过30秒
4.剔除新书信息
5.系统登记剔除一条旧书信息
6.用例结束
其他事件流：
A1:旧书条码无效
(1).提示新书条码无效
(2).返回主事件流第3步
后置条件：系统成功写入一条剔除旧书信息，当前的图书数量减1
特殊需求：支持使用条码扫描仪输入图书条码，剔除一本书时间不超过30秒
用例名称：统计月借阅情况
描述：馆长使用图书查询用例完成统计月借阅情况的活动
用例名称：剔除旧书
描述：图书管理员使用办理预定业务用例完成图书管理员剔除旧书活动
标识符:uc7
优先级：B(中)
角色:图书管理员
前置条件：图书馆员已成功登录系统并具有剔除旧书的权限
主事件流:
1.管理员选择“剔除旧书”选项，用例开始
2.打开剔除旧书窗体
用例描述模板内容
用例描述模板内容
以下是 9 条用例描述模板内容：
1. 嘿，你知道不，当你要描述一件事情的时候，就像讲故事一样！比如说，“我今天出去买菜，哇，那菜市场人多得像蚂蚁开会！”看到没，就这样简单直接，把事情说明白了。
2. 哎呀呀，咱就说如果你要写一个使用某个工具的用例，可以这样呀，“我拿起那把剪刀，就跟拿起了我的秘密武器似的，喀嚓喀嚓就把纸剪开啦！”这多生动形象啊。
3. 哇塞，要描述一个人的行为时，可以这么说呀，“他吃饭的样子，简直就像一头饿了好几天的狼！”这不是很容易让人懂嘛。
4. 嘿，当你写一个流程的时候，像这样，“我先打开冰箱门，然后像在找宝藏似的找我想吃的东西。
”是不是很清楚呢？
5. 哟呵，比如说要描述一个场景，“那个房间暗得跟晚上没开灯一样！”这样一说，大家一下子就有画面感了呀。
6. 你想想看啊，要是描述一个人的心情，“我当时开心得就像中了彩票一样！”简洁明了还有感觉。
7. 哇哦，像描述一个动作，“她跳舞的姿势，就像蝴蝶在花丛中飞舞！”是不是很妙呀。
8. 哎呀，当你要描述一个现象的时候，“那雨下得跟倒水似的！”这样多形象呀。
9. 好啦，总之呢，用例描述就是要让别人一听就懂，就像我举的这些例子一样，简单又有趣，大家肯定都喜欢呀！。
图书管理系统用例描述
5c.无法借书
5c1.系统显示读者有超期未还得图书；
5c2.读者归还未还图书并交罚款；
5c3.可以借书。
补充说明：
用例编号：005
用例名称：读者归还图书
用例描述：读者到图书馆归还所借阅的图书
参与者：读者
前置条件：图书馆正常开放、读者携带图书借阅证及所需还的书。
后置条件：如果归还了图书，下次可以正常借书。
1.搜集旧书和新书的信息
1.对新书贴条形码；；
2.把旧书下架
3.把新书上架；
扩展点：
变异点：
2a.找不到旧书
2a1.查看图书是否在被借中；
2a2.等归还后再进行下架。
补充说明：
用例编号：008
用例名称：处理借书
用例描述：在读者借阅图书时，处理读者的借书请求
参与者：图书管理员
前置条件：图书馆开放、图书管理系统正常运行时间
6.图书管理员允许读者借阅图书。
7.系统添加借阅信息。
扩展点：
变异点：
2a.读者查阅的图书不存在
2a1.读者离开图书馆，或读者搜索其他的图书信息；
5a.无法借书
5a1.系统弹出读者的图书实际借阅的数量超过图书额定的借阅数量
5a2.归还部分图书或下次再借。
5b.无法借书
5b1.系统显示图书证与读者本人信息不符；
2.读者输入需要注册的用户名和密码；
3.读者将注册信息进行提交；
4.系统对用户提交的用户名和密码进行有效性检查；
5.系统显示用户是否注册成功
扩展点：
变异点：
4a.读者输入要注册的用户名错误
4a1.系统弹出的用户名错误或者已被注册；
4a2.读者离开或者重新输入用户名。
系统用例描述
瑞天图书管理系统用例描述一、图书借阅该用例提供了用户借阅图书时管理员更新图书信息以及日志、录借阅信息、创建和修改借阅者账户以及信息等1、用例图如下：其他用户（from图书管理系统参与）更改借阅日志2、用例描述：用例名称：图书借阅简要说明：图书管理员输入读者编号和图书编号来完成图书借阅参与者：图书管理员前置条件：读者出示的借阅证必须是有效的借阅证学生（from图书管理系统参与.）创建新的借阅者帐户a, 1修改借阅者的帐户信息管理员（from图书管理系统参与）删除已存在的借阅者帐户（已还书）记录图书数量与价格记录图书流水编号后置条件：显示读者的全部借阅信息假设条件：图书管理员已经成功登录图书管理系统基本操作流程：(1)图书管理员输入借阅证信息(2)系统检查读者是否有超期的借阅信息和读者的借书数量是否已经达到借书限额(4)图书管理员输入要借阅的图书信息(5)系统将读者的借阅信息保存到数据库中可选操作流程：读者有超期的借阅信息，或者读者的借书数量已经达到借书限额，系统显示不能借阅图书的信息，图书管理员进行超期处理。
二、归还图书1、用例图如下:2、用例描述：用例名称：归还图书简要说明：图书管理员收到要归还的图书，进行还书操作 参与者：图书管理员、学生、其他用户 前置条件：无后置条件：显示读者的全部借阅信息假设条件：图书管理员已经成功登录图书管理系统 基本操作流程：(1) 图书管理员输入读者要归还的图书信息 (2) 系统检索与该图书相关的借阅者信息 (3) 系统检查该借阅者是否有超期的借阅信息 (4) 系统将借阅者的还书信息保存到数据库中学生(from图书管理系统参与者删除借阅记录罚款处理(书籍丢失)更改图书状态判断是否超出期限管理员图书管理系统参与者(from)(from)接受罚款登录其他用户图书管理系统参与者(5)系统将该图书的状态改变为可借阅状态可选操作流程：读者归还图书，图书管理员查看是否超出期限，并进行相应处罚，并且图书管理员将借阅信息删除。
100704112 用例描述
用例描述一、客户用例描述：参与者：客户用例描述：客户将汽车送至该汽车修理企业进行检修，检修完成后取车。
前置条件：前台服务人员对该车辆进行登记并安排机械工程师来修理。
后置条件：完成车辆检修，客户取车并拿取发票。
事件流：1.基本流1.1客户将汽车送至该汽车修理企业进行检修；1.2前台服务人员对该车辆进行登记；1.3修理部经理安排机械工程师修理此车；1.4修理完成，客户取车。
2. 备选流2.1若修理完成后达不到客户要求，重新修理。
二、前台服务人员用例描述：参与者：前台服务人员用例描述：记录检修车辆与客户信息，检修完成后开具发票。
前置条件：客户将汽车送至该汽车修理企业进行检修。
后置条件：完成车辆检修，为客户开具发票。
事件流：1.基本流1.1客户将汽车送至该汽车修理企业进行检修；1.2前台服务人员对该车辆及客户信息进行登记，记录客户检修需求；1.3修理部经理安排机械工程师修理此车；1.4修理完成，客户取车，开具发票。
三、修理部经理用例描述：参与者：修理部经理用例描述：对车辆进行初步检查，并安排机械工程师进行修理。
前置条件：客户及车辆信息正确登记，经过初步检查后交于机械工程师修理。
后置条件：安排并确认检修完成。
事件流：1.基本流1.1对车辆进行初步检查；1.2制定检修内容和检修时间；1.3安排机械工程师修理此车；1.4确认修理完成。
2. 备选流2.1若修理完成后达不到客户要求，重新制定一个新的安排工作。
四、机械工程师用例描述：参与者：机械工程师用例描述：修理部经理安排好机械工程师，机械工程师按要求进行检修。
前置条件：经过修理部经理确认后，完成修理工作。
后置条件：若达不到要求，继续检修，直到完成车辆检修。
事件流：1.基本流1.1修理部经理安排好机械工程师修理此车；1.2在修理过程中，若发现问题，上报修理部经理；1.3重新制定工作计划并继续修理；1.4完成检修任务后，负责完成检修报告。
2. 备选流2.1在修理过程中发现问题，向修理部经理提出才可继续修理。
用例及用例描述
用例图用例描述用例：留言ID：1简单描述：用户在本网站留言板上进行留言（咨询）主参与者：user副参与者：数据库前置条件：本网站被打开且用户有留言需要主流：i)用户打开本网站ii)进入留言板页面iii)在留言板对话框内发布信息iv)点击确定，完成留言后置条件：用户留言成功附加流：数据库添加失败时提醒错误原因并询问是否重新留言用例：搜索ID：2简单描述：在本网站进行所需信息的搜索主参与者：user副参与者：数据库前置条件：本网站被打开且用户有搜索信息的需要主流：i)用户打开本网站ii)在网站搜索引擎中键入搜索条件或直接按类别搜索iii)点击确定，完成搜索iv)得到预期信息，用户可以对所得信息进行浏览后置条件：搜索完成并且用户得到预期信息附加流：搜索数据库无结果，提示原因并询问是否重新搜索用例：回复ID：3简单描述：客服对用户的留言板提问或留言进行回复主参与者：客服副参与者：数据库前置条件：有用户在留言板上提问或留言主流：i)客服登录网站后台ii)进入留言板回复页面iii)点击回复，在出现的对话框内键入回复内容iv)点击确定，完成回复后置条件：客服回复信息成功附加流：数据库添加失败时提醒错误原因并询问是否重新回复ID：4简单描述：普通管理员将最新资讯信息添加到网站数据库中主参与者：普通管理员副参与者：数据库前置条件：网站有最新的咨询信息需要添加主流：i)普通管理员登录网站后台页面ii)将最新资讯信息录入到数据库中iii)点击确定完成录入后保存所作修改iv)修改成功后关闭后台页面后置条件：最新资讯信息成功添加到数据库中附加流：添加信息出错时数据库提示出错信息用例：删除网站信息ID：5简单描述：普通管理员将废旧资讯信息从网站数据库中删除主参与者：普通管理员副参与者：数据库前置条件：网站有废旧的咨询信息需要删除主流：i)普通管理员登录网站后台页面ii)查询废旧的资讯信息iii)将废旧资讯信息从数据库中删除iv)点击确定完成删除后保存所作修改v)删除成功后关闭后台页面后置条件：废旧资讯信息成功从数据库中删除附加流：删除信息出错时数据库提示出错信息ID：6简单描述：普通管理员对网站数据库中数据进行修改主参与者：普通管理员副参与者：数据库前置条件：网站有待修改的数据信息需要修改主流：i)普通管理员登录网站后台页面ii)查询待修改的资讯信息iii)对待修改资讯信息进行修改iv)点击确定完成修改后保存所作修改v)修改成功后关闭后台页面后置条件：待修改资讯信息在数据库中修改成功附加流：修改信息出错时数据库提示出错信息用例：查询网站信息ID：7简单描述：对数据库中的网站信息通过不同条件进行搜索查询主参与者：普通管理员副参与者：数据库前置条件：已确定要查询信息的关键字主流：i)普通管理员登录网站后台页面ii)根据搜索关键字对信息进行搜索iii)搜索成功，显示查询到的语句后置条件：信息查询成功，得到所查信息详情附加流：搜索失败，未能得到要查询信息并提示出错信息用例：删除留言ID：8简单描述：对数据库中的留言进行删除管理主参与者：普通管理员副参与者：数据库前置条件：存在不合法留言信息，普通管理员需要对其进行删除操作主流：i)普通管理员登录网站后台页面ii)在数据库中查询到不合法的留言信息iii)对不合法留言信息进行删除操作iv)点击确定完成操作后进行保存v)保存后关闭后台页面后置条件：不合法留言信息得以成功删除附加流：删除留言信息失败并提示出错信息用例：查询留言ID：9简单描述：对数据库中的留言信息进行查询检索主参与者：普通管理员副参与者：数据库前置条件：确定要检索留言信息的关键字主流：i)普通管理员登录网站后台页面ii)根据不同的检索条件对留言信息进行查询iii)成功检索到所要查询留言信息并显示信息详情后置条件：所要查询留言信息得以成功检索附加流：未能查询到所要查询的留言信息并提示出错信息用例：登录ID：10简单描述：网站的超级管理员、普通管理员和客服登录进本网站后台主参与者：超级管理员、普通管理员，客服副参与者：无前置条件：各种管理员需要进入后台进行各种信息维护主流：i)进入网站后台管理页面ii)键入预先分配好的帐号和密码iii)点击登录，进入后台iv)登录成功后置条件：各种管理员登录后台成功附加流：登录出错时提示出错信息用例：创建管理员用户ID：11简单描述：超级管理员创建一个新的管理员用户（普通管理员、客服）主参与者：超级管理员副参与者：数据库前置条件：网站需要新建一个管理员用户主流：i)超级管理员登录网站后台页面ii)创建一个新的管理员用户（帐号，密码）iii)点击确定完成新管理员用户的创建，数据库进行保存iv)创建成功后关闭后台页面后置条件：网站得到一个新的普通管理员用户或客服用户附加流：创建失败时数据库提示出错信息用例：删除管理员用户ID：12简单描述：超级管理员删除一个管理员用户（普通管理员、客服）主参与者：超级管理员副参与者：数据库前置条件：网站需要删除一个管理员用户主流：i)超级管理员登录网站后台页面ii)删除一个管理员用户（帐号，密码）iii)点击确定完成管理员用户的删除，数据库进行保存iv)删除成功后关闭后台页面后置条件：删除一个普通管理员用户或客服用户成功附加流：删除失败时数据库提示出错信息用例：设置管理员权限ID：13简单描述：超级管理员对网站中的管理员设置权限主参与者：超级管理员副参与者：数据库，普通管理员，客服前置条件：需要对网站内的普通管理员和客服进行区分，对他们分别设置不同的权限主流：i)超级管理员登录网站后台页面ii)对普通管理员设置权限，令其能对网站信息进行增、删、改、查以及对游客留言信息（不合法）进行查询和删除对客服设置权限，令其只能对游客的留言或提问信息进行回复iii)点击确定完成权限设置，数据库进行保存iv)设置成功后关闭后台页面后置条件：普通管理员或客服的权限设置成功附加流：权限设置失败时数据库提示出错信息用例：查看管理员用户信息ID：14简单描述：超级管理员对普通管理员用户或客服用户的信息进行查看主参与者：超级管理员副参与者：数据库前置条件：需要查看管理员用户信息主流：i)超级管理员登录网站后台页面ii)对指定普通管理员用户或客服用户的信息进行查询iii)显示指定管理员用户信息后置条件：管理员信息查询成功，得到所查信息详情附加流：查询信息失败时数据库提示出错信息。
学生管理系统的用例描述
学生管理系统的用例描述用例编号：001用例名：系统管理员的登录用例描述：系统管理员完成学生信息管理系统登录的整个过程。
参与者：系统管理员老师学生前置条件：系统运行正常。
后置条件：如果管理员登录成功，可以对学生的基本信息进行进行管理。
包括：录入，查询，修改，删除。
如果教师登陆成功，可以对学生的成绩进行管理。
如果学生登录成功，可以查看个人的基本信息。
如果登录未成功，则不能进行如上操作。
基本路径：1，系统管理员，学生，老师输入用户和密码。
2，然后系统管理员，学生，老师提交输入的信息。
3，系统对系统管理员，学生和老师的用户和密码信息进行有效的检查。
4，检查通过，则返回带用户登录界面。
扩展点：3a:密码输入错误3a1:系统弹出输入错误的警告信息。
3a2:系统管理员，学生和老师离开或重新输入密码。
变异点：无补充说明：无用例编号：002用例名：查询学生的基本信息用例描述：完成系统管理员对学生的基本信息查询的完整过程。
参与者：系统管理员前置条件：登录成功后置条件：系统给出学生的基本信息。
系统管理员可以查询操作。
基本路径：1. 系统管理员，进入查询学生基本信息界面，发送查询学生基本信息的请求。
2.界面Form向控制对象Control请求学生的基本信息，控制对象到数据库查询学生的基本信息。
3.查询学生基本信息界面对象从控制对象中取得所查询得到的学生基本信息Course。
并返回到查询界面上显示所有的学生基本信息。
4. 系统管理员查询学生的基本信息。
扩展点：4a:查询学生基本信息失败。
4a1: 系统弹出查询学生信息失败的警告信息。
4a2: 系统管理员离开或重新查询学生的基本信息。
变异点：无补充说明：无用例编号：003用例名：修改学生的基本信息用例描述：完成系统管理员对学生的基本信息修改的完整过程。
参与者：系统管理员前置条件：登录成功，数据库中存在这个学生的记录后置条件：系统给出学生的基本信息。
系统管理员可以进行修改操作。
用例描述的写法
这里用我开发的一个家教网站来简单的分析用例图的画法和用例描述的写法。
这个网站我用UML完整的分析一下，以下我提取了用例图和用例描述的部分。
这个家教网站分为前台客户系统和后台管理系统。
前台客户系统的用例图如下：
后台管理系统用例图如下：
对于用例描述，篇幅有限，我在这里只列了后台管理系统中的网站公告发布这个用例的描述。
如下：
用例名称：网站公告发布
用例标识号：101
参与者：负责人
（注：专业文档是经验性极强的领域，无法思考和涵盖全面，素材和资料部分来自网络，供参考。
可复制、编制，期待你的好评与关注）。
用例文字描述示例
2a1a1 系统跳过动作3，执行动作4。
异常过程描述
业务规则
2a1a 最大次数为3
可靠性需求
误报率小于2%，漏报率小于1%。
补充说明
2. 如果不正常，系统启动警报器，拨报警电话号码。
3. 报警电话接通后，系统播出语音，报告异常事件发生的时间、位置、类别和事件内容。
）
分支过程描述
2a. 报警电话无人接听
2a1 系统按照重拨延迟反复拨号，直至电话接通，再执行动作3。
嵌套的扩展交互动作
1.1.1
用例名称
传感器监测
实现名称
业务目标
接收并判别来自传感器的数据是否正常，一旦发现异常即报警。
执行者
各类传感器，警报器，报警电话，显示器。
前置条件
系统处于“监控”状态。
后置条件
如果已发现异常，系统处于“报警”状态；否则系统处于正常的“监测”状态。
主过程描述
1. 传感器向系统上报其监测数据，系统判别监测数据是否正常。
用例描述(1)
1 用例名称：登录描述：车主、管理员和老板用来进入系统。
前置条件：无部署约束：必须可以让车主、管理员、老板从公司客户端、行程中的任何一台计算机登录，并可以通过客户端防火墙进入系统。
正常事件流：（1）车主、管理员或老板输入用户名和密码。
（2）系统验证姓名和密码、（3）系统判断是否第一次登录，如果是则提示更改密码。
可选事件流：验证错误●系统提示再次输入姓名和密码。
●如果连续验证错误3次，系统提示相应信息，用例结束。
非功能性需求：无。
后置条件：无。
未解决的问题：无。
2 用例名称：修改密码。
描述：车主用来修改自己的登录密码。
前置条件：车主成功登录到系统中或有验证信息。
部署约束：车主可以从客户端访问该用例，如果是客户端访问，则要考虑到客户端的防火墙。
正常事件流：（1）车主输入用户和密码。
（2）选择修改密码，验证密保。
（3）输入新密码并确定。
可选事件流：密保错误●系统提示再次输入密保信息●如果连续错误3次，系统提示相应信息，用例结束。
非功能需求：无。
后置条件：如果用例执行成功，则车主修改后的密码信息，被保存到系统中。
未解决问题：无。
3 用例名称：余额查询。
描述：车主用来查询账户余额。
前置条件：成功登录到系统。
部署约束:车主可以从客户端访问该用例，如果是客户端访问，则要考虑到客户端的防火墙。
正常事件流：（1）成功登录到系统。
（2）选择余额查询或充值。
（3）显示余额信息或充值信息。
可选事件流：打印回单●选择打印回单。
●回单打印成功，返回到主页面。
非功能性需求：无。
后置条件：无。
未解决的问题：无。
4 用例名称：停车记录。
描述：记录用户停车的信息。
前置条件：用户车辆在此停放。
部署约束：用户或管理员成功登录后可以访问该用例。
正常事件流：（1）用户或管理员选择停车记录。
（2）显示车辆在停车场所有停放记录。
可选事件流：●选择具体的时间进行搜索、查询。
非功能性需求：无。
后置条件：如果用例执行成功，则显示详细信息。
未解决的问题：无。
用例描述
用例编号：001用例名：系统管理员登录系统用例描述：系统管理员登录系统后，通过身份验证，能够对学生的基本信息进行管理，包括录入学生基本信息、修改学生基本信息、查询学生基本信息、删除学生基本信息，并且可以找回自己的密码。
基本路径：1、系统提示用户输入用户名和密码。
2、用户输入用户名和密码。
3、点击学生基本信息，查看学生基本信息。
4、点击修改学生基本信息，修改某位同学的基本信息。
5、点击删除学生基本信息，删除某位或多位学生信息。
6、点击添加学生信息，添加学生基本信息。
扩展点2a输入的用户名错误2a1提示用户账号不存在或者错误2a1用户离开或重新输入账号2b输入密码错误2b1提示用户密码输入错误或者是否找回密码2b2用户离开或者重新登录、找回密码。
变异点无补充说明用例编号：002用例名：教师登录系统用例描述：教师在日常管理中可以登录系统，如果忘记密码，可以找回，可以通过系统查询、修改删除学生的考试成绩。
当考试结束后，教师有权将学生成绩录入系统。
基本路径；1、系统提示用户输入用户名和密码。
2、用户输入用户名和密码。
3、点击录入学生成绩，可以录入学生成绩。
4、点击修改学生成绩，修改该学生的成绩。
5、点击查询学生成绩，查看学生的成绩。
6、点击删除学生成绩，删除学生成绩。
扩展点2a输入的用户名错误2a1提示用户账号不存在或者错误2a1用户离开或重新输入账号2b输入密码错误2b1提示用户密码输入错误或者是否找回密码2b2用户离开或者重新登录、找回密码。
变异点无补充说明用例编号：003用例名：学生登录系统用例描述：学生登录后可以进入本系统用例图，查询自己的个人基本信息。
如果忘记密码可以通过系统找回。
基本路径：1、系统提示用户输入用户名和密码。
2、用户输入用户名和密码。
3、输入个人信息，查看个人基本信息。
扩展点2a输入的用户名错误2a1提示用户账号不存在或者错误2a1用户离开或重新输入账号2b输入密码错误2b1提示用户密码输入错误或者是否找回密码2b2用户离开或者重新登录、找回密码。
测试用例 格式
测试用例格式
测试用例（Test Case）的格式因组织和项目而异，但通常都会包含以下几个部分：
1. 测试用例ID：这是唯一标识一个测试用例的编号。
2. 测试用例描述：简短描述测试用例的目的或意图。
3. 前置条件：执行测试用例之前必须满足的条件。
4. 测试步骤：详细描述执行测试的步骤。
5. 预期结果：根据步骤执行的预期结果。
6. 实际结果：执行测试后的实际结果。
7. 结论：基于实际结果和预期结果的比较，判断测试是否通过。
以下是一个简单的示例：
```markdown
测试用例ID: TC001
测试用例描述: 验证登录功能是否正常工作。
前置条件: 已安装应用程序并拥有有效的用户账户。
测试步骤:
1. 打开应用程序。
2. 点击“登录”按钮。
3. 在弹出的登录页面输入用户名和密码。
4. 点击“登录”按钮。
预期结果: 成功登录并进入主界面。
实际结果: [在实际执行后填写]
结论: [根据实际结果和预期结果的比较填写]
```
当然，实际测试用例可能会更加复杂，并且会包括更多的细节和条件，这取决于所测试的特性和需求。
用例描述模板
用例模板(表单形式)e Case Description Information（用例描述信息）<以下内容定义了适用一个特定用例的信息。
每一条信息对于理解隐藏在用例后的目的都非常有用。
>名称:<一个简短的描述性动词短语给一个用例命名。
>1.2.Goal目标:<从用户的角度，用几句话描述这个用例的终极目标。
>e Case Team Leader/Members用例负责人及其成员:<这是定义一个负责完成这个用例的人，及其团队成员。
>1.4.Pre-condition前置条件:<在开始执行这个用例的路径之前，系统必须达到的状态。
当进行路径层的分析时，这些应该会被深化>1.5.Post-condition后置条件:<当用例的路径完成后，系统必须达成的状态。
当进行路径的分析时，这些可能会被深化。
>1.6.Constraints/Issues/Risks约束/问题/风险:<当进行用例细节的设计时，这里的任何一条都会增加开发团队的负担。
当进行路径的分析时，这些可能也会被深化。
把每个问题指派给具体的个人也许会带来好处。
>1.7.Trigger Event(s)驱动用例的事件:<外部事件或内部时钟事件可以触发一个穿过用例的路径。
这些事件也可以在每个路径分析时定义。
>1.8.Primary Actor主要活动者:<这个关键活动者参与进这个用例中。
典型地，这个个体是触发用例路径的事件来源。
>1.9.Secondary Actor(s)次要活动者:<其他活动者，在用例中充当一定的角色。
>e Case Pathway Names用例路径名称:<这些代表路径的名称列表，它们只是作为下面部分路径细节描述的一个总览列表。
>2.1.Primary Path(Happy Path)主要路径（愉快路径）:<这是这个用例最经常发生的路径。
用例描述(部分)
9.创建给送货员的购买单。
10.创建顾客收据并放给用户在Web浏览器上显示，收据数据被作为电子邮件发送到顾客的电子邮件账户地址。
扩展：
2.a由于商品无现货而不能创建行项目
2.a.1顾客收到无现货的消息，顾客订购该商品的期货。
2.a.2顾客收到无现货的消息，顾客继续选购替代品。
用例名称：登录
主参与者：顾客、客服、系统管理员
层次：海平面（用户目标）
利益相关者：顾客、客服、系统管理员
前置条件：已经注册成为八公宠物乐园的用户
最低保证：回滚任何未完成的事务，系统记录进展日志直到失败
成功保证：用户能够登录自己的账号
触发器：用户进入“登录”页面
主要成功情节：
1.用户进入八公宠物乐园网站的“登录”页面。
成功保证：顾客能够评价已完成的订单
触发器：顾客进入“评价商品”页面
主要成功情节：
1.顾客调用“查看订单”用例。
2.顾客选择“待收货”的订单。
3.顾客选择“确认收货”，订单状态更新。
4.顾客选择“评价商品”，进入商品评价页面。
5.顾客在文本框中输入对该商品、物流、服务的评价并对其打分。
6.顾客选择“提交”，评价成功，订单状态更新。
2.顾客输入要咨询的问题，得到客服机器人的回答。
3.顾客选择“咨询人工客服”按钮。
4.顾客选择要咨询的问题类型（如商品咨询、送货咨询、服务咨询）。
5.系统按照问题类型为该顾客匹配一位处于空闲状态的客服。
6.顾客输入要咨询的问题，得到人工客服的回答。
7.顾客结束咨询，对客服服务进行评价。
扩
成功保证：顾客能够查看自己所有的订单
触发器：顾客进入“查看订单”页面
用例描述
SUGG．PRICE：161，250 PURCHASE PRICE：205，000
——————————————————————————————————
CLASSIFICATION：*Other PURCHASE DATE：07/13/2003
TRENDS
Artist：David Hatzayar
——————————————————————————————————
CLASSIFICATION：Masterwork TIILE：Table_Mountain
SALE DATE：05/11/2003
TARGETPRICE：264，450 SALEPRICE：270，000
分类
购买日期
画家姓氏
油画名称
建议的最大购买价格
实际购买价格
任何以超过由算法确定的最大购买价格的价格购买的油画必须标记出来。
该报告必须依据分类和分类中的购买日期排序存储。
在报告末尾应该显示报告中所有油画的实际购买价格与算法建议的最大购买价格之间的平均比率。
Report Date：08/14/2004
Osbert Oglesby – Collector of Fint Art
2.1对于名品：
信息系统首先把该油画看作是同一位画家的精品来计算最大购买价格。然后，如果油画是在21世纪绘制的，则用该数字乘以0.25；否则，用该数字乘以
（21－c）/（22－c），其中c代表作品是在哪个世纪绘制的（12＜c＜21）。
2.1对于其他油画：
信息系统通过公式Ｆ×A来计算最大购买价格，其中Ｆ是针对那位画家的一个常数(流行度系数)，A是以平方厘米为单位的油画布的面积。如果那位画家没有流行度系数，Osbert将不会购买该油画。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
这里用我开发的一个家教网站来简单的分析用例图的画法和用例描述的写法。
这个网站我用UML完整的分析一下，以下我提取了用例图和用例描述的部分。
这个家教网站分为前台客户系统和后台管理系统。
前台客户系统的用例图如下：
后台管理系统用例图如下：
对于用例描述，篇幅有限，我在这里只列了后台管理系统中的网站公告发布这个用例的描述。
如下：
用例名称：网站公告发布
用例标识号：101
参与者：负责人
（注：专业文档是经验性极强的领域，无法思考和涵盖全面，素材和资料部分来自网络，供参考。
可复制、编制，期待你的好评与关注）。