Quic用例文档
1. 参与者 .......................................................................................................................... - 1 -
1.1. 注册用户............................................................................................................ - 1 -
1.2. 游客.................................................................................................................... - 1 -
1.3. 管理员................................................................................................................ - 1 -
2. 用例说明........................................................................................................................ - 1 -
2.1. 注册用户............................................................................................................ - 1 -
2.2. 用户登录............................................................................................................ - 1 -
2.3. 修改个人信息.................................................................................................... - 2 -
2.4. 添加好友............................................................................................................ - 3 -
2.5. 编辑文档............................................................................................................ - 4 -
2.6. 发送邮件............................................................................................................ - 4 -
2.7. 发送消息............................................................................................................ - 4 -
2.8. 接收消息............................................................................................................ - 5 -
2.9. 查看消息记录.................................................................................................... - 5 -
2.10. 检索文档.......................................................................................................... - 6 -
2.11. 检索邮件.......................................................................................................... - 6 -
2.12. 用户管理.......................................................................................................... - 6 -
1.参与者
1.1.注册用户
1.2.游客
1.3.管理员
2.用例说明
2.1.注册用户
用例描述：
参与者通过填写注册信息，确认激活邮件成为Quic注册用户
参与者：
游客
前置条件：
游客申请Quic账号，输入电子邮件地址、昵称、生日、性别、密码、确认密码、所在地，确定同意Quic用户服务条款
后置条件：
系统发出激活邮件，用户登录邮箱确认后账号申请成功
基本路径：
1.游客选择注册Quic账户，输入电子邮件地址、昵称、生日、性别、
密码、确认密码、所在地，确定同意Quic用户服务条款
2.系统向用户填写的邮箱地址发出激活邮件
3.用户登录邮箱激活账号
4.系统确认账号申请成功并为用户分配Quic号码
错误流
A. 邮箱格式不正确、出现不允许昵称、密码不符合要求、未同意服务条款
A1系统提示错误信息
A2 游客可选择以下动作重新填写注册信息取消
A2A游客选择重新填写注册信息，系统检测有无错误……
A2B游客选择取消，用例结束
B. 游客没有登录邮箱激活账号
B1 系统不分配账号
B2 游客可选择以下动作登录邮箱激活账号无动作
B2A游客登录邮箱激活账号，系统确认账号激活并为用户分配Quic号码
B2B游客不激活账号，用例结束
2.2.用户登录
用例描述：
参与者通过填写账号和密码登录到Quic系统
参与者：
注册用户
前置条件：
用户拥有正确的账号密码
后置条件：
系统显示Quic系统操作界面
基本路径：
1.用户在Quic登录窗口填写账号、密码、选择登录状态
2.系统检查账号是否存在、密码是否匹配
3.系统显示Quic系统操作界面
错误流：
A．账号不存在
A1系统提示错误信息
A2用户可选择以下动作重新填写正确的Quic账号注册新账号关闭登录窗口
A2A用户填写正确Quic账号，系统检测其密码是否匹配
A2B用户注册新账号，系统显示注册窗口
A2C用户关闭登录窗口，用例结束
B．密码错误
B1系统提示错误信息
B2用户可选择以下动作重新填写正确密码找回密码关闭登录窗口B2A用户填写正确密码，系统显示操作界面
B2B用户选择找回密码，系统向用户邮箱发送找回密码邮件……
B2C关闭登录窗口，用例结束
2.3.修改个人信息
用例描述：
用户可以修改昵称，密码，联系电话，邮箱等
参与者：
注册用户
前置条件：
用户已经登录系统
后置条件：
无
基本路径：
1.用户发送修改个人信息请求
2.进入修改个人信息页面
3.输入要修改的昵称，密码，联系电话，地址，邮箱等有效信息
4.修改成功则返回已修改的信息列表
错误流：
A. 填入信息错误，不符合系统要求
A1系统提示错误信息
A2用户选择以下动作重新填写取消
A2A重新填写，系统检测有无差错······
A2B取消，用例结束
2.4.添加好友
用例描述：
用户通过发送添加好友请求或接受添加好友请求添加好友
参与者：
注册用户
前置条件：
用户通过身份验证向其他用户发送添加好友请求或接收到添加好友请求
后置条件：
系统显示两用户成为好友
基本路径：
1.1.用户通过身份验证向其他用户发送添加好友请求
1.2.系统将好友请求发送至被添加用户
1.3.被添加用户可选择确认添加请求取消请求
1.4.若被添加用户确认添加请求系统显示两用户成为好友
1.5.用户可选择以下操作修改好友昵称修改用户分组发起对
话
1.6.用户接收到添加用户请求确认发送请求的用户身份确认信
息添加为好友
1.7.系统显示两用户成为好友
1.8.用户可选择以下操作修改好友昵称修改用户分组发起对
话
错误流：
A．身份验证信息不正确
A1系统提示错误信息
A2用户可选择以下动作
重新输入身份验证信息
取消添加好友操作
A2A重新输入身份验证信息，系统将好友请求发送给被请求好友
A2B用户取消操作，用例结束
2.5.编辑文档
用例描述：
用户打开文档，编辑后保存
参与者：
注册用户
前置条件：
新建文档
已经打开已存在文档
后置条件：
显示文档编辑界面
基本路径：
1.打开“我的文档”分页，或选择聊天窗口内文档
2.新建文档或点击打开目标文档
3.进行文档编辑
4.保存文档
错误流：
无
2.6.发送邮件
用例描述：
实现对联系人邮件的发送,用例起始用户选择成员后，点击“发送Email”按钮
参与者：
注册用户
前置条件：
进入“发送邮件”界面
后置条件：
发送成功
基本路径：
1.进入邮件发送系统
2.用户通过复选框勾选收件人,或输入收件人账号
3.系统显示勾选结果
4.填写邮件内容
5.添加附件
6.用户点击“发送Email”按钮
7.提示“邮件发送成功”
错误流：
A.若没有勾选接收人
A1系统给出提示“请选择收件人”
2.7.发送消息
用例描述：
系统将用户输入的文字、图片等信息发送给指定好友
参与者
注册用户
前置条件
用户选择好友输入需要发送的文字、图片等信息
后置条件
系统将信息发送至被指定好友，震动（声音）提示
基本路径
1.用户选定好友，输入要发送的文字、图片等消息
2.系统将消息发送至被指定好友账号
3.系统在被指定好友登录时进行提醒
错误流
A 指定好友账号已注销
A1系统提示错误信息，用户取消操作，用例结束
B 因网络问题消息发送失败
B1系统提示错误信息
B2用户可选择以下动作重新发送消息取消发送
B2A用户点击重新发送，系统再次发送消息
B2B用户取消发送，用例结束
2.8.接收消息
2.9.查看消息记录
用例描述：
用户可查询与特定用户或聊天群的聊天记录
参与者
注册用户
前置条件
用户打开Quic聊天系统，聊天记录存在
后置条件
系统显示用户要查询的聊天记录
基本路径
1.用户选择好友或者群
2.点击查看消息记录
3.系统显示用户想要查询的消息记录
4.用户可选择以下动作：查看记录删除消息记录关注消息历史窗口
错误流
A不存在消息记录，或时间太久被删除
A1系统显示消息记录空白
A2用户关闭历史记录，用例结束
2.10.检索文档
2.11.检索邮件
用例描述：
用户搜索自己邮箱中的邮件、文件、文字等信息
参与者：
注册用户
前置条件：
无
后置条件：
显示搜索的列表供用户选择
基本路径：
1.打开我的邮箱分页
2.点击搜索框并输入关键字
3.系统把关键字与本地邮件中的文字与附件作比对
4.以列表的形式返回相应的文字结果和附件结果
错误流：
A.搜索无结果
A1提示用户继续搜索取消
A1A重新搜素，返回基本路径
A1B取消，用例结束
2.12.用户管理
用例描述：
管理员通过该用例管理用户信息
参与者：
管理员
前置条件：
管理员登陆
后置条件：
如果管理员对用户信息进行了修改，则保存修改的用户信息
基本路径：
1.该用例起始于管理员需要对用户信息进行管理
2.管理员通过系统进行登陆
3.管理员登陆后，进入用户管理模块
4.管理员管理用户信息，删除用户，发出警告，冻结用户等，保存修改的信息
5.系统保存管理员的对用户信息的修改，用例结束
错误流：
A.系统保存失败
A1系统显示保存失败信息，并提醒管理员重新修改用户信息A2管理员重新提交用户信息，也可以结束该用例
学生： 用户登录 ID 1 用例名称：用户登录 参与者：学生 用例描述：大概过程：学生在系统上登录需要输入用户名、密码，系统确认身份。 输出结果：在系统的登陆界面区域确定身份后，登录界面转换登 录成功。 前置条件：系统已启动到登录界面，学生在进行其余操作之前必要完成的步骤。 后置条件：用户登录成功后系统显示信息查看的结果界面，用户登录成功后，进入到学生相应界面。 正常流程：1．学生在用户名输入框里输入用户名 2．在密码框里输入密码 3．用户按登录后，系统验证学生输入的有效性。 4．有效则进入系统的主界面。无效则提示相应错误给用户。 5．用例终止 异常事件流：显示错误信息，提示无效身份登录，认证无法通过登陆失败。 分支流程：在按“登录”按钮之前，学生可以随按“关闭”按钮。 特殊需求：要求用户密码安全。 签到 ID： 2 用例名称：签到 参与者：学生 用例描述：大概过程：学生在系统上选择签到按钮。 输出结果：在系统确定身份后，签到成功。
前置条件：在此用例开始之前，学生必须登录到系统中。 后置条件：如果用例执行成功，可以实现学生客户端的功能。 正常流程： 1.学生成功登陆客户端 2.点击签到按钮，此用例启动。 3.显示“签到成功”信息。 特殊需求：学生一次只允许签到一个用户。 发送文件 ID： 3 用例名称：发送文件 参与者：学生 用例描述：产生的原因：学生需要将所完成的功课提交老师批阅。 大概过程：学生完成作业后，按“提交按钮”发送给老师。 输出结果：系统提示文件送达成功或者失败。 前置条件：学生必须提供上传信息资源请求。 后置条件：学生可以快速提交作业，老师及时发现问题，可通过群聊方式纠正学生出现的问题。 正常流程： 1.学生提交上传文件信息请求 2.界面转换至上传文件界面 3.学生将所传文件内容进行上传 4.进行提交 5.系统提示成功与否信息 异常流程： 1.用户取消上传请求，系统回到界面。 2.文件上传失败，系统提示再次上传。 特殊需求：上传文件不宜过大。
案例描述 两位数加两位数口算的课堂作业.doc 在教学“两位数加两位数口算”时我创造性地使用教材，修改了书本上的习题，设计了如下的课堂作业： 第一部分 1.直接写出得数 37+21 23+25 30+20 37+33 43+27 30+80 37+31 43+25 300+200 37+36 46+27 300+800 2.把得数大于50的算式圈出来。 34+18 23+26 19+64 38+53 62+14 43+48 26+47 17+36 72+12 3.先估计得数是几十多，再口算。 73+15= 35+26= 19+64= （）十多（）十多（）十多 38+53= 26+47= 17+36= ( )十多（）十多（）十多 第一部分的习题为基本训练，即本节课的基本标准，全班每个学生必须完成，每人都要“保底”。如在完成的过程中有困难，有错误的学生，给予的课后作业为巩固练习，即第二部分的练习。 第二部分 1.先估计几十多，再口算。 35+32 45+14 37+55 26+29 35+38 49+14 21+78 44+17 2.比一比，算一算。 60+70 50+90 80+40 600+700 500+900 800+400 3.估计一下，填上“> ”“<”或“=”。 27+58（）58+27 54+18（）45+18 35+48（）48+53 23+18（）23+13 当学生能轻松完成第一部分的基本题，并且正确率100%的话，就不需要再做第二部分的巩固练习了，而是完成第三部分的提高题。 提高题 36+64 1000-547 175+225 16+28+72 409+191 38-13-17 这部分的题目要求全部口算，不列竖式能马上完成。 提高题是有一定难度的，对学生的计算能力，思维速度，都有较高要求，能完成这部分题目的学生，并能做到全对的话，将给予奖励，并且可以免做一道明天的基本题。练习到这儿还没结束，我还设计了更高难度的“挑战题”。 挑战题： 756-98 500-99-1-98-2-97-3-96-4 挑战题每天两个，不在多，而要精，有难度，能吸引一部分学有余力的学生。
软件测试用例模板（带实例） 工程管理系统案例研究项目功能测试用例 编号：Project_MA_Login_1 编号：Project_MA_Interface_3 项目/软件工程管理系统案例研究项目程序版本 1.0.0 功能模块Login 编制人李虎、彭贝贝、唐姣凤用例编号Project_MA_Login_1编制时间 2005-2-22 相关用例Project_MA_Main_1 、Project_MA_Interface_1 、Project_MA_Priority_1 功能特性系统的初始窗体，并进行用户的合法性验证。 测试目的验证是否输入合法的信息，阻止非法登陆，以保证系统的安全特性预置条件数据库中存储了一些用户信息特殊规程说明 （区分大小写） 参考信息需求说明中关于“登录”的说明测试数据用户名= administrators 密码= 1001（数据库表中有相应的信息）操作步骤 操作描述 数据期望结果 实际结果 测试状态（P/F ） 1 选择用户名称，按“提交”按钮。用 户 名 = administrators ，密码为空显示警告信息“帐号 或密码不能为空！” （符合） P 2 选择用户名称,输入错误密码，按 “提交”按钮。用 户 名 为 administrators ，密码=123 显示警告信息 “帐号 或密码不错误！” （符合） P 3 选择用户名称 ,输入密码，按“提交”按钮。 用 户 名 = administrators ，密码 为=1001 进入系统” （符合） P 测试人员 彭贝贝、李绍霞、 唐姣凤 开发人员杨丽娟负责人李虎(手写)
项目/软件工程管理系统案例研究项目程序版本 1.0.0 功能模块Interface编制人李虎、彭贝贝、唐姣凤用例编号Project_MA_Interface_3编制时间2005 – 2– 21 相关用例Project_MA_Interface_1、Project_MA_Interface_2、Project_MA_Priority_1、Project_MA_DBACCESS_1 功能特性维护界面添加操作 测试目的检查维护窗体界面与设计的符合性。 预置条件能够登录进入到系统特殊规程说明（无） 参考信息系统概要设计说明和详细设计说明 测试数据 操作步骤操作描述数据期望结果实际结果测试状态（P/F）1 …………… 2 3 4 5 6 7 8 9 10 11 12 测试人员彭贝贝、李绍霞、 唐姣凤开发人员杨丽娟负责人李虎(手写)
作者：尤帅 信息工程学院 《软件模型》课程期中报告 学年：2015—2016第一学期专业：软件工程 班级： 小组成员： 课程教师： 完成时间：2015年11月5日
图书馆信息管理系统 用例文档 成员： 日期：2015-11-05 目录 1.前言 (3)
1.1编写目的 (4) 1.2内容概述 (4) 2.用例列表 (5) 3.用例图 (6) 3.1子系统（局部）用例图 (6) 3.1.1读者参与用例 (6) 3.1.2管理员管理用例 (7) 3.1.3数据用例 (8) 3.1.4登录用例整合 (8) 3.1.5账号信息管理整合 (9) 3.2系统用例图 (9) 4.用例描述 (10) 编写总结 (18) 1.前言 图书馆信息管理系统的需求获取过程中，根据分析系统和外部对象的交互当中所执行的行为序列，及场景的层次性描述，提取了相关用例。 本文档给出了需求获取阶段使用的用例列表和用例描述。
1.1编写目的 整理和归类需求获取行为得到的消息。由于直接从用户的到的信息具有荣誉、遗漏、模糊、错误等，我们需要对他们进行分析并进行归类和系统化。 为详细的信息分析提供背景基础和上下文知识。由于软件系统的每项功能都依存于一定的背景和上下文环境，有利于开发者获取精准的信息进行系统开发。 在得到用户需求并将其转化成一个目标时，需要为目标组织信息，建立场景。用例就是一种场景的文化表现方式，实用叙述性的文本来描述场景。可以将解决方案用自然语言描述出来，便于用户理解，和用户达成共识，以便于进一步完善。 该文本是对用户的所有操作的描述，经过一系列的描述可以实现用户的业务需求。可以说是对用户前景的实现，从而使得软件系统由抽象变成具体。 1.2内容概述 该文档会根据启动阶段的前景和范围文档，对解决方案进行细化。文档包括几个细化用例，先对每个用例做了简要描述，并定义每个用例的ID，然后对用例进行详细的描述。
XXX村村民交流互动网站系统 设计小组成员：何成龙、陆承林 黄元勇、王永亮 胡荣启 引言： 在计算机技术飞速发展的今天，各类交流网站挤满了互联网，本设计立足于XXX村村民交流互动而设计一个交流网站，网站为村民提供交流服务，村民可以在网上通过发帖聊天交流生活琐事以及农事科技等。 第一章：功能性需求分析 一、在本次设计中，“远程教育网站系统”包括以下功能模块： 1、个人工作台 2、在线浏览 3、资料共享 4、系统管理 5、在线帮助 二、功能描述 1、个人工作台 用户可通过个人工作台对个人信息进行注册和修改。 1.1、用户注册/登陆模块 用户通过注册模块进行注册成为会员，登陆模块为会员完成用户登陆； 1.2、修改信息 在本模块用户可对已填信息进行完善和修改。 2、在线浏览 在线浏览为会员和非会员提供阅读材料以及视频文件，可在线点播及阅读。 3、资料共享 此功能仅为会员提供，非会员无权享受此功能。会员通过此模块可下载所需内容以及上传文
件。 4、系统管理 4.1、后台管理 专为网站管理员开设。网站管理员通过此模块可对网站进行维护和管理。 4.2、网站数据库 主动收集网站各类数据并及时更新。 4.3、信息管理系统 仅为信息管理员提供，可以通过此模块对会员上传的文件进行审核和删除，以及对注册会员进行管理。 5、在线帮助 5.1、联系我们 用户通过此模块就网站存在的问题进行反馈。 6.功能描述文档： 功能编号功能名称功能描述备注 01 注册用户可以通过注册功能进行信息注册成为网站会员 02 登录会员/信息管理员用户通过此登录进行登录网站，登录时会员选择“会员登录”进行登录，信息管理员选择“管理员”进行登录。 03 浏览网页非会员和会员享有的权力，非会员只能浏览不能留言 以及下载上传文件。 04 个人中心一、会员个人中心包含以下内容模块： 1.个人主页 会员在个人主页里可以根据自己喜好设置主页属性； 2.个人信息修改 个人信息修改包括密码修改和基本信息修改； 3.好友 好友模块包含对好友的添加和删除功能，也可以对好友进行喊话；
需求用例文档 ----酒店管理用例文档
----酒店管理
用例ID号 UC-1 用例名称开房登记 创建者陶菲 最后更新者马萍 创建日期2010-5-14 最后更新日期2010-5-16 参与者前台工作人员 描述前台工作人员查询可用房间，填写登记相关信息，保存登记信息 前置条件1、前台工作人员 登录到“酒店管理系统” 2、有顾客预定或亲自登记 房间 3、登记信息符合业务要求 4、系统显示尚有空房 后置条件1、系统提示保存成功 2、根据登记信息引导顾客找到房间 主要参与者用例 主干过程 1.0 客房登记 1.前台工作人员要求查 看当前的客房情况 2.系统显示当前客房信 息 3.根据系统显示的空房 信息，为顾客选择相应的客房 4.系统生成入住单号、 入住时间。根据系统选择的房间 类型自动生成单价。通过顾客提 供的信息，选择客户类型、性别、 证件类型、计费方式，输入房间 号、客户名称、会员编号、地址 信息、备注、预住天数、押金等。 5.前台工作人员要求保 存登记信息 6.系统检查不能为空信 息是否已正确填写
7.系统提示保存成功 8.系统将登记信息存储 在数据库中 分支过程 1.1定多个房间 1．顾客要求定多个房间 2．返回第一步 异常 1.0.E.1 当前没有空房（第一步） 1、系统通知前台工作人 员当前没有空房 2a、顾客取消订房 2b、系统终止用例 3a、顾客请求选择另一时间或 房间类型 3b、系统重新启动用例 包含查询客房信息 优先级高 使用频率每天大约50-100次 业务规则BR-1 ，BR-2，BR-3 ，BR-4 特别需求 1.前台工作人员在 保存表单前可以清空表单 假设顾客是符合规定可以订房的 用例ID号 UC-4 用例名称客户结账 创建者陶菲 最后更新者马萍 创建日期2010-5-14 最后更新日期2010-5-16 参与者顾客、结账核算系统 描述由前台工作人员选择 或输入顾客要结账的房间，填写结 账相关信息，保存结账信息 前置条件1、前台工作人员 登录到“酒店管理系统” 2、提出结账要求的顾客定 过房间并且尚未结账 后置条件1、系统提示结账成功 2、系统更新数据库
[方案]编写软件测试用例文档的例子TestCase_LinkWorks_WorkEvaluate 用例编号 LinkWorks 项目名称 WorkEvaluate模块模块名称 研发中心-质量管理部项目承担部门 用例作者 2005-5-27 完成日期 质量管理部本文档使用部门 评审负责人 审核日期 批准日期 注:本文档由测试组提交～审核由测试组负责人签字～由项目负责人批准。 历史版本: 版本/状态作者参与者起止日期备注 V1.1 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI(图形用户界面)与应用程序交互，对交互的输出或接受进行分析，以此来核实需求功能与实现功能是否一致。 项目名称用例标识 LinkWorks_ WorkEvaluate_02 MIIP 陈谦模块名称开发人员 WorkEvaluate 参考信息工作考核系统界面设计(2005_03_28).vsd 用例作者
设计日期测试人员高珍珍测试类型 2014-8-25 黑盒测试日期测试方法 用例描述 前置条件 编号权限测试项测试描述/输入/操作期望结果真实备注 (并列类别结果 关系) 无列导航栏导航浏览\点击导航连接详细正确导航页面所 00001 表测试在位置 页添加删除修添加修改删除按钮是否不可用 00002 面改按钮可用 接受、汇报按1) 不是自己负责的数据不能 钮未考核之前能否接受 \汇报 2) 属于自己负责的未接能 受之前时候是否可以 接受 00003 3) 属于自己负责的数据能 接受后但未考核能否 可以汇报 4) 接受后的数据没有汇不能 报但考核了，是否仍 可以汇报 考核审核按这俩按钮是否可用这两按钮为置灰，不 00004 钮可用 二级联动下功能下拉列表选择 1)默认为“本月由我
Use Case 图即用例图，是从外部用户的角度来描述系统功能的一种需求表达方式。一个系统常常包含了众多的用例，每个用例表达了用户对系统的一项需求或描述了人们使用系统某项功能的途径。使用系统的不同功能，其操作的场景不同。而使用相同的功能，其场景则相似。将同一用例的场景用文字描述出来就得到了系统用例描述。完整的描述用例，通常包括用例名称、参与执行者、前置条件、事件流、后置条件等。若用UML 图形机制表达，便是系统的用例图。通常，我们将二者相结合，能清晰的表达出系统的用例。 系统管理员：系统管理员为系统的管理者，系统管理员主要有以下权限：读者信息管理，图书信息管理，系统维护。 图书管理员：图书管理员为图书馆工作人员，图书管理员主要有以下权限：分类管理，借书处理，还书处理，解除预定。 图书借阅者：图书借阅者是系统中数量最多也是最重要的参与者。图书借阅者主要有以下权限：查询个人信息，查询图书信息，预定图书，借阅图书，返还图书。 1. 创建系统用例模型图 系统参与者： borrower librarian administrator 系统参与者 图书管理系统简示： system management borrowers management librarian books management administrator 图书管理系统 a.系统管理员用例图
系统管理员能通过该系统进行如下活动内容和要求： 添加借阅者：系统管理员可以在添加符合身份的新读者信息 删除借阅者：系统管理员可以在删除页面添加已不符合身份的借阅者信息 修改借阅者信息：系统管理员可以在修改信息页面修改借阅者信息 添加图书信息：系统管理员可以在添加图书信息页面添加图书馆新增图书 删除图书信息：系统管理员可以删除不能在借阅图书的信息 系统维护：系统管理员维护该系统的日常工作 system maintenance 用例说明： Login system：系统登录 Account management：账户管理（其中包括图书管理、借阅者管理、系统管理）Add book：添加图书 Remove book：删除图书 Add borrower：添加借阅者
百度文库 - 让每个人平等地提升自我 需求分析规范 用例描述文档编写规范（精要） 版本 <> 文档编号：001-0002-2
版本历史 日期版本描述作者2006-07-01 <> 初稿整理吕春秋
目录 1.前言5 1.1目的5 1.2范围5 1.3本文档说明5 2.基本要求6 3.用例事件流的描述6 3.1基本事件流的要求7 3.2子事件流的要求7 3.3备选事件流的要求8 3.4事件流中的序号标号9 3.5事件流中“确认”与“执行”操作描述的建议9 4.业务规则的描述9 4.1业务规则的种类9 4.1.1业务规则的抽取及编号10 4.1.2公共业务规则的抽取及编号10 4.2业务规则描述结构10 4.2.1要点说明式10 4.2.2顺序结构11 4.2.3分支结构11 4.2.4循环结构12 4.2.5混合结构13 4.2.6注意事项13 4.3业务规则描述中的缩进规则13 4.4业务规则描述中的标号13 5.子用例的定义与描述13 5.1子用例的设计方法13 5.2子用例中判断上级调用用例的方法13 6.用例描述中的其它规范14 6.1类、属性、参数、值的书写规则14 6.1.1类名的书写规则14 6.1.2属性名的书写规则14 6.1.3参数名的书写规则14 6.1.4各种值的书写规则14 6.2用例描述中的注释信息15 6.2.1注释要求15 6.2.2注释信息的描述15 6.3描述一致性15 7.接口15 8.新一代ERP系统中的几个公共机制15
8.1删除完整性检查15 8.2消息机制16 8.3编号管理16 9.用例描述中用词规范16 9.1范围值的描述16
图书管理系统UML建模与设计模式 实验报告 计算机与信息工程学院 一、实验目的 在熟悉用例概念与应用的基础上，掌握用例模型的建立，包括： 1．掌握用例图的建立。 2．掌握用例描述文档的编写。 3．掌握建模工具的使用。 二、实验内容 根据以下需求设计一个图书馆管理系统的用例图模型，包括：用例图和主要用例的描述文档。 基本功能要求： 图书管理：新书登记，图书查询，图书注销； 借阅管理：借书，还书，查询今日到期读者； 读者管理：增加读者、删除读者、查询读者、读者类别管理（可以设置不同
类的读者，并使不同类读者对应不同类的图书流通参数，如可借册数，可借天数，可续借次数，可续借天数等）； 报表管理：包括图书借阅统计报表，被注销图书统计报表等；报表可以有多种格式可供选择；可以把报表输出到文件中，可以预览报表、打印报表等。 系统管理：系统管理员使用，包括用户权限管理（增加用户，删除用户，密码修改等），数据管理（提供数据修改、备份、恢复等多种数据维护工具），系统运行日志，系统设置等功能。 三、实验思想 （1）分析系统需求； （2）确定系统参与者：读者、图书管理员、图书管理系统； （3）确定系统用例； 四、实验结果 借阅人用例图：
图书系统管理员用例图： 图书管理员用例图：
1．用例名称：登录 用例描述：根据用户输入的用户名和密码判断用户的身份，赋予相应的权限。前置条件：无 后置条件：根据用户所有的权限进入相应的操作界面。 基本操作流程： 1输入用户名 2输入密码 2校验密码是否正确。 3根据用户身份进入相应的操作界面。 可选流程：如果密码不正确，提示重新输入密码； 如果用户名不正确，提示没有此用户。
测试用例 目录 1．引言 (3) 1.1编写目的 (3) 1.2项目背景 (3) 1.3定义 (3) 1.4参考资料 (3) 1.5测试种类的分类 (4) 1.6测试阶段 (4) 1.7测试用例的分类 (4) 1.8测试种类、阶段和测试用例的关系 (4) 1.9用例编写方案 (5) 2测试用例 (5) 2.1 功能测试用例（代号F（Function ）） (5) 2.1.1 被测试对象（单元）的介绍 (5) 2.1.2测试范围与目的 (5) 2.1.3测试环境与测试辅助工具的描述 (5) 2.1.4测试驱动程序的设计 (5) 2.2 接口-路径测试用例(代号I（Interface）） (6) 2.2.1被测试对象（单元）的介绍 (6) 2.2.2测试范围与目的 (6) 2.2.3测试环境与测试辅助工具的描述 (6) 2.2.4 测试驱动程序的设计 (6) 2.2.5 路径测试的检查表（代号PI（Path Inspection ） (6) 2.3 性能测试用例(代号PE（Performance）） (7) 2.3.1 被测试对象（单元）的介绍 (7) 2.3.2 测试范围与目的 (7) 2.3.3 测试环境与测试辅助工具的描述 (7) 2.3.4 测试驱动程序的设计 (7) 2.4 图形用户界面测试用例（代号U（User Interface）） (8) 2.4.1 被测试对象的介绍 (8) 2.4.2 测试范围与目的 (8) 2.4.3 测试环境与测试辅助工具的描述 (8) 2.4.4测试驱动程序的设计 (8) 2.4.5测试人员分类 (8) 2.4.6用户界面测试的检查表 (8) 2.5 健壮性测试用例（代号RO（Robustness）） (9) 2.5.1 被测试对象的介绍 (9) 2.5.2测试范围与目的 (9) 2.5.3 测试环境与测试辅助工具的描述 (9) 2.5.4 测试驱动程序的设计 (9) 2.5.5 容错能力/恢复能力测试用例 (9)
用例描述?对“身份验证”用例的完整描述 主参与者：参保人 目标：参保人登陆查询系统 范围：医疗保险管理系统 前置条件： 触发事件：参保人想进入查询系统进行操作 主成功场景： 1）参保人输入卡号，系统验证其有效性 2）参保人输入密码，系统验证其有效性和正确性 扩展： 1a：系统不存在该卡号 2a：输入密码有误，无法通过验证 发生频率：一天100次 ?对“信息统计处理”用例的完整描述 主参与者：参保人 目标：参保人察看统计信息 范围：医疗保险管理系统 前置条件：参保人已登陆查询系统 触发事件：参保人鼠标点击查询或键盘输入请求 主成功场景： 1）参保人鼠标点击查询或键盘输入请求 2）系统内部进行查询 3）系统显示查询结果给参保人 扩展： 1a：参保人输入请求有误 2a：系统内部忙 发生频率：一天100次 ?对“反馈信息”用例的完整描述 主参与者：医疗保险管理系统 目标：显示结果给参保人 范围：医疗保险管理系统 前置条件：参保人发出查询请求，并经过系统处理触发事件：系统处理结束 主成功场景： 1）参保人发出查询请求，并经过系统处理 2）可视化显示给参保人
扩展： 2a：系统发生错误 发生频率：一天100次 ?对“录入报销记录”用例的完整描述主参与者：工作人员 目标：向系统输入报销记录 范围：医疗保险管理系统 前置条件：参保人来到服务窗口 触发事件：参保人要求报销回退 主成功场景： 1）参保人来到服务窗口要求报销回退 2）参保人提供卡号及密码 3）工作人员验证报销记录并确认 4）工作人员录入报销记录 扩展： 2a：参保人忘记了自己的卡号密码 3a：报销凭证有误无法通过验证 4b：录入时系统发生错误 发生频率：一天100次 ?对“返回处理结果”用例的完整描述主参与者：工作人员，参保人 目标：显示结果给参保人 范围：医疗保险管理系统 前置条件：工作人员录入记录 触发事件：工作人员录入记录并保存 主成功场景： 1）工作人员录入记录并保存 2）系统显示处理成功界面 扩展： 1a：工作人员未能正常录入 1b：系统未能正常保存 2a：系统显示出错 发生频率：一天100次 ?对“输入处方”用例的完整描述 主参与者：工作人员 目标：向系统输入处方 范围：医疗保险管理系统 前置条件：参保人来到服务窗口请求报销
长春一汽启明信息技术有限公司 ERP项目 需求分析规范用例描述文档编写规范（精要） 版本 <1.0> 文档编号：001-0002-2
版本历史
目录 1.前言5 1.1目的5 1.2范围5 1.3本文档说明5 2.基本要求6 3.用例事件流的描述6 3.1基本事件流的要求7 3.2子事件流的要求7 3.3备选事件流的要求8 3.4事件流中的序号标号9 3.5事件流中“确认”与“执行”操作的描述9 4.业务规则的描述9 4.1业务规则的种类10 4.1.1业务规则的抽取及编号10 4.1.2公共业务规则的抽取及编号10 4.2业务规则描述结构10 4.2.1要点说明式10 4.2.2顺序结构11 4.2.3分支结构11 4.2.4循环结构12 4.2.5混合结构13 4.2.6注意事项13 4.3业务规则描述中的缩进规则13 4.4业务规则描述中的标号13 5.子用例的定义与描述13 5.1上级调用用例的判断方法13 6.用例描述中的其它规范14 6.1类、属性、参数的书写规则14 6.1.1类名的书写规则14 6.1.2属性名的书写规则14 6.1.3参数名的书写规则14 6.1.4各种值的书写规则14 6.2用例描述中的注释信息15 6.2.1注释要求15 6.2.2注释信息的描述15 6.3参数传递错误！未定义书签。 7.新一代ERP系统中的几个公共机制15 7.1删除完整性检查16 7.2状态管理错误！未定义书签。
7.3变更管理错误！未定义书签。 7.4权限控制错误！未定义书签。 7.5消息机制16 7.6编号管理16 7.7地址管理错误！未定义书签。 7.8长文本错误！未定义书签。 8.用例描述中用词规范16
1：总体用例 图 2：留言管 理 2-1:回复留言 用例描述: 用例名称：回复留 言用例标识号： 2-1
参与者：管理员简要说明：管理员对用户提交到系统的留言，进行浏览和回复。前置条件： 管理员已经登管理系统基本事件流：1．管理员鼠标点击“浏览留言”按钮，发出留言审核请求；2．系统提供系统中存储的留言，分页显示留言内容； 3. 管理员选择一条留言标题，点击浏览留言详细信息；4．管 理员可以在选择要回复的留言； 5. 管理员点击提交回复留言 6．用例终止；其他事件流A1：在按“提交”按钮之前，管理员随时可以按“返回”按钮，返回到浏览页面 异常事件流：1．提示错误信息，管理员确认；2．返回到留言管理页面。 后置条件：系统中的留言得到回复 注释：无 2-2:删除留言 用例描述: 用例名称：删除留言用例标识号：2-2 参与者：管理员简要说明：管理员对用户提交到系统的留言，进行浏览和删除前置条件： 管理员已经登管理系统基本事件流：1．管理员鼠标点击“浏览留言”按钮，发出浏览留言请求；2．系统提供系统中存储的经审核的留言，分页显示留言； 3. 管理员查看留言，点击删除按钮删除留言后重新列出留言； 7．用例终止；其他事件流A1： 在按“提交”按钮之前，管理员随时可以按“返回”按钮，返回到浏览
异常事件流：1．提示错误信息，管理员确认；2．返回到留言管理页面。 后置条件：系统中的留言被删除。 注释：无 3：管理帖子 3-1 回复帖子 用例描述: 用例名称：回复帖子用例标识号：3-1 参与者：管理员简要说明：管理员对用户提交到系统的帖子，进行浏览和回复帖子。前置条件：管理员已经登管理系统基本事件流：1．管理员鼠标点击“浏览帖子”按钮，发出帖子浏览请求；2．系统提供系统中存储的帖子，分页显示帖子内容； 3．管理员可以在选择要帖子的留言； 4. 管理员点击提交回复帖子5．用例终止；其他事件流A1： 在按“提交”按钮之前，管理员随时可以按“返回”按钮，返回到浏览异常事件流：1．提示错误信息，管理员确认；2．返回到帖子管理页面。 后置条件：系统中的帖子批准状态被修改。 注释：无
图书管理系统 UML建模与设计模式 实验报告 计算机与信息工程学院 一、实验目的 在熟悉用例概念与应用的基础上，掌握用例模型的建立，包括： 1．掌握用例图的建立。 2．掌握用例描述文档的编写。 3．掌握建模工具的使用。 二、实验内容 根据以下需求设计一个图书馆管理系统的用例图模型，包括：用例图和主要用例的描述文档。 基本功能要求： 图书管理：新书登记，图书查询，图书注销； 借阅管理：借书，还书，查询今日到期读者； 读者管理：增加读者、删除读者、查询读者、读者类别管理（可以设置不同类的读者，并使不同类读者对应不同类的图书流通参数，如可借册数，可借天数，可续借次数，可续借天数等）； 报表管理：包括图书借阅统计报表，被注销图书统计报表等；报表可以有多种格式可供选择；可以把报表输出到文件中，可以预览报表、打印报表等。 系统管理：系统管理员使用，包括用户权限管理（增加用户，删除用户，密码修改等），数据管理（提供数据修改、备份、恢复等多种数据维护工具），系统运行日志，系统设置等功能。 三、实验思想 （1）分析系统需求； （2）确定系统参与者：读者、图书管理员、图书管理系统； （3）确定系统用例；
四、实验结果 借阅人用例图： 图书系统管理员用例图：
图书管理员用例图： 1．用例名称：登录 用例描述：根据用户输入的用户名和密码判断用户的身份，赋予相应的权限。前置条件：无 后置条件：根据用户所有的权限进入相应的操作界面。 基本操作流程： 1输入用户名 2输入密码 2校验密码是否正确。 3根据用户身份进入相应的操作界面。 可选流程：如果密码不正确，提示重新输入密码； 如果用户名不正确，提示没有此用户。 2.用例名称：查询图书 用例描述：由读者进行操作，查询图书馆中有没有需要图书，如果有，显示该图书编号、书名、作者、出版日期、当前借阅状态等信息。 前置条件：以顾客身份登录 后置条件：无 基本流程： 1 以读者身份登录。 2输入图书的名称或作者名称。
图书管理系统用例文档--教 程文件 -标准化文件发布号：（9556-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII
作者：尤帅 信息工程学院 《软件模型》课程期中报告 学年： 2015—2016第一学期 专业：软件工程 班级： 小组成员： 课程教师： 完成时间： 2015年11月5日
图书馆信息管理系统 用例文档 成员： 日期：2015-11-05 目录 1. 前言 (5)
1.1编写目的 (5) 1.2内容概述 (6) 2.用例列表 (6) 3.用例图 (8) 3.1子系统（局部）用例图 (8) 3.1.1读者参与用例 (8) 3.1.2管理员管理用例 (9) 3.1.3数据用例 (10) 3.1.4登录用例整合 (10) 3.1.5账号信息管理整合 (11) 3.2系统用例图 (11) 4.用例描述 (12) 编写总结 (20)
1.前言 图书馆信息管理系统的需求获取过程中，根据分析系统和外部对象的交互当中所执行的行为序列，及场景的层次性描述，提取了相关用例。 本文档给出了需求获取阶段使用的用例列表和用例描述。1.1编写目的 整理和归类需求获取行为得到的消息。由于直接从用户的到的信息具有荣誉、遗漏、模糊、错误等，我们需要对他们进行分析并进行归类和系统化。 为详细的信息分析提供背景基础和上下文知识。由于软件系统的每项功能都依存于一定的背景和上下文环境，有利于开发者获取精准的信息进行系统开发。 在得到用户需求并将其转化成一个目标时，需要为目标组织信息，建立场景。用例就是一种场景的文化表现方式，实用叙述性的文本来描述场景。可以将解决方案用自然语言描述出来，便于用户理解，和用户达成共识，以便于进一步完善。
我发现，在OO和UML几乎一统天下的今天，仍有很多系统分析员对OO和UML一知半解，甚至包括很多已经使用了很久UML的系统分析员。 于是打算写一个系列文章，将多年来的工作经验做一个总结。对初学者起个启蒙作用，也希望抛砖引喻，与各路大虾共同探讨，共同提高。 这个系列文章将以我对OO和系统分析的理解为主，从UML基础开始，阐述面向对象的需求分析方法，过程，并以RUP为例，阐述如何将OO过程与软件过程有机结合在一起，做一个真正OO应用。 好了，今天是第一篇。想得很远，不知能否坚持下去，呵呵:lol: 用例是什么？其原始英文是usecase，直译过来就成了用例。这也是一个比较贴切的叫法了，从字面的直接理解就是使用的例子。另一种比较流行的定义是用例就是与使用者(actor)交互的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。 这个定义还是比较费解的，笔者在众多应聘者中发现很多使用用例来做需求的系统分析员，有的已经使用了两年以上，但仍不能把握用例的本质，虽然他们号称精通UML。 最具普遍意义的理解错误是认为用例就是功能的划分和描述，认为一个用例就是一个功能点。在这种理解下，用例变成了仅仅是较早前需求中功能框图的翻版，很多人用用例来划分子系统，功能模块和功能点。如果这样，用例根本没有存在的必要。有意思的是，造成这种理解错误的相当一部分原因却是因为对OO思想的理解不够深入，本质上说，把用例当成功能点的系统分析员脑子里还是面向过程的那一套思想，虽然他们在使用OO的工具，OO的语言，号称在做面向对象的开发，但过程的影子还没有从他们脑子里彻底抹去。 如果用例不是功能的话，它是什么呢？从定义上说，能给使用者提供一个执行结果的活动，不就是功能吗？我的回答是：错！功能是计算机术语，它是用来描述计算机的，而非定义需求的术语。功能实际描述的是输入-->计算-->输出。这让你想到了什么？DFD图？这可是典
1、兼容性测试 在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。测试目的 配置说明操作系统系统软件外设应用软件结果 服务器Window2000(S) WindowXp Window2000(P) Window2003 用例编号TestCase_LinkWorks_WorkEvaluate 项目名称LinkWorks 模块名称WorkEvaluate模块 项目承担部门研发中心-质量管理部 用例作者 完成日期2005-5-27 本文档使用部门质量管理部 评审负责人 审核日期 批准日期 注：本文档由测试组提交，审核由测试组负责人签字，由项目负责人批准。历史版本： 版本/状态作者参与者起止日期备注 V1.1 1.1. 疲劳强度测试用例 强度测试也是性能测试是的一种，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。 测试目的
测试说明 前提条件连续运行8小时,设置添加10用户并发 测试需求输入/动作输出/响应是否正常运行 功能1 2小时 4小时 6小时 8小时 功能1 2小时 4小时 6小时 8小时 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务 规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则 的实施是否恰当。主要测试技术方法为用户通过GUI（图形用户界面）与应用程序交互，对 交互的输出或接受进行分析，以此来核实需求功能与实现功能是否一致。 用例标识LinkWorks_ WorkEvaluate_02 项目名称https://www.doczj.com/doc/5c18769571.html, 开发人员模块名称WorkEvaluate 用例作者参考信息工作考核系统界面设计(2005_03_28).vsd 测试类型设计日期2006-9-27 测试人员 测试方法黑盒测试日期 用例描述 前置条件 编号权限 （并列 关系）测试项测试 类别 描述/输入/操作期望结果真实 结果 备注 00001 无列 表 页 面 导航栏导航 测试 浏览\点击导航连接详细正确导航页面所 在位置 00002 添加删除修 改按钮 添加修改删除按钮是否 可用 不可用 00003 接受、汇报按 钮 1）不是自己负责的数据 未考核之前能否接受 \汇报 不能 2）属于自己负责的未接 受之前时候是否可以 接受 能
用例描述 学生管理系统的用例描述；用例编号：001；用例名：系统管理员的登录；用例描述：系统管理员完成学生信息管理系统登录的整；参与者：系统管理员老师学生；前置条件：系统运行正常；后置条件：如果管理员登录成功，可以对学生的基本信；基本路径：；1，系统管理员，学生，老师输入用户和密码；2，然后系统管理员，学生，老师提交输入的信息；3，系统对系统管理员，学生和老师的用户和 学生管理系统的用例描述 用例编号：001 用例名：系统管理员的登录 用例描述：系统管理员完成学生信息管理系统登录的整个过程。 参与者：系统管理员老师学生 前置条件：系统运行正常。 后置条件：如果管理员登录成功，可以对学生的基本信息进行进行管理。包括：录入，查询，修改，删除。如果教师登陆成功，可以对学生的成绩进行管理。如果学生登录成功，可以查看个人的基本信息。如果登录未成功，则不能进行如上操作。 基本路径：
1，系统管理员，学生，老师输入用户和密码。 2，然后系统管理员，学生，老师提交输入的信息。 3，系统对系统管理员，学生和老师的用户和密码信息进行有效的检查。 4，检查通过，则返回带用户登录界面。 扩展点： 3a:密码输入错误 3a1:系统弹出输入错误的警告信息。 3a2:系统管理员，学生和老师离开或重新输入密码。 变异点： 无 补充说明：无 用例编号：002 用例名：查询学生的基本信息 用例描述：完成系统管理员对学生的基本信息查询的完整过程。 参与者：系统管理员 前置条件：登录成功 后置条件：系统给出学生的基本信息。系统管理员可以查询操作。
基本路径： 1. 系统管理员，进入查询学生基本信息界面，发送查询学生基本信息的请求。 2.界面Form向控制对象Control请求学生的基本信息，控制对象到数据库查询学生的基本信息。 3.查询学生基本信息界面对象从控制对象中取得所查询得到的学生基本信息Course。并返回到查询界面上显示所有的学生基本信息。 4. 系统管理员查询学生的基本信息。 扩展点： 4a:查询学生基本信息失败。 4a1: 系统弹出查询学生信息失败的警告信息。 4a2: 系统管理员离开或重新查询学生的基本信息。 变异点： 无 补充说明： 无 用例编号：003 用例名：修改学生的基本信息
用例图和用例描述设计实例 作者：ephyer 发表时间： 2004-09-09 18:01:35 更新时间： 2004-09-09 18:01:35 浏览：1954次 主题：电脑技 术 评论：0篇 地址：202.19 7.75.* :::栏目::: ? T hinkin g in jav a 学习 笔记 ? J A VA 基 础知识 ? U ML ? 软 件设计 师 ? 其 他类别 这里用我开发的一个家教网站来简单的分析用例图的画法和用例描述的 写法。这个网站我用UML 完整的分析一下，以下我提取了用例图和用例描述 的部分。这个家教网站分为前台客户系统和后台管理系统。 前台客户系统的用例图如下： 后台管理系统用例图如下： 对于用例描述，篇幅有限，我在这里只列了后台管理系统中的网站公告发布这个用例的描述。如下：
用例名称：用户登录 用例标识号：01 参与者：管理员、普通用户 简要说明： 参与者输入用户名、密码以及验证码，系统进行验证后，合法者登录系统，否则提供拒绝登录系统。 前置条件： 参与者已经打开系统的登录页面（login.jsp） 基本事件流： 1．参与者在用户名输入框里输入用户名 2．在密码框里输入密码 3．密码框下方显示验证码，验证码由4位数字构成，用户按原样输入验证码。 4．用户按登录后，系统验证参与者输入的有效性。 5．有效则进入系统的主界面。无效则提示相应错误给用户。 6．用例终止 其他事件流A1： 在按“登录”按钮之前，参与者可以随按“取消（或关闭）”按钮。 异常事件流： 1．提示错误信息，参与人确认 后置条件：进入的主界面main.jsp ,装载相应的数据 注释：（可选：记住用户）
旅游管理系统用例文档 一．参与人员 (1) 二．用例总图 (1) 三．具体用例说明 (1) 3.1 UCHL01 (1) 3.2 UCHL02 (1) 3.3 UCHL03 (1)
一．参与人员 班级学号姓名七班 54100727 常瑞娟七班 54100728 陈玉城七班 54100729 荣春雨七班 54100730 王彬彬二．用例总图
三．具体用例说明 UCHL02:预定客房 ?用例名称 预订客房 ?涉及的参与者 旅客，旅店信息库 ?用例描述： 旅客进入旅店管理系统的网站，按己所需，预订客房，登记个人信息 ?前置条件 旅客必须已经登录到网上预订页面 ?后置条件 旅客完成网上预订客房，旅店客房信息库更新 ?正常事件流： 1.旅客进入旅店管理系统； 2.查看旅店按季节和每周不同时间公布的价目表和空余的客房信息； 3.旅客选择需要的客房档次，输入自己的姓名，地址，联系电话， 有效证件号，房间类型和预订天数； 4.旅客提交预订信息； 5.旅客支付预定金； 6.旅店信息库更新这个信息，并在以后的视图中看到这个数据。
?备选事件流1：旅客更改预订信息 1.旅客查看当前预订信息； 2.旅客选择更改条目； 3.旅客重新输入预订信息； 4.旅店信息库更新这个信息，并在以后的视图中都可以看到。 ?非功能性需求 无 ?涉及约束 无 ?部署约束 旅客可以从个人电脑或服务台访问”预订客房”用例，如果是从客户端访问，则要考虑到客户端的防火墙 ?未解决的问题 采用何种费用支付方式 UCHL03:”管理旅客信息”用例文档 ?用例名称:管理旅客信息 ?用例标识: UCHL03 ?涉及的参与者:旅店工作人员,客房信息库 ?描述:旅店工作人员利用”管理旅客信息”用例来对旅客的要求进行 增删改。 客房信息库用这个用对所有旅客订房信息进行统一管理。