需求说明书规格.docx

上传人:b****8 文档编号:29795764 上传时间:2023-07-27 格式:DOCX 页数:33 大小:1.51MB
下载 相关 举报
需求说明书规格.docx_第1页
第1页 / 共33页
需求说明书规格.docx_第2页
第2页 / 共33页
需求说明书规格.docx_第3页
第3页 / 共33页
需求说明书规格.docx_第4页
第4页 / 共33页
需求说明书规格.docx_第5页
第5页 / 共33页
点击查看更多>>
下载资源
资源描述

需求说明书规格.docx

《需求说明书规格.docx》由会员分享,可在线阅读,更多相关《需求说明书规格.docx(33页珍藏版)》请在冰豆网上搜索。

需求说明书规格.docx

需求说明书规格

学校代码:

10128

学号:

**********

 

 

课程设计说明书

题目:

车站售票管理系统

—需求规格说明书

学生姓名:

********

学院:

信息工程学院

系别:

计算机系

专业:

软件工程

班级:

***

指导教师:

***

***

2011年7月15日

目录

1.引言1

1.1编写目的1

1.2项目背景1

1.3定义2

1.4参考资料2

2.任务概述2

2.1目标2

2.2运行环境3

2.3条件与限制3

3.数据描述3

3.1静态数据3

3.2动态数据4

3.3数据库介绍5

3.4数据词典5

3.5数据采集7

4.功能需求8

4.1功能划分8

4.2功能描述21

5.性能需求22

5.1数据精确度22

5.2时间特性22

5.3适应性22

6.运行需求23

6.1用户界面23

6.2硬件接口28

6.3软件接口28

6.4故障处理28

7.其它需求29

8.附录29

1.引言

1.1编写目的

随着计算机技术的发展,人类生活速度的加快,单一的人工售票方式已经不能满足人们出行的要求。

每逢出行高峰都会造成火车站售票的拥挤,因此售票自动化应运而生。

车站售票管理系统就是这样的一个产物。

经过我开发小组的调研与讨论研究,基本上明确了该系统的需求,并在此基础上完成软件需求规格说明书。

该文档旨在对该系统的需求做出综合的分析,对各个模块的功能做出具体的说明。

《车站售票管理系统需求规格说明书》的目的是明确《车站售票管理系统》中各项功能和非功能需求,确定系统功能模块,同时为概要设计和详细设计人员提供设计依据,也可供本项目的其他开发人员参阅。

本需求分析报告的目的是规范化本软件的编写,旨在于提高软件开发过程中的能见度,便于对软件开发过程中的控制与管理,同时提出了本火车售票系统的软件开发过程,便于程序员与客户之间的交流、协作,并作为工作成果的原始依据,同时也表明了本软件的共性,以期能够获得更大范围的应用。

本文档需要交于论证人员进行论证修改,无误后供软件开发人员进行后期的软件设计

1.2项目背景

委托单位:

呼和浩特火车站

开发单位:

内蒙古工业大学软件工程

主管部门:

内蒙古工业大学计算机系

项目开发者:

*****

用户:

呼和浩特火车站

产品的所有权:

呼和浩特火车站

项目背景:

火车票出售管理系统是典型的信息管理系统(MIS),其开发主要包括后台数据库的建立和维护以及前端应用程序的开发两个方面。

本项目适用于Windows操作系统,使用SQLServer2005数据库,利用C++,JAVA开发平台开发系统。

1.3定义

静态数据:

主要是由表和视图组成,应该注意的是,数据字典中的表是不能直接被访问的,但是可以访问数据字典中的视图。

动态数据:

SQL包含了一些潜在的由系统管理员如SYS维护的表和视图,由于当数据库运行的时候它们会不断进行更新,所以称它们为动态数据字典(或者是动态性能视图)。

这些视图提供了关于内存和磁盘的运行情况,所以我们只能对其进行只读访问而不能修改它们。

数据字典:

数据字典是SQL存放有关数据库信息的地方,其用途是用来描述数据的。

比如一个表的创建者信息,创建时间信息,所属表空间信息,用户访问权限信息等。

当用户在对数据库中的数据进行操作时遇到困难就可以访问数据字典来查看详细的信息。

需求:

用户解决问题或达到目标所需的条件或功能;系统或系统部件要满足合同、标准,规范或其它正式规定文档所需具有的条件或权能。

需求分析:

