汽车销售管理系统软件需求规格说明.docx
- 文档编号:27882139
- 上传时间:2023-07-06
- 格式:DOCX
- 页数:17
- 大小:64.19KB
汽车销售管理系统软件需求规格说明.docx
《汽车销售管理系统软件需求规格说明.docx》由会员分享,可在线阅读,更多相关《汽车销售管理系统软件需求规格说明.docx(17页珍藏版)》请在冰豆网上搜索。
汽车销售管理系统软件需求规格说明
汽车销售管理系统
软件需求规格说明
学校:
宁夏大学
学院:
数学计算机学院
年级:
09级7班
专业:
软件工程
指导老师:
杨萍
姓名:
12009242530周海东
12009242531周健
12009242534尤欢
12009242539李可新
D.3软件需求规格说明
D.3.1介绍
1.目标
公司通过该“汽车销售管理系统”在两到四个季度可以使公司销售管理的所有流程都有所提高。
首先,运作费用减少50%。
尽可能的减少了公司成本,使利润增加80%。
其次,员工平均工作量也降低了40%。
有效提高了劳动力的价值。
再次,为顾客在购车环节节省时间80%。
这样也不会让顾客在购车时感到程序繁琐。
最后,通过顾客对销售管理系统的满意度对其进行适度的调整,以致达到更高的销售水平。
2.项目范围和产品特性
汽车销售管理系统根据客户需要主要根据实际需求,实现了从客户预约、报价、订购、售后服务等多个环节数据的跟踪管理服务。
“汽车销售管理系统”可以根据不断更新的汽车数据向顾客展示车辆信息、图片、视图等,并根据市场变动向顾客推荐最新的汽车信息与款型,介绍其性能。
然后根据顾客反馈的信息(用途、价位等)向其推荐合适的车型以及给出合理的建议,如果客户满意的话,由专业的顾问跟客户预约到公司试车的时间。
最后本系统可以根据公司的销售的情况,对销售量进行统计,并显示出销售业绩最好的车型及相关的信息(车辆信息、顾客信息),以便更好的掌握市场销售动向。
D.3.2总体描述
1.产品远景规划
“汽车销售管理系统”是一个现代化的新系统,它取代了繁琐的客户购车方式,可以不用打很多电话,可以不用到处跑去选择自己喜欢的车辆。
图1.1显示了“汽车销售管理系统”的关联图它演示了外部实体和系统接口。
期望系统能够演化出更多的版本,最终体现出更好的效果。
客添加客户添加信息
户车辆信息客户进货
订信息管理信息加
客车添信息
户退货
退添加
货
车车辆
车辆车辆销售车辆进货
添加密码管理退货退货辆退结帐
用户修改用户查询查询退货销货
车辆车辆车辆车辆售结
系统设定
售后管理
进货销售库存销售结帐帐
退出登录查询查询查询排行结帐
图1.1“汽车销售管理系统”的关联图
2.用户类和用户特性
用户类
描述
客户
客户是一个消费群体,他们希望通过公司的“汽车销售管理系统”订购自己需要的车辆款型,以至于送货上门。
有100名消费的客户,其中大约有65%的客户都会使用“汽车销售管理系统”来订购车辆(大致估计的数据),其中50%的客户是直接在家里连网订购的,所以可见“汽车销售管理系统”的方便
前台工作人员
公司的销售部门目前雇佣了大约30名“汽车销售管理人员”,他们从“汽车销售管理系统”接受订单并收取定金,准备车辆,按照客户要求的送货时间进行发货,销售部门的工作人员需要接受培训,学会如何使用计算机、相应的浏览器和“汽车销售管理系统”
技术主管
技术部门主管,他负责建立并维护(增加、删除、更新)“汽车销售管理系统”的各项菜单,例如:
菜单中有效的送车时间;车库中车辆款型、数量的情况
售后服务人员
售后服务人员,当前台接受订单并确定要发货后就会将相关的信息发送给售后部,售后就会根据客户的请求时间进行发货,并且还要根据客户所定的售后各项套餐定期给予相应的服务
3.运行环境(operatingenvironment,OE)
OE-1:
“汽车销售管理系统”的操作将通过web浏览器完成:
MicrosoftInternetExplorer版本8.0和9.0,,MacromediaDreamwear8.0。
OE-2:
“汽车销售管理系统”将运行在一个服务器中,该服务器运行当前由公司批准的ftp和http。
OE-3:
“汽车销售管理系统”将允许用户通过公司内联网来访问,如果用户被授权在公司的外部穿过防火墙来访问,那么用户也可以在家里通过Internet来访问改系统。
4.设计和实现的约束条件(constraint)
CO-1:
系统的设计、编码和维护文档将遵照ProcessImpactIntranetDevelopmentStandard(ProcessImpact公司内联网开发标准)版本1.3【2】。
CO-2:
系统将采用公司标准的当前Oracle数据引擎库。
CO-3:
所有HTML代码将遵守HTML4.0标准。
CO-4:
所有脚本都用Perl语言来编写。
5.用户文档(UserDocumentation,UD)
UD-1:
系统将提供一个分层的和跨越连接的html联机帮助系统,它描述并演示了所有系统功能。
UD-2:
如果有一个用户第一次使用该系统,系统可根据用户的要求,提供一个联机教程,这样用户可以使用静态教程菜单来具体实现一下如何订餐。
系统不会将采用的这一模板的订餐订单储存到数据库中,也不会将这种订单提交给销售部门。
6.假设(ASsumption)和依赖(DEpendency)
AS-1:
只要是要求员工在岗的每一个工作日,销售部门的前台、售后都会营业。
DE-1:
“汽车销售管理系统”的运行依赖于“刷卡缴费系统”所做出的变更,他接受用“汽车销售管理系统”订购车辆的付费请求。
DE-2:
“汽车销售管理系统”的运行依赖于“销售部门库存系统”所做出的变更,当接受“汽车销售管理系统”订单后,它更新车辆数量、款式的有效性。
D.3.3系统特性
1.订购车辆
(1)描述和优先级
客户的身份的到验证之后,他们就可以订购自己喜欢的车辆,并可以要求送货到指定的地点,也可以自行去公司领取。
只要在规定的期限内客户可以随时取消或改变订单。
优先级为最高。
(2)刺激/响应序列
刺激:
客户请求订购车辆可以一辆或者是多辆。
响应:
系统向客户询问订车细节、售后套餐和送货说明。
刺激:
客户请求改变订单。
响应:
如果订单的状态是可以点击(即在规定改变的时间内),则系统允许用户编辑以前的订单。
刺激:
客户请求取消菜单。
响应:
如果订单的状态是可以点击(即在规定改变的时间内),则系统取消订单。
(3)功能性需求
Order.place
登陆到“汽车销售管理系统”的客户可以通过该系统订单,订一份或者多份
Order.place.Register
系统将确认订单的客户所注册付费是一次付清还是分期付费,或是刷卡
Order.place.Register.No
如果客户没有注册则不能继续订购车辆
Order.place.Date
系统将提示客户输入送车日期
Order.place.Date.Cutoff
如果订购的日期是当前的日期,而订购时间已经过了截止时间,那么系统将通知客户订购太晚了,今天已经不能订购了,客户可以改变订购日期,或者也可以取消订单
Order.Deliver.Select
客户可以请求只是订购车辆或是还要求送货上门
Order.Deliver.Location
如果订单是送货上门,送货的日期是有效的时间,那么客户将提供一个有效的送货地点
Order.Deliver.Notimes
如果送货日期是无效的,那么系统将通知客户,客户可以取消订单也可以自行去接收
Order.Deliver.times
系统将显示订购日期剩余的有效送货时间,客户可以从显示的送货时间中选择一个时间,也可以自行去接收,或者取消订单
Order.Menu.Date
系统将显示指定日期的菜单
Order.Menu.Available
当前的日期的菜单只显示至少在销售部门存货的一个供应库有货
Order.Units.car
系统允许客户表明他希望订购的车辆款型、数量
Order..Units.Multiple
系统允许用户订购多份同样的餐,但其最大的份数只能是库存中有效份数的最小值
Order..Units.TooMany
如果客户所订购的车辆数超过了库存的数量,那么系统会提示客户他所能订购的车辆最大数目
Order..Units.Change
如果车库中的存货不能够满足客户的订购数量,那么客户可以改变所定车辆的数目,也可以取消订单
Order.Confirm.Display
如果客户表明他不想再订购了,那么系统就会显示一个总菜单,标明客户所订购的车辆信息,以及应该支付多少费用
Order.Confirm.Prompt
系统提示客户确认订单
Order.Confirm.Not
如果客户不确认订单,则客户可以继续编辑订单,也可以取消订单
Order.Confirm.More
客户可以通过系统再另外订单,可以使同一天的,也可以是不同天的。
Order.pay.Method
当客户标明他确认订购时,系统就会提示用户选择一种付费方式
Order.pay.Deliver
如果送货上门,客户可以选择现金支付余款
Order.pay.Pickup
如果客户选择自行去接收,那么系统就会提示客户付费方式
Order.pay.Details
系统将显示所订购的车辆数目、费用、付费方式和送货说明
Order.pay.Confirm
客户可以确认订单,也可以请求编辑订单,或者也可以请求取消订单
Order.pay.Confirm。
Deduct
如果客户确认订单,并选择直接刷卡,那么系统将向“刷卡缴费系统”发出一个付费请求
Order.pay.Confirm.Ok
如果付费请求被接受,那么系统将显示一条消息来确认订单已经接受,消息中会提示刷卡(输入自己的卡号)
Order.pay.Confirm.NG
如果付费请求被拒绝,系统将显示一条消息来说明拒绝的理由,客户可以取消订单,也可以改变为直接去公司接收
Order.Done
当顾客确认了订单时,系统会将下面几步座位一个事务来处理
Order.Done.Store
将这个订单分配一个有效的订单号并储存这一订单
Order.Done.Inventory
向“汽车销售管理系统”发送一条消息,包括订单的信息
Order.Done.Menu
对库存进行更新,以便其他客户进行选择
Order.Done.times
对有效的送货时间进行更新
Order.Done.patron
向客户发送电子邮件消息,消息包括订购车辆和支付费用的有关信息
Order.Done.Cateteria
向售后的工作人员发一个消息,包括客户的订单有关信息(送货日期、售后套餐等)
Order.Done.Failure
如果Order.Done中一步不成功,则系统回滚事务,通知用户,并说明失败的原因
Order.Previous.Period
系统允许客户浏览之前的所有点单
Order.Previous.Reorder
客户可以重新再够任何一款车型,只要订单中的所有条目在菜单中有效即可
2.创建、浏览、修改和删除订单
(该范例不提供细节)
3.注册个人的有关信息
(该范例不提供细节)
4.请求送货
(该范例不提供细节)
5.创建、浏览、修改和删除销售部门的菜
(该范例不提供细节)
D.3..4外部接口需求
1.用户界面(UserInterfaces,UI)
UI-1:
“汽车销售管理系统”的屏幕画面将遵照公司Internet应用程序界面的标准
UI-2:
系统对所显示的每个HTML网页都提供帮助链接,解释如何使用这些网页。
UI-3:
web页面的全部导航和车辆条目选择。
除了综合使用鼠标和键盘共同完成外,还可以通过键盘单独来完成。
2.硬件接口
硬件接口还没有确定
3.软件接口
SI-1:
汽车销售存货系统
SI-1.1:
“汽车销售管理系统”通过程序界面向“汽车销售存货系统”发送所订购的车辆数目和款型。
SI-1.2:
“汽车销售管理系统”将轮询“汽车销售存货系统”,以确定请求的车辆是否有效。
SI-1.3:
当“汽车销售管理系统”通知“汽车销售存货系统”某款车型没有货时,“汽车销售存货系统”会从库存菜单上将其删除。
SI-2:
“刷卡缴费系统”。
“汽车销售管理系统”通过程序界面与“刷卡缴费系统”进行通信,完成下面这些操作:
SI-2.1:
允许客户通过刷卡进行缴费的方式。
SI-2.2:
允许客户取消通过刷卡进行缴费的方式。
SI-2.3:
检查客户是否注册选择刷卡缴费的额方式。
SI-2.4:
为所订购的车辆提交付费请求。
SI-2.5:
退还全部或部分上面的费用,其原因是因为客户拒绝的所订购的车辆,或对其不满,也可能是没有按照客户的要求进行送货。
4.通信接口(CommunicationsInterfaces,CI)
CI-1:
“汽车销售管理系统”将向客户发送电子邮件消息,以确定收到订单、价格和套餐说明。
CI-2:
“汽车销售管理系统”向客户发送电子邮件消息,以报告订单接受之后订单中或送货中存在的问题。
D.3.5其他非功能性需求
1.性能(PErformance)需求
PE-1:
客户可以随时浏览本系统网页,系统能适应1000用户。
PE-2:
系统生成的所有web网页,通过64kbps的调制解调器在不超过三秒的时间内可以全部下载下来。
PE-3:
用户提交了查询后,对查询的响应时间不能超过3秒,在此时间内要将查询结果显示在屏幕上。
PE-4:
用户向系统提交信息后,系统将在4秒内向用户显示确认消息。
2.防护性需求
防护性需求还没确定。
3.安全性(SEcurity)需求
SE-1:
所有涉及功能信息或个人身份信息的网络事物,都要进行加密操作。
SE-2:
除浏览菜单外,用户必须登录到“汽车销售系统”才能完成其他所有操作。
SE-3:
客户的登录受计算机系统访问控制策略限制。
SE-4:
汽车销售系统的销售人员,只有那些授权为管理员的成员,才能通过系统创建或编辑汽车信息。
SE-5:
只有那些被授权可以在家访问公司内联网的用户,才可以在公司以外的地方使用“汽车销售系统”。
SE-6:
系统只允许客户浏览他们自己以前的订单,而不能浏览其他顾客的订单。
4.软件质量属性
Availability(可用性)-1:
“汽车销售系统”在任何时间内都可以被客户访问。
Robustness(健壮性)-1:
如果在订单得到确认或取消之前,用户和系统的链接中断,那么用户应该能通过“汽车销售系统”恢复不完整的订单。
D.3.6附录A数据字典和数据模型
预约说明=顾客名字
+顾客电话号码
+顾客户籍地
+试驾日期
+客户指定顾问
顾问ID号=*汽车顾问在公司里的ID号;是由6个字符数字组成的字符串*
汽车款式描述=*汽车款式的文本描述,最多1M字节;汽车款式的图片描述,最多20M字节;汽车款式的视频描述,最多100M字节*
汽车价格=*一款汽车的税前费用,以人民币计算*
购车日期=*试驾或取车日期:
格式为MM/DD/YYYY;如果取车截止日期在当前日期之后,则取车的默认值为当前日期,否则为预定日期;取车日期不能在当前日期之前*
订单=订单号
+订单日期
+试驾日期
+试驾车型
+订单状态
订单号=*系统为接受的每一个订单分配一个惟一的、顺序的整数;初始值是1*
订单状态=[未完成|已完成|已准备|已试驾|已购车|一取消]
结算购车款=车辆价格
+付费方式
车辆信息=车辆信息日期
+1:
m{汽车款式}
车辆信息日期=*某一特定的车辆信息的有效日期;格式是MM/DD/YYYY*
车辆信息条目=车辆条目描述
+车辆条目价格
+车辆条目配置
+车辆条目颜色
+车辆条目排量
订单截止日期=*所有订单必须在此之前提交的具体时间*
订单日期=*顾客提交订单的日期;格式是MM/DD/YYYY*
所订的汽车条目 =车辆条目
+订购数量
顾客 =顾客名字
+顾问ID号
+顾客电话号码
+顾客地点
顾客电子邮件
顾客电子邮件=*提交订单的顾客的电子邮件地址;由50个字母数字组成*
顾客地点=*提交订单的顾客的户籍地;由50个字母数字组成*
顾客名字=*提交订单的顾客的名字;又30个字母数字组成*
顾客电话号码=*提交订单的顾客的电话号码;格式为AAAA-NNNN xXXXX,分别表示区号、电话局号、号码和扩展号码*
所付购车款=*以人民币表示的一个订单的总价格*
订车数量=*顾客订的每一辆车型条目的个数;默认值为1;最大值为目前存货量*
图D.2是“汽车销售系统”的部分数据模型,展示了数据字典中描述的实体以及它们之间的关系。
付款
请求
选择
车型
包含
所有车辆
顾客
订车 包括 所定车辆
订单
付款
付款
图D.2“汽车销售系统”部分数据模型
D.3.7 附录B分析模型
顾客取消不收费
顾客取消不收费
顾客拒绝,因为
对车辆不满 顾客取消不收费
图D.3订单状态的状态转换图 出师表
两汉:
诸葛亮
先帝创业未半而中道崩殂,今天下三分,益州疲弊,此诚危急存亡之秋也。
然侍卫之臣不懈于内,忠志之士忘身于外者,盖追先帝之殊遇,欲报之于陛下也。
诚宜开张圣听,以光先帝遗德,恢弘志士之气,不宜妄自菲薄,引喻失义,以塞忠谏之路也。
宫中府中,俱为一体;陟罚臧否,不宜异同。
若有作奸犯科及为忠善者,宜付有司论其刑赏,以昭陛下平明之理;不宜偏私,使内外异法也。
侍中、侍郎郭攸之、费祎、董允等,此皆良实,志虑忠纯,是以先帝简拔以遗陛下:
愚以为宫中之事,事无大小,悉以咨之,然后施行,必能裨补阙漏,有所广益。
将军向宠,性行淑均,晓畅军事,试用于昔日,先帝称之曰“能”,是以众议举宠为督:
愚以为营中之事,悉以咨之,必能使行阵和睦,优劣得所。
亲贤臣,远小人,此先汉所以兴隆也;亲小人,远贤臣,此后汉所以倾颓也。
先帝在时,每与臣论此事,未尝不叹息痛恨于桓、灵也。
侍中、尚书、长史、参军,此悉贞良死节之臣,愿陛下亲之、信之,则汉室之隆,可计日而待也
。
臣本布衣,躬耕于南阳,苟全性命于乱世,不求闻达于诸侯。
先帝不以臣卑鄙,猥自枉屈,三顾臣于草庐之中,咨臣以当世之事,由是感激,遂许先帝以驱驰。
后值倾覆,受任于败军之际,奉命于危难之间,尔来二十有一年矣。
先帝知臣谨慎,故临崩寄臣以大事也。
受命以来,夙夜忧叹,恐托付不效,以伤先帝之明;故五月渡泸,深入不毛。
今南方已定,兵甲已足,当奖率三军,北定中原,庶竭驽钝,攘除奸凶,兴复汉室,还于旧都。
此臣所以报先帝而忠陛下之职分也。
至于斟酌损益,进尽忠言,则攸之、祎、允之任也。
愿陛下托臣以讨贼兴复之效,不效,则治臣之罪,以告先帝之灵。
若无兴德之言,则责攸之、祎、允等之慢,以彰其咎;陛下亦宜自谋,以咨诹善道,察纳雅言,深追先帝遗诏。
臣不胜受恩感激。
今当远离,临表涕零,不知所言。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 汽车 销售 管理 系统软件 需求 规格 说明