一,用例模型
1,系统用例图
2,开单用例分析
用例名:销售开单
主要参与者:收银员
主成功场景:
(1),收银员开始新的一次销售
(2),收银员依次录入商品条目,选择数量(默认1)
(3),系统总金额随商品的录入不断刷新
(4),收银员录入完毕,确认结账
(5),系统创建交易信息表,并自动记录交易时间,等待客户支付
扩展:
2a.收银员录入错误商品或者客户不需要某个商品
1.主管或者高权限人员登陆系统
2.主管或者高权限人员删除该条商品录入信息
3.主管或者高权限人员退出系统
4.系统显示回销售画面
5.收银员进行下一个商品的录入
2-5a.客户取消交易
1.主管或者高权限人员登陆系统
2.主管或者高权限人员取消交易,删除交易信息表
3.主管或者高权限人员退出账户
4.系统恢复初始销售状态,等待新一次的交易
2-5b.客户要求取消某件商品
1.主管或者高权限人员登陆系统
2.主管或者高权限人员删除该条商品录入信息
3.主管或者高权限人员退出系统
4.系统删除交易信息表,并重新执行步骤6
5a.客户请求挂单
1.收银员选择挂单选项
2.系统保存交易信息表
3.系统恢复到步骤1
二,补充性规格说明
简介
本补充规约列出了不便于在用例中获取的系统需求。补充规约和用例模型一起记录关于系统的一整套需求。
本文档并不是终稿,会随项目推进而不断优化。
功能性
1. 用户单位查询。
根据业务代号查询业务办理的基本信息和办理进展。
2. 流程控制。
管理员可以查询已有的流程定义,并可以部署新的流程。
3. 设备进口管理方工作人员可以执行一个流程,创建一个新的流程实例。
4. 设备进口管理方和外贸公司工作人员可以采取具体的任务执行工作。
可行性
桌面用户界面应与Window 2000、XP、win7兼容。。
可靠性
系统在每周7天,每天24小时内都应是可以使用的。
宕机的时间应少于10%。
系统重启时间少于1分钟。
性能
1. 系统将能在10秒钟内提供对数据库的访问。
2. 系统必须能够在2分钟内完成所有事务的80%。
可支持性
可扩展支持条形码扫描器等外围设备。
安全性
系统必须能防止非授权用户执行非授权操作。
设计约束
系统必须提供基于Windows桌面的接口。
关键字体应一米外可视(例如总金额),避免收银员长时间而视觉疲劳。
有键盘快捷键,便于收银员提高工作效率。
界面设计,应简洁易懂,颜色不宜太多,避免收银员长时间而视觉疲劳。
PS:输入设计见下一篇博客~谢谢~