包括提炼,分析和仔细审查已收集到的需求,以确保所有的风险承担者都明其含义并找出其中的错误,遗憾或其它不足的地方。

1.4参考资料

[1]刘利民、田宝军.软件工程综合设计指导书,2011

[2]张海藩.软件工程导论(第五版).北京清华大学出版社,2003

[3]黄国兴、周勇著.软件需求工程.清华大学出版社,2008-05

[4]车站售票管理系统——项目开发计划书

[5]车站售票管理系统——可行性分析报告

2.任务概述

2.1目标

利用信息化手段缓解火车站售票压力,满足广大人民群众的购票需求,使管理人员能够方便进行售票管理工作,包括修改、维护、统计等,使广大人民用户能够利用该系统进行信息的查询,购票,退票等。

用自然语言或者形式化语言与图形等完整、准确、具体地描述系统的数据需求、功能需求、性能需求、可靠性需求和可用性需求、接口需求、约束、逆向需求以及将来可能提出的要求。

(1)完善目前火车售票系统,使之能跟上时代的发展。

同时通过实践来提高自己的动手能

(2)应用范围:

理论上能够实现于铁路部门的售票系统,其目的在于在原有的系统基础使得火车售票便捷化,以期实现完善日常生活中火车售票的各种缺陷。

(3)可实现旅客对于火车票的查询与购买功能,售票员则可实现查询、添加和删除等功能;对于所查询的车次结果提供列表显示输出;有一定的安全机制,普通旅客不能对车次信息随意删改,只有系统管理员可通过密码识别进行维护。

2.2运行环境

操作系统:

MicrosoftWindows2007或MicrosoftWindowsXP

支持环境:

IIS5.0

数据库:

MicrosoftSQLServer2005

2.3条件与限制

应具备的设备:

计算机4台,打印机1台

应具备的人员:

软件专业学生4人

其他条件:

保证相关开发人员全部到位,不缺勤;资金全部到位

3.数据描述

3.1静态数据

列车信息:

列车车号(intSerialNumber)

列车始发时间(structtimeSetOut)

列车始发站(charDeparturePoint)

列车终点站(charTerminalPoint)

额定载量(intFixNumber)

票务:

列车车号(intSerialNumber)

发车时间

票价

发出车站

售票员:

用户名(charname)

密码(charpassword)

3.2动态数据

输入数据:

(根据界面提示,键盘输入操作)

旅客输入信息:

查询方式查询车次、查询站点

查询站点查询时用户输入的始发站到终点站

查询车次查询时用户输入的车次号

 

售票员输入信息:

身份验证帐号用户登录系统所需的账号(第一次需要注册)

帐号密码用户登录系统所需认证密码

查询方式查询车次、查询站点

查询站点查询时售票员输入的始发站到终点站

查询车次查询时售票员输入的车次号

票务信息添加、购票、退票的票务信息

 

管理员输入信息:

身份验证帐号用户登录系统所需的账号(第一次需要注册)

帐号密码用户登录系统所需认证密码

系统管理员备份数据恢复所需的数据备份文件;

 

输出数据:

输出信息:

查询车次确定的数据库记录的子集;

旅客输出信息

车票(价格,车次,发车时间,始发站)

售票员输出信息:

车次信息查询、购买的操作结果

 

管理员输出信息:

车次信息录入、删除结果成功或失败

数据备份输出的数据备份文件

 

3.3数据库介绍

名称:

MicrosoftSQLServer2005

介绍:

微软SQLServer2005SP1加入数据库镜像功能,为SQLServer2005ExpressEdition提供新管理工具,并且加强了SAPNetWeaver智能商务系统的报告反馈支持功能。

管理:

SQLServerManagementStudio集成了对SQLServer2005所有组件的管理。

BusinessIntelligence从业者都将得益于Microsoft服务器“能力”扩展这一用户盼望已久的功能增强,即从关系引擎(伸缩性、可靠性、可用性、可编程性,等等)扩展为全套的BI平台组件。

支持的操作系统:

Windows2000ServicePack4;

WindowsServer2003ServicePack1;

WindowsXPServicePack2

硬件要求:

具有IntelPentiumIII600MHz(或同等性能的兼容处理器)或速度更快处理器(建议使用1GHz或速度更快的处理器。

)的计算机最低192MB的RAM(建议使用512MB或更高的RAM。

)100MB的可用硬盘空间

