XXX售票网站系统需求分析.docx
- 文档编号:3843341
- 上传时间:2022-11-25
- 格式:DOCX
- 页数:13
- 大小:671.30KB
XXX售票网站系统需求分析.docx
《XXX售票网站系统需求分析.docx》由会员分享,可在线阅读,更多相关《XXX售票网站系统需求分析.docx(13页珍藏版)》请在冰豆网上搜索。
XXX售票网站系统需求分析
XXXX售票网站系统
需求分析说明书
文件状态:
[√]草稿
[]正式发布
[]正在修改
文件标识:
SPWZ-XQFX-2012-001
当前版本:
1.0
作者:
XXXX
完成日期:
版本历史
版本/状态
作者
参与者
起止日期
备注
1.0
XX
2012-1-4—
2012-1-4
编写初步售票网站的基本需求分析说明,提交草稿。
2.0
根据调研需求及相关要求进行修订和评审,评审通过。
3.0
根据整体建设方案修改
阅读历史记录
日期
版本
阅读者
说明
0.1
0.2
第1章简介
XXX售票网站系统,其设计目标是基于XXX票务发展需要,全面建设一个智能化的电子商务平台,使得XXX适应目前的票务市场的发展,成功实现电子售票、电子支付、电子资金等功能,以摆脱传统的售票、资金流所带来的落后运营局面。
通过互联互通,实现与纵向、横向间互联互通的软件整体应用环境,并以此为基础,最终达到建立XXX综合电子商务平台的目的。
第一节目的
本文档初步大致分析了XXX售票网站系统的基本建设需求,此文档将成为指导本项目设计、开发、实施、验收的标准之一。
第二节阅读范围
XXX相关领导及技术人员
XXX票务工作的相关部门领导及技术人员
本项目管理人员
本项目的网站开发人员和实施人员
项目的其他相关人员
第三节定义、首字母缩写词和缩略语
体育中心:
XXX的简称
本系统――XXX售票网站系统
拟稿――新建一份文件,并符合国家行政机关公文处理办法中相关草拟的规定
审核――是部门领导对下级人员递交的文件进行审阅;审核重点是:
是否确需行文,行文方式是否妥当,是否符合行文规则和拟制公文的有关要求,公文格式是否符合国家行政机关公文处理办法的规定等
会签――除该部门以外其他相关部门或外单位对文件进行并行处理的过程
签发――领导或分管领导确认文件生效的过程
复核――公文正式印制前,综合管理部门应当进行复核;复核重点是:
审批、签发手续是否完备,附件材料是否齐全,格式是否统一、规范等。
经复核需要对文稿进行实质性修改的,应按程序复审
编号――对领导签发的发文的不同的文种进行编号过程,此区别于手工操作时的草拟编号
已阅――领导或相关人员点击“已阅”,系统自动处理,直接提交给下一处理人或流向流程指定人
批示――领导或相关人员点击“批示”,系统弹出批示框,批示填写完毕后再确定发送
第四节参考资料
《信息处理数据流程图、程序流程图、系统流程图、程序网络图、系统资源图的文件编制符号及约定》,GB/T1526-1989
《软件需求》作者:
KarlE•Wiegers出版社:
机械工业出版社
《软件需求管理:
统一方法》作者:
DeanLeffingwell出版社:
机械工业出版社
《软件工程导论(第三版)》作者:
张海藩出版社:
清华大学出版社
第2章整体说明
本需求分析报告主要描述XXX售票网站系统的总体需求概况,并对总体需求进行子系统及模块的划分,然后进一步对各子系统进行功能说明(文字)和流程图描述。
第一节系统功能模块整体结构表
第二节系统界面介绍
以下图例仅供参考,在系统设计开发阶段另行设计、沟通和确认。
首页样式
工作台页面样式
子系统页面样式
第三节易用性
本系统采用B/S结构,操作方便、使用简单,降低对使用人员的计算机专业技术要求;功能必须符合和优化手工管理习惯,体现计算机管理的价值和优势。
使政府工作人员能够方便快捷地共享、交流信息,高效地协同工作,实现办公业务工作运转的电子化、科学化、系统化、自动化。
第四节可靠性
软件的可靠性主要通过系统逻辑原型的合理准确设计、系统权限严格分配、软件开发过程的质量控制、应用软件的全面测试、用户操作的充分培训、网络和系统软硬件平台的可靠支持等加以保障。
系统充分考虑到可能出现的各种异常情况,具备快速应变能力和容错能力,采用高可靠性的设备和技术,保证数据资料的联机备份与恢复,确保系统整体安全和可靠。
第五节可支持性
系统的可支持性体现在应用软件设计可理解性、可测试性、可修改性,是保护投资的重要系统属性。
硬件:
设备的选型应遵循先进性、可靠性原则。
网络构架:
网络构架的设计应适应未来的发展。
同时具有可拓展性、易维护性和易管理性,关键要适合体育中心目前的网络条件。
软件:
软件设计要结合本系统的实际情况,找准最恰当的切入点,指定较为合理的解决方案,有简到难、有小到大、逐步实现电子商务的目标。
第六节设计约束
服务器端:
a)操作系统采用Window2008Server或Windwos2003Server
b)WEB服务器采用微软公司的IIS6.0或IIS7.0服务器
c)数据库服务器采用SQLServer2008Enterprise
d)开发工具选择ASP.NET
客户端:
e)操作系统需WindowXP及以上版本
f)浏览器建议采用IE6.0及以上版本
第3章会员管理
原则上规定,欲从XXX售票网站系统购票的访问者必须先成为XXX会员。
其设计目标是基于XXX会员发展的需要,会员信息可方便的对购票售后服务环节进行客户追踪和服务。
第一节注册
一、业务描述
客户身份信息访问注册。
二、功能说明
必注册数据项:
呢称/用户名、性别、出生年月、登陆密码、电子邮箱等。
选注册数据项:
电话、地址、学历、职业、婚姻状况、专业、照片等。
系统形成《会员信息二维表》存放数据。
数据约束:
呢称/用户名:
由字母、数字组成,14个长度以内,不含特殊字符。
性别:
男、女
出生年月:
由日期型字符组成,如20081231,字符长度8位。
登陆密码:
由字母、数字组成,14个长度以内,不含特殊字符,此项 数据在数据库中必须以密文方式存储,不能以明文上市存储。
注册时必须给予图像识别确认,以防止自动程序注册系统。
三、数据流图
第二节登陆
一、业务描述
客户输入用户名、密码后方可登陆系统,而后不仅可以浏览网站信息,也可留言,发表论坛言论,预定票务,在线订票的功能。
二、功能说明
系统要有会员在线、离线显示标识和统计。
区别会员和非会员的功能。
第三节级别
一、业务描述
通过用户的购票金额和票务数量(可累积)来为每位客户确定不同的积分,以积分的多少对用户进行级别分类。
不同级别的用户可享受不同等级的服务和优惠。
二、功能说明
每购票金额达100元赠加用户积分1分;
每咨询票务信息留言一次,增加用户积分0.1分;
20分以下为普通客户、20-50分为中级客户、50分-80分高级客户、80-120位贵宾客户、120分以上未vip客户。
第四节会员库
第五节个人帐务中心
除了将用户注册的所有信息之外,在这里我们要加上用户的订票及交易记录信息。
第六节论坛与注销
第4章项目管理
项目所指一次活动所引起的网上购票行为的过程。
活动包括文艺演出、体育赛事等多种因活动产生的购票行为。
售票信息具体指该活动的票价、等级、票数量等基本信息。
第一节 项目建立
一、业务描述
新的项目在售票前,需要将项目的所有数据和信息全部在数据库中建立起来。
项目的具体数据项和信息详情请参考本节《项目信息数据》部分。
二、功能说明
对整个项目的信息进行建立,如添加新项目。
统一的数据库数据输入应用程序窗口。
前置条件
使用本项功能的用户必须是高级用户或是系统管理员级别的相应权限。
后置条件
建立好的新项目默认为非激活项目(不能开始售票的项目)。
三、业务流图
第二节 项目控制
一、业务描述
通过项目控制对已经建立的所有项目进行管理,如项目删除、项目修改、项目激活(开始售票)、项目关闭(停止售票)、项目售卖数量设置、项目状态设置等
二、功能说明
项目删除:
删除该项目在系统中的所有数据,并不可恢复。
项目修改:
能修改非激活状态的项目所有信息数据,对该项目进行修正和调整。
项目激活(开始售票):
将该项目激活成开始售票状态。
项目关闭:
将该项目恢复成非激活状态。
项目售卖数量设置:
对每天的放票数量进行控制,并且对剩余票数量给予提前报警功能。
项目状态设置:
标识状态有激活、非激活状态。
三、前置条件
用本项功能的用户必须是系统管理员级别的相应权限。
四、后置条件
五、约束条件
项目删除、项目修改只能用于非激活项目
项目售卖数量设置只能用于激活项目
用户必须是高级用户或是系统管理员级别的相应权限
六、业务流图
第三节 项目情况查询
一、业务描述
对正在售票的项目运行情况进行查询,了解运行项目的售票情况,为临时调整放票进程提供数据依据。
二、功能说明
对已售票的数量、金额进行统计查询
对剩余票数、金额进行查询
对相应不同级别、价位的已售、未售情况进行查询
三、前置条件
使用本功能的用户一定是具备相应权限的操作人员或高级管理人员的权限。
第四节 项目的信息数据
对所有项目的所有信息进行数据分类,明确项目数据信息。
一、数据项:
项目名称、项目举办时间和地址、售票时间、激活状态、关闭时间、新建时间、票务等级、各个等级票价、各个等级总票数、单位时间内各个等级可售票数,各个等级已售票数等。
二、约束条件:
单位时间内各个等级可售票数<=(各个等级总票数-各个等级已售票数)
第5章订票控制
第一节订单生成
一、业务描述
注册用户可浏览到已经激活项目(开始售票的项目)的售票情况,并选择自己所需要的票务商品,点击“订单生成”,系统自动生成“订单信息记录单”。
用户确认无误后跳转电子支付平台付费。
二、功能说明
生成订单信息记录单,单中信息含有:
订单编号、订单生成时间、用户身份信息、票务商品信息、取票方式(自行提票、快递)、是否在线支付快递费用、费用总计等。
对输入信息要进行效验,以防止数据有误。
订单信息记录单必须留有重要标识符,如支付是否成功、支付帐单流水号等信息。
三、前置条件
已激活项目信息中必须有用户所选择数量内的票数,否则禁止生成订单信息记录单。
四、后置条件
等待银行支付程序的返回报文:
未支付、成功支付、非成功支付。
成功支付:
将订单信息记录单中的C修改为已经支付,自动填入帐单流水号。
并将此条记录所销售的票务商品数量从已经激活项目信息中的单位时间内各个等级可售票数减去。
非成功支付:
将订单信息记录单中的支付是否成功标识符修改为非成功支付。
将本条订单信息记录单存储在已支付订单数据库,以用于后期人工配送处理。
第二节订单信息记录单的数据项
订单编号、订单生成时间、用户身份信息(会员信息+帐务信息)、票务商品信息(购买各等级票数量)、取票方式(自行提票、快递)、是否在线支付快递费用、费用总计、支付是否成功标识符、
第三节业务流程图
第6章电子支付
本章内容请参考“招商银行”相关文档。
第7章票务配送
一、电子化处理方式
根据《已支付订单数据库》的“支付是否成功标识符”的值将《已支付订单数据库》划分为〈待配送处理业务数据库〉和〈不可配送处理业务数据〉。
〈待配送处理业务数据库〉的“支付是否成功标识符”值=成功支付。
〈不可配送处理业务数据〉的“支付是否成功标识符”值=未支付或非成功支付。
对于〈不可配送处理业务数据库〉的“支付是否成功标识符”值=非成功支付的记录处理过程:
通知银行和客户,手工处理至支付成功。
对于〈不可配送处理业务数据库〉的“支付是否成功标识符”值=未支付的记录处理过程:
通知客户要求重新提交订票信息单,删除该记录。
对于〈待配送处理业务数据库〉记录配票处理过程:
将严格按“订票信息单”中的票务商品信息人工配好实物票,使用信封单一封装,信封表面粘贴订单相关信息。
然后在〈订单信息记录单〉上标志该条记录已经过配票程序处理。
对于〈待配送处理业务数据库〉记录送票处理过程:
如果注明是用户自提,就等待客户自行提取。
如果是快递,就将业务转交快递公司邮寄。
二、临时手工处理方式
第8章系统管理
一、用户管理
用户角色
高级系统管理
普通系统管理
项目管理
送票管理
查询管理
二、权限分配
高级系统管理---数据库维护、整体权限分配,拥有最高权限,不受任何限制
普通系统管理---会员管理、论坛管理、用户管理
项目操作---项目管理
配票操作---配票管理
送票操作---送票管理
查询操作---财务查询数据查询
三、财务统计
已提交购票订单信息一览表(时间阶段:
当日、历史、项目情况:
单项目、多项目)
已成功支付订单信息一览表(时间阶段:
当日、历史、项目情况:
单项目、多项目)
非成功支付订单信息一览表(时间阶段:
当日、历史、项目情况:
单项目、多项目)
未支付订单信息一览表(时间阶段:
当日、历史、项目情况:
单项目、多项目)
需要进行配、送票处理信息一览表(时间阶段:
当日、历史;项目情况:
单项目、多项目;处理类型:
配票处理、送票处理)
已配票待送票处理信息一览表(时间阶段:
当日、历史;项目情况:
单项目、多项目;)
配、送票已完毕处理信息一览表(时间阶段:
当日、历史;项目情况:
单项目、多项目;)
配、送票已处理或未处理信息一览表(时间阶段:
当日、历史;项目情况:
单项目、多项目;操作对象)
四、打印报表
五、数据库维护
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- XXX 售票 网站 系统 需求 分析