XXX售票网站系统需求分析.doc

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