注意事项:

安装此包之前,必须从系统中删除SQLServerManagementStudioExpress的任何Beta版本或CommunityTechnologyPreview(CTP)版本。

如果不执行此操作,则将导致此包安装失败。

安装条件:

您必须在计算机上具有管理权限才能安装SQLServer2005。

3.4数据词典

 

 

 

 

 

 

 

3.5数据采集

(1)车票信息由数据库设计人员加入录入数据库中

(2)用户账户及密码由登陆人员自行设计有数据库设计人员设计的系统方式录入数据库中。

(3)其他数据如票务信息由系统自动生成

4.功能需求

4.1功能划分

图3.1系统管理用例图

 

表3-1登录系统用例规约

用例名称:

登录系统

用例ID:

001

角色:

系统管理员

用例说明:

管理员登录管理

前置条件:

基本事件流:

登录

1.打开系统首页,并点击登录按钮

2.系统显示用户名,密码

3.输入用户名,密码,并确认

4.登陆成功

A1:

登录失败

5.系统将为该用户分配权限,并在页面显示

其它事件流:

A1:

1.登录失败

2.提示错误信息

异常事件流:

用户名称或密码不正确,不能登录系统,提示错误;允许3次

后置条件:

对系统及列车信息进行管理

 

表3-2列车管理规约

用例名称:

列车管理

用例ID:

002

角色:

管理员

用例说明:

管理员对列车进行添加,删除处理

前置条件:

管理员成功登录系统对列车由管理权限

基本事件流:

管理员添加、删除列车

1.选择要操作的类型

2.点确认

3.输入添加列车的车次及列车信息或删除列车车次

4.提示添加或删除成功

A1:

操作失败

其它事件流:

A1:

1.操作失败

2.提示错误信息

异常事件流:

1.删除列车在,提示删除错误;

2.添加的列车已经存在,提示重新输入列车车次

后置条件:

保存成功,列车新信息开始实施

 

表3-3列车信息规约

用例名称:

列车信息

用例ID:

003

角色:

管理员

用例说明:

管理员对列车信息进行修改

前置条件:

管理员成功登录,索要修改的列车信息正确无误

基本事件流:

管理员修改列车信息:

1.选择要操作的类型

2.点确认

3.输入要修改的车次号\时刻表\票价\站点\停车时间,

4.提示修改成功

A1:

操作失败

其它事件流:

A1:

1.修改失败

2.提示错误信息

异常事件流:

要修改的车次不存在

后置条件:

信息成功保存,正确实施

 

表3-4权限管理规约

用例名称:

权限管理

用例ID:

004

角色:

管理员

用例说明:

管理员对用户登录系统的权限进行管理

前置条件:

管理员成功登录

基本事件流:

管理员为用户分配权限

1.选择要操作的类型

2.点确认

3.选择相应的权限给各种用户

4.提示分配成功

A1:

分配失败

其它事件流:

A1:

3.操作失败

4.提示错误信息

异常事件流:

1.分配的权限不存在;

2.已存在要分配的权限

后置条件:

 

表3-5人员管理规约

用例名称:

人员管理

用例ID:

005

角色:

管理员

用例说明:

管理员对人员进行添加,删除处理

前置条件:

管理员成功登录

基本事件流:

管理员添加、删除人员

1.选择要操作的类型

2.点确认

3.输入添加人员的基本信息或删除人员

4.提示添加或删除成功

A1:

操作失败

其它事件流:

A1:

5.操作失败

6.提示错误信息

异常事件流:

删除人员不存在

后置条件:

 

表3-6维护数据管理规约

用例名称:

维护数据管理

用例ID:

006

角色:

管理员

用例说明:

管理员对数据库中数据进行维护

前置条件:

管理员成功登录,有数据维护权限

基本事件流:

管理员维护数据

1.选择要操作的类型

2.点确认

3.对无用数据的删除或新增数据的安全保护

4.对数据库进行数据备份

5.提示操作成功

A1:

操作失败

其它事件流:

A1:

7.操作失败

8.提示错误信息

异常事件流:

1.删除不应删除的数据

2.数据权限分配错误

后置条件:

各类用户对数据的权限使用

图3.2售票用例

 

表3-7登录系统用例规约

用例名称:

登录系统

用例ID:

007

角色:

售票员

用例说明:

售票员登录系统售票

前置条件:

