超市管理系统软件需求说明书.docx
《超市管理系统软件需求说明书.docx》由会员分享,可在线阅读,更多相关《超市管理系统软件需求说明书.docx(14页珍藏版)》请在冰点文库上搜索。
超市管理系统软件需求说明书
超市管理系统软件需求说明书
超市治理系统需求分析说明书
1、项目打算
1.1系统开发目的
(1)大大提精湛市的运作效率;
(2)通过全面的信息采集和处理,辅助提精湛市的决策水平;
(3)使用本系统,能够迅速提升超市的治理水平,为降低经营成本,提高效益,增强超市扩张力,提供有效的技术保证。
1.2背景说明
21世纪,超市的竞争也进入到了一个全新的领域,竞争已不再是规模的竞争,而是技术的竞争、治理的竞争、人才的竞争。
技术的提升和治理的升级是超市业的竞争核心。
零售领域目前呈多元进展趋势,多种业态:
超市、仓储店、便利店、特许加盟店、专卖店、货仓等相互并存。
如何在猛烈的竞争中扩大销售额、降低经营成本、扩大经营规模,成为超市营业者努力追求的目标。
1.3项目确立
针对超市的特点,为了关心超市解决现在面临的问题,提高小型超市的竞争力,我们将开发以下系统:
前台POS销售系统、后台治理系统,其中这两个子系统又包含其它一些子功能。
1.4应用范畴
本系统适应于各种小型的超市。
1.5定义
(1)商品条形码:
每种商品具有唯独的条形码,关于某些价格一样的商品,能够使用自定义条形码。
(2)交易清单:
包括交易的流水账号、每类商品的商品名、数量、该类商品的总金额、交易的时刻。
(3)商品积压:
在一定时期内,远无法完成销售打算的商品会造成积压。
(4)促销:
在一定时期内,某些商品会按低于原价的促销价格销售。
库存告警提示:
当商品的库存数量低于库存报警数量时发出提示。
(5)盘点:
运算出库存、销售额、盈利等经营指标。
1.6参考资料
《SQLServer2000有用教程》范立南编清华大学出版社
《软件工程导论》重庆大学出版社
《软件工程理论与实践》ShariLawrencePfleeger编清华大学出版社
2逻辑分析与详细分析
2.1系统功能
(1)零售前台(POS)治理系统,本系统必须具有以下功能:
✧商品录入:
依照超巿业务特点制定相关功能,能够通过输入唯独编号、扫描条形码、商品名称等来实现精确或模糊的商品扫描录入。
该扫描录入方法能够充分保证各种电脑操作水平层次的人员均能准确快速地进行商品扫描录入。
✧收银业务:
通过扫描条形码或者直截了当输入商品名称(关于同类多件商品采纳一次录入加数量的方式)自动运算本次交易的总金额。
在顾客付款后,自动运算找零,同时打印交易清单(包括交易的流水账号、每类商品的商品名、数量、该类商品的总金额、交易的时刻)。
✧安全性:
OS登陆、退出、换班与操作锁定等权限验证爱护;断电自动爱护最大限度防止意外及恶意非法操作。
✧独立作业:
有的断网收银即在网络服务器断开或网络不通的情形下,收银机仍能正常作业
(2)后台治理系统,本系统必须具备以下功能:
✧进货治理:
依照销售情形及库存情形,自动制定进货打算(亦可手工制定修改),能够幸免盲目进货造成商品积压。
按打算单有选择性地进行自动入库登记。
综合查询打印打算进货与入库记录及金额。
✧销售治理:
商品正常销售、促销与限量、限期及禁止销售操纵。
综合查询各种销售明细记录、交结账情形等。
按多种方式统计生成销售排行榜,灵活观看和打印商品销售日、月、年报表。
✧库存治理:
综合查询库存明细记录。
库存状态自动告警提示。
如库存过剩、少货、缺货等。
软件为您预警,幸免库存商品积压缺失和缺货。
库存自动盘点运算。
(3)系统结构
小型超市零售治理系统
图1系统总体结构图2模块子系统结构
(5)进货治理:
图3进货治理
功能描述:
进货治理子系统能够依照库存自动指定进货打算,进货时自动等级,以及提供查询和打印打算进货与入库记录的功能。
(6)销售治理:
图4销售治理
功能描述:
销售治理子系统能够操纵某商品是否承诺销售,查询每种商品的销售情形并产生年、月、日报表,同时能够生成销售排行榜。
(7)库存治理:
图5库存治理
功能描述:
库存治理子系统提供查询库存明细记录的差不多功能,并依照库存的状态报警,以及自动盘点运算。
2.2流程图
前台治理系统
图6顶层DFD图
图7第0层DFD图
图8第1层DFD图
2.3户类型与职能
(1)职员(营业员):
✧通过商品条形码扫描输入商品到购买清单
✧操作软件运算交易总金额
✧操作软件输出交易清单
(2)超市经理
✧操作软件录入商品,供货商,厂商
✧操作软件制定进货打算
✧查询打印打算进货与入库记录
✧操作软件操纵商品销售与否
✧查询打印销售情形
✧操作软件生成销售排行榜
✧查询库存明细记录
✧依照软件发出的库存告警进行入货
✧操作软件进行盘点运算
(3)总经理:
✧差不多信息登记治理
✧职员操作权限治理
✧客户销售权限治理
2.4系统开发步骤
✧确定参与者和相关的用况
✧为每个用况设计过程
✧建立顺序图,确定每个脚本中对象的协作
✧创建类,确定脚本中的对象
✧设计,编码,测试,集成类
✧为过程编写系统测试案例
✧运行测试案例,检验系统
2.5系统安全问题
信息系统尽管功能强大,技术先进,但由于受到自躯体系结构,设计思路以及运行机制等限制,也隐含许多不安全因素。
常见因素有:
数据的输入,输出,存取与备份,源程序以及应用软件,数据库,操作系统等漏洞或缺陷,硬件,通信部分的漏洞,企业内部人员的因素,病毒,“黑客”等因素。
因此,为使本系统能够真正安全,可靠,稳固地工作,必须考虑如下问题:
为保证安全,不致使系统遭到意外事故的损害,系统因该能防止火,盗或其他形式的人为破坏。
✧系统要能重建
✧系统应该是可审查的
✧系统应能进行有效操纵,抗干扰能力强
✧系统使用者的使用权限是可识别的
3基于UML的建模
3.1语义规则
用例模型(usecasesview)(用例视图)的差不多组成部件是用例(usecase)、角色(actor)和系统(system)。
用例用于描述系统的功能,也确实是从外部用户的角度观看,系统应支持哪些功能,关心分析人员明白得系统的行为,它是对系统功能的宏观描述,一个完整的系统中通常包含若干个用例,每个用例具体说明应完成的功能,代表系统的所有差不多功能(集)。
角色是与系统进行交互的外部实体,它能够是系统用户,也能够是其它系统或硬件设备,总之,凡是需要与系统交互的任何东西都能够称作角色。
系统的边界线以内的区域(即用例的活动区域)则抽象表示系统能够实现的所有差不多功能。
在一个差不多功能(集)差不多实现的系统中,系统运转的大致过程是:
外部角色先初始化用例,然后用例执行其所代表的功能,执行完后用例便给角色返回一些值,那个值能够是角色需要的来自系统中的任何东西。
UML:
是一种标准的图形化建模语言,它是面向对象分析与设计的一种标准表示;它不是一种可视化的程序设计语言而是一种可视化的建模语言;不是工具或知识库的规格说明而是一种建模语言规格说明是一种表示的标准;不是过程也不是方法但承诺任何一种过程和方法使用它。
用例(usecase):
参与者(actor):
3.2UML模型
3.21系统UML模型
3.22子系统UML模型
(1)零售前台(POS)治理系统用例视图
(2)后台治理系统用例视图
4、超市销售系统概念设计文档
(1)系统ER图
(2)系统ER图说明
1)每个顾客能够购买多种商品,不同商品可由不同顾客购买;
2)每个供货商能够供应多种不同商品,每种商品可由多个供应商供应。
5小结
✧和传统治理模式相比较,使用本系统,毫无疑问会大大提精湛市的运作效率,辅助提精湛市的决策水平,治理水平,为降低经营成本,提高效益,减少差错,节约人力,减少顾客购物时刻,增加客流量,提高顾客中意度,增强超市扩张能力,提供有效的技术保证。
✧由于开发者能力有限,加上时刻仓促,本系统难免会显现一些不足之处,例如:
✧本系统只适合小型超市使用,不能适合中大型超市使用;
✧超市治理系统涉及范畴宽,要解决的问题多,功能复杂,实现困难,但由于限于时刻,本系统只能做出其中的一部分功能;
关于以上显现的问题,我们深表歉意,如发觉还有其它问题,期望老师批判指正。