用例规约
- 格式:doc
- 大小:393.50 KB
- 文档页数:21
系统用例规约
系统用例规约是指对系统用例进行规范化描述的文档,包括用例的名称、编号、参与者、前置条件、后置条件、基本流程、扩展流程、异常流程等内容。
具体而言,系统用例规约需要包含以下内容:
1. 用例编号:每个用例都应该有一个唯一的编号,以便于管理和跟踪。
2. 用例名称:简短明了的用例名称,能够清晰地表达用例的功能。
3. 参与者:用例所涉及的各方参与者,包括主要参与者和次要参与者。
4. 前置条件:执行该用例之前必须满足的条件,如必须登录系统、必须有特定权限等。
5. 后置条件:执行该用例之后的系统状态,如生成订单、更新数据等。
6. 基本流程:用例的主要流程,包括各个步骤和参与者的交互。
7. 扩展流程:用例的可能扩展流程,通常用于描述一些特殊情况的处理方式。
8. 异常流程:用例的异常情况处理流程,包括可能出现的错误、异常和失败情况的处理方式。
总之,系统用例规约是一份详细描述系统用例的文档,能够帮助开发者更好地理解和实现系统功能,同时也能够让用户和参与者更清
晰地了解系统的功能和运行方式。
一、用例规约作业请根据中国工商银行网络银行的转账汇款的相关说明,试编写该用例的规格说明。
要求从中体会业务规则的作用和分析,并在自己的课题中分析充分详尽的业务规则。
注:新发布的用例一章的课件中,有个取款相关的用例规格说明,可参考。
1.安全提示:为了您的资金安全,请勿轻信陌生人通过网络聊天群、直播、电话、短信等方式进行的诱导性“投资理财”、代办大额信用卡或高额贷款、网购客服或快递进行退货等非正规渠道要求进行转账汇款,谨防被骗。
短信通知手续费将根据我行政策进行减免,请以实际扣款情况为准。
2.汇款类型:根据人民银行关于防范电信诈骗有关要求,我行为您提供“实时汇款、普通汇款、次日汇款”三种汇款方式选择。
对于“普通汇款”和“次日汇款”,您可在限定时间内通过手机银行或网银“转账汇款-查询汇款明细”进行撤销。
3.到账时间:行内汇款一般实时到账,7*24小时受理。
自2019年11月29日起100万元(含)以内跨行汇款,我行将优先通过网银互联系统汇出至收款行,一般实时到账,7*24小时受理。
100万元以上跨行大额汇款,工作日交易时间(前一日20:30-当日17:15)一般实时到达收款行;工作日(周一至周四)非交易时间(17:15-20:30)提交,系统预约至当日20:30后汇出;非工作日,系统将做预约处理,待下一工作日交易时间(一般为节假日最后一天20:30后)汇出。
准确时间以人民银行系统为准。
4.收款人信息:当您向其他银行汇款时,系统无法判断收款人信息是否准确,仅对信息格式进行校验,请您务必准确填写收款人户名、卡(账)号、收款行等信息,若因上述信息填写错误导致汇款失败,手续费不退回。
汇款成功后收款人信息将自动添加至“我的收款人”,方便您再次汇款操作。
您还可直接输入收款人户名、手机号向其汇款,若其手机号已绑定银行账户(含他行),则将实时汇入绑定账户;若其手机号未绑定银行账户,则系统将向收款人发送短信,根据收款人短信回复卡/账号汇入资金。
uml用例规约UML(统一建模语言)用例规约是指对系统中某一特定功能或行为的详细说明和定义。
用例规约被用来描述系统中所需的所有输入、输出、前置条件、后置条件和用例执行步骤等信息。
在UML中,用例规约通常被用来描述用例的所有方面,包括预期的行为和系统响应。
下面将详细介绍一下UML用例规约。
UML用例规约通常包含以下几个方面:1. 名称:用例规约必须具有唯一的名称,以便与系统中的其他用例区分开来。
2. 概述:用例规约需要简要描述该用例的作用和目的。
3. 前置条件:描述执行该用例前必须满足的条件,这些条件可以是系统状态、数据要求、前置操作等。
4. 后置条件:描述执行该用例后的状态。
即系统状态、数据状态、后置操作等。
5. 执行步骤:用例规约必须描述用例的详细执行步骤,包括所有输入和输出。
6. 异常情况:描述当某个步骤失败或者出现错误时,应该采取的措施。
7. 优先级:描述该用例的优先级,以便团队能够确定该用例的重要性。
在编写UML用例规约时,需要遵循一些规则:1. 用例规约必须与用例图中的用例匹配。
2. 确保用例规约中包含所有必要的信息,以便其他团队成员能够理解和实现该用例。
3. 用例规约必须是准确的和一致的,以便与其他用例规约和系统文档相匹配。
在编写UML用例规约时需要注意以下几点:1. 用例规约应该易于理解和阅读,以便其他团队成员能够理解该用例的目的和执行步骤。
2. 用例规约应该尽可能清晰和简明,同时包含所有必要的信息。
3. 用例规约应该是一致的,遵循团队的规范和标准,以便与其他文档相匹配。
总之,UML用例规约是系统中描述某一特定功能或行为的详细说明和定义。
编写UML用例规约需要遵循一些规则和注意事项,以便其他团队成员能够理解和实现该用例。
用例规约描述变更记录填表说明本文档的目的是依据《需求规格说明书》和系统原型,建立用例模型,并对用例模型进行具体描述。
用例规约描述是面向对象分析和设计的重要步骤。
用例规约描述需要进行评审。
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 登陆用例规约:。
系统用例规约
系统用例规约是指对系统用例进行详细的规范和说明,包括用例名称、用例编号、前置条件、基本流程、备选流程、后置条件、异常处理等内容。
其中,用例名称应简洁明了,用例编号应唯一标识每个用例,前置条件应明确用例执行所需的条件,基本流程应描述用例的正常执行流程,备选流程应描述可能出现的其他执行流程,后置条件应描述用例执行成功后的状态,异常处理应描述可能出现的异常情况及处理方式。
系统用例规约对于软件开发过程中需求分析及后续的测试工作都具有重要意义,能够确保系统用例的正确性和可靠性。
- 1 -。
1.注册功能用例的用例实现一、简要说明游客可注册为网上订餐系统的用户。
注册时只要填写登录用户名、密码、联系电子信箱、联系电话以及安全问题和答案六项信息即可。
注册后,用户可以继续填写个人详细信息及收获人信息,同时可以修改密码、查询及维护订单。
二、事件流基本流:1. 游客选择注册。
2. 系统返回一个注册页面。
3. 游客根据提示输入相应的注册信息。
4. 系统验证游客输入成功。
5. 游客提交注册信息。
6. 系统提示注册成功并返回首页。
(默认已登录)备选流:1. 游客输入信息和系统验证不一致(如字段长度超过系统设置等),系统给出相应的提示信息并返回注册页面。
2. 游客输入用户名是已注册用户名,系统给出提示并返回注册页面。
3. 系统异常,无法注册,并给出相应的信息(如网站维护等)。
三、前置条件游客申请注册。
四、后置条件游客注册成功成为会员五、扩展点无。
2.登录\注销用例的用例实现一、简要说明用户:已经注册成功的用户可以通过登录页面登录进入该网站。
登录之后可以实现订餐系统的设定功能。
管理员:管理员必须通过后台进行登录,登陆以后,可以在前台或者后台之间切换,更方便地对系统进行管理及维护。
不提供管理员注册功能,管理员只能在数据库中添加,以保证系统的安全性。
登录后,可在前台或者后台选择注销,以便安全退出系统。
二、事件流基本流:1. 该会员选择登录。
2. 系统返回一个登录页面。
3. 会员输入用户名、密码和验证码并提交。
4. 系统进行系统验证,验证成功,记录该用户为登录用户并返回主页面。
(表明该会员已登录。
)5. 会员选择“注销”。
6. 系统提示用户成功注销并返回网站首页。
7.管理员修改管理员个人资料和账号信息。
备选流:1.用户忘记密码,选择“找回密码”功能,进入找回密码用例。
2. 系统验证用户登录信息有错,提示用户重新登录。
3. 系统处理异常,系统给出相应的提示信息.。
4.管理员只能在后台运行。
三、特殊要求无。
四、前置条件该会员必须是本网站已注册的成员。
用例规约例子
以下是 6 条用例规约例子:
1. 咱就说,你去超市买东西,这不就是一个很常见的用例规约嘛!你知道自己要买啥,什么品牌、多少数量,这不就跟软件里的各种条件、步骤一样一样的嘛?比如说,你决定要买巧克力,然后选了某个牌子,接着看价格和重量,哎呀,这就跟程序里的各种设定和判断太像啦!
2. 你想想看,你每天早上起床后要做的一系列事情,也是个用例规约呀!刷牙、洗脸、换衣服,每一步都有先后顺序和特定的操作呢!就像软件运行时,一个步骤紧接着一个步骤,可不能乱了呀!比如你总不能先换衣服再刷牙吧,这多别扭呀!
3. 嘿,你知道煮饺子也是个好例子呢!先准备水,水开了下饺子,然后等饺子煮熟,捞出来,每一步都不能马虎呀!这在软件里不就相当于一个个明确的流程和规定嘛,水就像是输入,饺子煮熟就是输出,这过程多清晰啊!难道不是吗?
4. 你和朋友约着出去玩,这整个过程也是个用例规约呀!先商量去哪里,再确定时间,然后怎么碰面,一点都不能乱来呢!这不就跟程序里的流程规划一样嘛,一环扣一环的。
你再想想,如果商量不好,那可就玩不成啦,就像程序出错就运行不下去一样呀!真的好形象呀!
5. 哎呀,就连你写作业都是个典型的例子呀!先拿出本子和笔,再看题目,思考怎么做,然后开始写,最后检查。
这和软件中的用例规约简直如出一辙嘛!你可别小瞧这写作业的过程呢,像不像程序在一步步执行任务?
6. 你看那些运动员比赛,也是有他们的用例规约呀!比如跑步比赛,先站在起跑线,听口令,起跑,冲刺,每一步都很关键呀!这多像软件运行时的各种规定呀,每一个动作都得精确无误呀!不然怎么能赢得比赛呢,你说对吧?
我的观点结论就是:生活中到处都是用例规约的例子呀,真的太有意思啦!。
学籍管理系统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名用户对其的同一时刻的访问。
系统中的所有参预者均可以使用本用例登陆系统,要求输入合法的用户名和密码。
登录系统用例规约用例编号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、提示信息不充分,要求重新输入字段列表员工信息=姓名+性别+出生年月日+家庭住址+电话+籍贯+学历+照片+备注业务规划非功能需求补充说明删除员工信息的参预者是数据管理人员,用于删除酒店员工的详细信息。
反审核订单用例规约反审核订单用例规约用例名称:反审核订单参与者:管理员、客服前置条件:订单已经被审核通过并已经被记录在系统中。
正常流程:1.管理员或客服登录系统。
2.管理员或客服进入订单管理界面,找到需要反审核的订单。
3.管理员或客服点击反审核按钮。
4.系统提示反审核成功,并且将订单状态置为待审核状态。
5.系统记录反审核操作记录。
6.管理员或客服退出系统。
扩展流程:1a.如果订单状态已经发生了变化,管理员或客服无法进行反审核操作,系统提示无法反审核,并给出相应提示信息。
2a.如果管理员或客服在订单管理界面无法找到需要反审核的订单,系统提示未找到该订单,并给出相应提示信息。
3a.如果反审核操作失败,管理员或客服需要重新进行反审核操作,并找出失败的原因并进行处理。
4a.如果反审核成功后,订单状态没有被修改为待审核状态,管理员或客服需要重新进行反审核操作,并找出失败的原因并进行处理。
5a.如果系统在记录反审核操作记录时失败,管理员或客服需要手动记录反审核操作记录,并能够找出失败原因并进行处理。
其他问题:1.管理员或客服需要对需要反审核的订单进行严格审核,以免误操作导致不必要的损失。
2.管理员和客服需要对反审核操作进行记录,以方便后续查看和审计。
3.反审核操作需要符合公司内部规定,并且需要及时向上级汇报。
总结:反审核订单用例规约是一个必要的规定,可以帮助管理员和客服在需要进行反审核操作时更加规范和有效地操作。
在使用反审核功能时,需要注意前置条件和各种扩展流程问题。
同时,需要对反审核操作进行记录,以方便后续查看和审计。
UML用例图中的用例规约与系统需求细化与优化技巧引言:UML(Unified Modeling Language)是一种用于软件开发的建模语言,用例图是UML中的一种图表,用于描述系统的功能需求。
在用例图中,用例规约和系统需求细化是非常重要的环节,它们能够帮助开发团队更好地理解和设计系统。
本文将探讨用例规约和系统需求细化的技巧,并提出一些优化的方法。
一、用例规约的重要性用例规约是对用例的详细描述,包括前置条件、后置条件、基本流程和可选流程等。
它能够帮助开发团队更好地理解用户需求,准确地定义系统的功能。
用例规约的编写需要考虑以下几个方面。
1.1 准确性用例规约必须准确地描述用户需求,避免出现歧义和模糊的描述。
开发团队应该与用户充分沟通,确保用例规约能够准确地反映用户的期望。
1.2 完整性用例规约应该尽可能地包含所有可能的场景和流程,以覆盖用户的所有需求。
开发团队需要仔细分析用户需求,确保用例规约的完整性。
1.3 可读性用例规约应该易于理解和阅读,以便开发团队能够清晰地理解用户需求。
开发团队可以使用简洁明了的语言,避免使用过于复杂的术语和句子结构。
二、系统需求细化的技巧系统需求细化是将用户需求转化为系统需求的过程。
它需要开发团队对用户需求进行深入的分析和理解,并将其转化为具体的功能和约束。
以下是一些系统需求细化的技巧。
2.1 分解需求将大的需求分解为小的子需求,以便更好地理解和设计系统。
开发团队可以使用层次结构或树状图等方式将需求进行分解,并为每个子需求编写详细的描述。
2.2 确定优先级根据用户需求的重要性和紧急程度,确定需求的优先级。
开发团队可以与用户进行讨论,共同确定需求的优先级,以便在开发过程中有针对性地进行工作。
2.3 确定约束条件系统需求可能会受到一些约束条件的限制,如时间、成本、技术限制等。
开发团队需要明确这些约束条件,并将其纳入系统需求的范围内。
三、用例规约与系统需求细化的优化方法优化用例规约和系统需求细化可以提高开发效率和系统质量。
课程注册系统用例规约版本<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.这样,学生就可以通过删除或者添加新课程来修改所选的课程。
学生从可选课程列表中选择要添加的课程。
学生也可以从目前的课程表中选择要删除的课程。
加入购物车用例规约表1. 介绍随着电商平台的兴起,购物车成为了用户进行在线购物的重要工具之一。
购物车用例规约表描述了用户将商品加入购物车的过程及相关需求。
2. 用例名称加入购物车3. 参与者主要参与者:用户次要参与者:商品管理系统4. 前置条件用户已登录到电商平台账户,并浏览到想要购买的商品页面。
5. 后置条件商品成功加入购物车。
6. 触发条件用户点击“加入购物车”按钮。
7. 主成功场景7.1 系统显示商品详情页面。
7.2 用户点击“加入购物车”按钮。
7.3 系统检查用户是否已登录。
7.4 如果用户未登录,系统跳转至登录页面。
7.5 用户输入账号密码并登录。
7.6 系统将商品加入购物车。
7.7 系统更新购物车数量。
7.8 系统显示加入购物车成功提示信息。
7.9 系统返回商品详情页面。
8. 扩展场景8.1 用户未登录8.1.1 系统检查到用户未登录。
8.1.2 系统跳转至登录页面。
8.1.3 用户输入账号密码并登录。
8.1.4 系统将商品加入购物车。
8.1.5 系统更新购物车数量。
8.1.6 系统显示加入购物车成功提示信息。
8.1.7 系统返回商品详情页面。
8.2 商品已下架或不存在8.2.1 系统检查到商品已下架或不存在。
8.2.2 系统显示商品不存在或已下架提示信息。
8.2.3 系统返回商品列表页面。
8.3 购物车已满8.3.1 系统检查到购物车已满。
8.3.2 系统显示购物车已满提示信息。
8.3.3 系统返回商品详情页面。
9. 特殊需求9.1 用户必须登录才能执行加入购物车操作。
9.2 用户在加入购物车前,需要浏览到商品详情页面。
10. 常见问题10.1 为什么要登录才能加入购物车?用户登录可以保证购物车中的商品信息与用户账户绑定,方便后续的购买和管理。
10.2 为什么加入购物车后会显示购物车数量?显示购物车数量可以提醒用户购物车中商品的数量,方便用户随时查看和管理购物车。
10.3 为什么会提示购物车已满?购物车有一定的容量限制,超过限制后就无法再加入新的商品。
下单用例的用例规约
用例模型是由用例图和用例规约组成的。
一个完整的用例模型应该不仅仅包括用例图部分,还要有完整的用例规约部分。
用例规约是对每一个用例的详细描述,也就是说有多少用例,就要有多少用例规约。
一.用例图和用例规约对比
用例图只是在总体上用图形大致描述系统功能,简单、直观,但是细节缺失、不明确。
用例规约则是一个用例的详细文字描述,采用自然语言,对用例的细节进行详细的描述。
二.包含内容
1.简要说明
用例名称,用例编号,参与者,用例简述。
2.场景描述
触发器,前置条件,基本事件流,扩展事件流,结论,后
置条件。
3.其他事项
特殊需求,扩展点,优先级。
三.简要说明
用例名称:描述用例的意图或实现的目标,要与用例图中的用例名保持一致。
用例编号:用例的唯一标识符,建议以UC(Use Case)作为前缀。
参与者:描述用例的参与者有哪些,包括主要参与者和次要参与者。
用例简述:简要介绍用例的作用和目的。
用户登录用例图用例规约:用例名称:登录用例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.3角色:普通用户用例说明:该用例主要实现的功能是用户实现对联系人信息的修改操作前置条件:进入主界面基本事件流:参与者动作系统响应1.选择想要修改的联系人,然后点击“修改”按钮3.用户对联系人姓名、性别、出生日期、Email、职务、固定电话、手机、住址、备注信息进行修改,点击“确定”按钮2.系统响应点击事件,跳转至“修改联系人信息”界面5.系统对用户的输入进行判断,若合法,则弹出对话框,提示“修改联系人成功”其它事件流:无异常事件流: 5.1姓名未输入,系统给出提示对话框“必须输入姓名”5.2 Email未输入,系统给出提示对话框“必填”后置条件:修改信息成功,返回主界面删除联系人用例图用例规约:用例名称:删除联系人用例ID:IBM_ESHOP_002.4角色:普通用户用例说明:该用例主要功能是删除联系人,用例起始用户点击“删除”按钮前置条件:进入主界面基本事件流:参与者动作系统响应1.用户确定要的联系人,然后点击“删除”3.1.1若确定删除联系人,点击“确定”按钮;2.系统弹出对话框,给出提示信息“是否删除”3.1.2进入“删除联系人成功界面”3.2系统返回主界面3.1.1用户点击返回按钮。
3.1.2点击“取消”按钮,取消删除操作。
其它事件流:无异常事件流:暂无后置条件: 删除联系人成功查找联系人用例图用例规约:用例名称:查找联系人用例ID:IBM_ESHOP_002.4角色:普通用户用例说明:该用例主要功能是从列表中查看联系人信息,用例起始用户点击“查找”按钮前置条件:进入主界面基本事件流:参与者动作系统响应1.用户点击“查找”按钮3.用户可以根据选择分组名称,填写邮2.系统跳转至“查找联系人界面”4.系统查找数据库中的信息,若找到,箱、职位、姓名、手机。
生日任一项对查找人进行查找,则返回查找到的信息,若没有找到,什么都不返回。
其它事件流:无异常事件流:暂无后置条件: 查找联系人成功统计联系人用例图用例规约:用例名称:统计联系人用例ID:IBM_ESHOP_002.4角色:普通用户用例说明:该用例功能是统计联系人,用例起始用户点击“统计”按钮前置条件:进入主界面基本事件流:参与者动作系统响应1.用户点击“统计”按钮3.用户可以在此页面查看每个组的人数2.系统跳转至“统计联系人界面”统计联系人用例规约:提醒生日用例图用例规约:用例名称:统计联系人用例ID:IBM_ESHOP_002.4角色:普通用户用例说明:用例起始用户点击“生日统计”按钮前置条件:进入统计界面基本事件流:参与者动作系统响应2.系统跳转至“生日统计界面”1.用户点击“生日统计”按钮3.用户可以查看此页面每个月份的过生日人数其它事件流:无异常事件流:暂无发送邮件用例图用例规约:用例名称:发送邮件用例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系统取消用户操作其它事件流:无异常事件流:无后置条件:删除分组成功,返回主界面显示全部分组信息用例图用例规约:用例名称:显示全部分组信息搜索添加联系人用例规约:3.选择联系人,点击“批量添加”按钮(点击某一个联系人对应的“添加”按钮,执行3.1.1)4.系统将联系人保存到当前组中(系统保存失败,执行4.1.1)5.系统提示“保存成功”,并转向“组内联系人列表”页面其它事件流:参与者动作系统响应3.1.1点击某一联系人对应的“添加”按钮3.1.2系统将联系人保存到当前组(系统保存失败,执行4.1.1)3.1.3系统进行回顾操作,提示用户“添加失败”异常事件流: 4.1.1系统保存失败,提示“无法将联系人保存到当前组中”后置条件:将联系人添加到当前组中搜索添加联系人用例图用例规约:显示组内联系人用例图用例规约:用例名称:显示组内联系人用例ID:IBM_ESHOP_002.2角色:普通用户用例说明:用例主要实现查看某一分组的组内联系人前置条件:进入管理分组界面基本事件流:参与者动作系统响应1.进入界面,用户点击“维护组内联系人”按钮。
3.用户查看该组内所有联系人成员的详细信息2.系统响应点击事件,跳转至“搜索添加联系人”界面其它事件流:无异常事件流:无后置条件:查看联系人详细信息成功删除组内联系人用例图用例规约:用例名称:删除组内联系人用例ID:IBM_ESHOP_002.2角色:普通用户用例说明:用例主要实现对某一组内成员的删除操作前置条件:打开并进入管理分组界面基本事件流:参与者动作系统响应1.进入界面,用户点击“维护组内联系人”按钮。
3.用户根据复选框进行成员选择3.1 若仅删除一个人,则直接点击“删除”按钮3.2 可以根据复选框进行多人选择,然后点击“批量删除”按钮。
2.系统响应点击事件,跳转至“组内成员显示”界面4.系统给出提示对话框,显示“从分组移除联系人成功”其它事件流:无异常事件流:无后置条件:从组内删除联系人成功。
-可编辑修改-。