基本事件流:

登录

1.打开系统首页,并点击登录按钮

2.系统显示用户名,密码

3.输入用户名,密码,并确认

4.登陆成功

A1:

登录失败

5.系统将为该用户分配权限,并在页面显示

其它事件流:

A1:

1.登录失败

2.提示错误信息

异常事件流:

用户名称或密码不正确,不能登录系统,提示错误;允许3次

后置条件:

实施相应操作

 

表3-8退票规约

用例名称:

退票

用例ID:

008

角色:

售票员

用例说明:

售票员对车票票进行退票或改签处理

前置条件:

售票员成功登录,车票无损且在规定时间内退票

基本事件流:

售票员对车票票进行退票或改签

1.选择要操作的类型

2.点确认

3.退票计算手续费并返还票钱,或改签的相应车次或时间

4.提示退票成功

A1:

操作失败

其它事件流:

A1:

9.操作失败

10.提示错误信息

异常事件流:

1.要退的车票已经检票无法退还

2.无法改签

后置条件:

修改车票信息,

 

表3-9统计信息用例规约

用例名称:

统计信息

用例ID:

009

角色:

售票员

用例说明:

售票员登录系统统计票务信息

前置条件:

售票员成功登录系统,具有相应权限

基本事件流:

售票员登录系统统计票务信息

1.选择要操作的类型

2.点确认

3.显示统计信息表

A1:

操作失败

其它事件流:

A1:

1.统计失败

2.提示错误信息

异常事件流:

1.用户名称或密码不正确,

2.无法统计

后置条件:

生成统计表供相应人员查看

 

表3-10售票规约

用例名称:

售票

用例ID:

010

角色:

售票员

用例说明:

售票员为旅客售票

前置条件:

售票员成功登录,具有售票权限

基本事件流:

售票员为旅客售票

1.选择要操作的类型

2.点确认

3.订票或为普通人售票或为特殊人售票

A1:

为特殊人售票

4.售票成功

A2:

操作失败

其它事件流:

A1:

为特殊人售票

1.刷优惠卡

2.售出票

A2:

操作失败

1.票已卖完

2.提示重新选择

异常事件流:

无票可卖

后置条件:

打印出车票供给旅客

 

表3-11查询信息规约

用例名称:

查询信息

用例ID:

011

角色:

乘客、售票员

用例说明:

乘客或售票员对车票信息进行查询

前置条件:

售票员登录,查询的信息存在

基本事件流:

乘客、售票员查询信息:

1.输入查询的车次或站点

2.点查询

3.返回列车信息,有无车票可出售

A1:

查询失败

其它事件流:

A1:

查询失败

提示错误信息

异常事件流:

输入车次号不存在,输入站点错误

后置条件:

订票或售票

 

表3-12购票规约

用例名称:

购票

用例ID:

012

角色:

旅客

用例说明:

旅客向售票员购票

前置条件:

售票员成功登录,旅客所要到达的地址存在且列车可停站

基本事件流:

旅客向售票员购票

1.选择要购买的车次或要到大的地址

2.确认

3.普通购票或优惠购票

4.售票成功

A1:

购票失败

其它事件流:

A1:

购票失败

1.票已卖完

异常事件流:

地址不存在

后置条件:

购票成功等待乘车

4.2功能描述

售票:

根据旅客的需求如发车日期、发车时间、车厢类型、车票类型(学生票、军人票…)、旅客终点站等选择用户所需要的车次,然后结算并打印车票给旅客。

订票:

由售票点授权或是有一定信誉的售票代理商替代旅客进行预订车票,售票代理商通过电话或是亲自到售票点预订的方式进行预订车票。

退票:

处理用户由于某种情况需要退回车票的情况,旅客要在车站指定的时间内进行退票,此外车站售票点还要扣除一定的手续费。

如若改签则由售票员改签到旅客所要的车次、时间、地点。

查询:

查询分为车次查询、站点查询、时刻表查询、票价查询、剩余票数查询。

车次查询提供了所有车次浏览、按车次查询、和站站查询,用户可以通过查询来了解列车所经车站以及发车时间等信息。

时刻表查询可以查询每一车次在每一站的发车时间和到站时间。

票价查询可以让用户按自己的需求来查询所有车次的车票价格;余票查询可以查询到所有车次的剩余车票的情况;

统计:

售票统计分别可以按日期统计、按车次统计、按客流方向统计等统计方式,通过察看车票的流向可以得知旅客的大致流向,列车管理人员可以根据客流的流向随时调整列车运行车次,达到列车的合理调度,使列车最大限度的投入使用中,实现资源的合理利用。

信息修改:

包括车次修改、票价修改、站点修改。

车次修改包括增加车次,减少车次,车次的临时调度和由于自然灾害造成的临时路线更改。

票价修改为节假日、春运等特殊时段或某些特殊地域需要适量增加或减少票价,具体数字有铁路管理定。

站点修改可是某些车次增加或减少一些站点。

系统管理:

管理员通过系统添加用户或者删除用户,并且授予权限,同时维护数据库,保证系统正确运行。

5.性能需求

5.1数据精确度

由于采用数据库技术并且用户的应用领域对数据精确度的要求不是太高,所以这点在系统中表现得比较少,但是用户数据的安全性与正确性是完全保证的,所以对用户的使用没有多大的障碍。

输入数据精度要求不高,但用户输入不精确时有提示。

5.2时间特性

对于用户的输入应该在较短的时间里给出回应。

若出错,应有出错报告。

由于该系统要求36台机器能够同时运行,要求较高的并发处理功能。

当增加多台机器后,要求系统的响应时间不会有过大的延时。

5.3适应性

该软件只能在Windows系统下运行,所以兼容性不高,但应用户特殊需求在维护阶段会保持一个与其它类软件接口,随时满足客户的使用需求。

6.运行需求

6.1用户界面

图3.3系统登录界面

图3.4旅客及售票员查询界面

 

图3.5管理员功能界面

图3.6列车信息

 

图3.7售票员功能

图3.8退票界面

 

图3.9人员管理

图3.10权限管理

图3.11售票管理

图3.12列车管理

图3.12维护后台

6.2硬件接口

(1)硬件接口:

支持x86系列PC机

(2)网络硬件接口要求:

现实中要求具有高速以太网组网一实现联网销售,但是在理论实验验证软件本身的目的来看,无需网络通讯接口。

软件除较小硬盘和显示器,鼠标外,服务器,基本没有与外界硬件的联系,不过考虑到数据库大量数据的备份等要求可以保持与磁带机和光盘刻录机的接口。

6.3软件接口

在这里主要考虑软件与操作系统的接口,考虑到文档处理的需要有可能需要与常用的办公软件的接口。

例如Microsoft的office系列。

另外查询模块需要与互联网相连,以实现乘客的网上查询。

运行于Windows2000及更高版本并装有JAVA虚拟机的操作系统之上。

6.4故障处理

鉴于火车售票系统涉及的数据对于火车站日常管理的重要性,必须建立数据库严格有效的恢复机制:

数据必须每天进行一次备份,由于本信息涉及信息量巨大,应以天为周期进行增量转储,一般半个季度为周期进行删除。

正常使用时不用出错,对于用户的输入错误应及时给出适当的改正信息提示,若运行遇到不可恢复的系统错误,也必须保证数据库完好无损。

7.其它需求

本系统中对系统各个模块功能,以分级菜单的形式给出;所有的提交,确认,删除等操作以按钮的形式给出,且名称一律取为“提交”、“确认”、“删除”等易于理解的形式;根据用户统计信息计算,统计在正常情况下应该支持一定人数的并行操作能力,春运高峰期间人们要集中买票和查询,应支持更多人数的并行操作能力;高峰期间服务器应支持几十万以上的日访问量。

(1)可用性:

该软件也可以通过单步跟踪的操作进行检查处理。

(2)安全性:

由于软件运行数据放在数据库中,所以参数不容易被错改、破坏,万一参数受到破坏也不会影响源程序。

(3)可维护性:

该软件利用数据库进行编程,系统结构由程序基本确定,大量的参数及文本内容全部放于数据库中。

修改、更新数据只要在数据库进行修改添加,而不需要对系统结构进行修改,这样系统维护性、升级都十分方便。

(4)兼容性:

由于尚未测试,故无法对兼容性进行评析。

8.附录

1.车辆类型

(1)动车D

(2)空调快车K

(3)空调特快T/N

(4)直达快车Z

(5)临时客车L

(6)普通快车编号

2.车座类型

(1)软卧

(2)硬卧

(3)软座

(4)硬座

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 人文社科 > 哲学历史

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1