图书馆管理系统(软件需求说明书)

图书馆管理系统(软件需求说明书)（精选9篇）

图书馆管理系统(软件需求说明书) 篇1

1引言...............................21.1编写目的...............................2

1.2背景.........................2

1.3定义.........................2

1.4参考资料...............................2

2任务概述..............................2

2.1目标.........................2

2.2用户的特点...........................32.3假定和约束...........................3

3需求规定..............................3

3.1对功能的规定.......................3

3.2对性能的规定.......................43.2.1精度.........................4

3.2.2时间特性要求.......................4

3.2.3灵活性............................53.3输人输出要求.......................5

3.4数据管理能力要求......................5

3.5故障处理要求.......................5

3.6其他专门要求.......................5

4运行环境规定.............................6

4.1设备.........................6

4.2支持软件...............................6

4.3接口.........................6

4.4控制.........................6

软件需求说明书

1引言

1.1编写目的本文档的目的是阐述酒店管理系统的需求分析

预期的读者：酒店经营者、客户、中间用户(软件的管理人员、开发人员、维护人员)、最终用户。

1.2背景

待开发的软件系统的名称：酒店管理系统

本项目的任务提出者和开发者：刘畅和酒店管理系统开发小组 本项目的用户是针对各档次酒店宾馆管理定制开发的本系统环境要求：所有程序均在Windows98/XP，Windows2000操作系统下测试运行。如果数据库为SQL Server数据库，建议用户安装SQL Serve2000

1.3定义

酒店管理系统是酒店宾馆销售管理系统

1.4参考资料

《现代软件工程》陈松乔 任胜兵 王国军 编著清华大学出版社 《程序设计语言》沈志斌编著电子工业出版社 《Delphi实用教程》 郑阿奇主编电子工业出版社

2任务概述

2.1目标

开发意图：

随着人民生活的水平的日益提高，人们对于生活的品质也有了明显的提高，现在到酒店住宿已经不再是少部分人才有的享受，越来越多的人开始将之视为日常生活的一部份。人们消费观念的改变也带来了酒店业的巨大发展。跟随时代的改变，21世纪的计算机化地位也已不可动摇，计算机简单、快捷、高效、准确的特性也受到推崇，在各行各业迅速发展壮大

起来。较大规模的酒店也正一步步地朝这方面发展。

与其他软件的关系：

与相应的软件可以共享数据库，本系统考虑到今后的数据量的扩大采用SQL Server数据库。

2.2用户的特点

本软件的最终用户为各大酒店及宾馆 一般用户只需懂得计算机基本操作、具备文字录入能力。相对维护人员应具备一定的计算机专业知识，了解数据库系统的管理与维护，能排除一般计算机故障。

2.3假定和约束

从项目设计需求说明至最终审核，开发人员工作分配到位，开发小组成员在配合组长工作的同时，应能如期完成各自的工作任务。

开发期限为一个月，若小组某成员因技术缺陷或者特殊原因延误开发进度，其他组员应提供相对帮助。另有辅导老师进行指导与督促。

3需求规定

3.1对功能的规定

功能模块初步设计为五大模块分别为身份验证、系统设置、客房管理、订房管理、结算管理。各模块分别提供基本数据流图。各模块所包含的子功能如下列出为准。

身份验证：提供了系统的访问控制功能。

系统：提供了对密码的修改以及添加新用户的功能。

客房信息管理：包括两大主要功能，设置客服标准和设置客房信息，在设置客房标准中，管理员可以添加，修改，删除客房标准，在设置客房信息中，管理员可以添加，修改，删除，查询客房信息。

订房信息管理：包括查询剩余客房信息，添加，修改，查询订房信息等功能。结算信息管理：包括添加，修改，查询结算信息功能。

图1．酒店管理系统用例图

3.2对性能的规定 3.2.1精度

对金额的输入要求保留小数点后两位，其他数值不做要求。

3.2.2时间特性要求

说明对于该软件的时间特性要求，如对： a． 响应时间<=15s； b． 更新处理时间<=5s；

c． 数据的转换和传送时间<=15s； d． 等待时鼠标将变成漏斗状。

3.2.3灵活性

a． 系统的界面操作方式应以用户意见变化而灵活转化； b． 系统不能以运行环境的变化而停止运作；

c． 一般情况下不用进行程序修改而是通过修改配置选项完成相应工作。

3.3输人输出要求

数据类型： 字符数据CHAR［(N)］：存放固定长度的N个字符数据，1<=N<=8000VARCHAR[(N)]:存放可变长度的N个字符数据，1<=N<=8000 日期型数据

DATATIME：存放从1/1/1753到12/31/9999的时间数据，精确到1/1000秒 数字型数据

INTEGER：存放从-2^31到2^63的整形数据货币数据

MONEY：存放从-2^63到2^63-1的货币数据，精度为货币单位的10/1000

3.4数据管理能力要求

需要管理的文卷和记录的个数为六张表：分别是 客户住宿基本信息表，营业动态数据信息表，营业总分析表，每日客流信息表，收费项目表，当日营业额日报表。

按可预见的增长对数据及其分量的存储要求估算字段的大小不超过50。表和文卷的大小规模为中等大小。

3.5故障处理要求

a． 源数据的处理：建议全部保存；

b． 操作规程：确保系统正常工作，数据完好无损，并定期进行数据库备份；

c． 数据进入系统的过程：通过数据库管理员身份登录进行管理，或由DBA直接对数据库进行操作；

d． 数据保存、存储、恢复的处理：请软件使用者自行备份相关信息； e． 系统失效的后果及恢复的处理办法：首先请恢复备份，在这里我建议备份数据库以将可能的损失降到最低点。如果不能恢复，请与我们联系，我们将竭尽所能提供力所能及的帮助。

3.6其他专门要求

该软件安全保密的要求为中等，对该系统使用尽可能方便，对可维护性比较容易、易补充、易读、可靠。

运行环境可在windows x系列操作系统下转换。

4运行环境规定

4.1设备

服务器：

CPU：PII233或HP系列的专门服务器 内存：128M 以上 硬盘：10G 以上

显示模式：推荐分辨率为800*600 工作站：

CPU：P133以上 内存：64M以上

模式：推荐分辨率为800*600

4.2支持软件

支持软件：Win9X/2000/XP/2003

服务器：数据库系统Microsoft SQL Server 2000

工作站：局域网络运行，工作站上不需要安装数据库系统。

4.3接口

该软件同各酒店宾馆的销售系统之间的接口。

与较大的客户单位之间的接口，用来跟踪掌握大客户的相关情况。接口之间网络协议采用TCP/IP协议。

4.4控制

用专门的机器控制该软件，并有专门的人员去维护与运行。可以通过计算机发出信号去控制软件的正常运行。

图书馆管理系统(软件需求说明书) 篇2

Standish Group从1994 年到2001 年的CHAOS Reports证实导致项目失败的最多的原因就是“变更用户需求”[1]。 因此避免失败和提高项目的成功率需要进行需求管理。

目前对需求进行管理主要是使用IBM Rational Requisite Pro、IBM Rational Doors等工具或使用excel进行人工管理, 但对需求的变更管理和版本管理往往借助第三方工具 (如IBM Rational Clear Case、IBM Rational Clear Quest) , 不能在同一个平台中对需求进行有效管理, 导致相关技术文档的源头不唯一, 需求追溯性变差, 同时增加了管理成本。

1 需求管理过程概述

需求管理的主要活动包括需求确认 (主要由用户和项目组共同对软件研制任务书和需求规格说明进行评审) 、 需求变更 (包括需求更改和版本控制) 和需求跟踪控制。

2 需求管理存在的问题

2.1 需求评审的问题

当前对需求的评审一般都是基于文档化的文件进行评审, 评审的时候不容易记录问题对应的需求项, 问题的提出人等信息。这带来的问题为:给手工记录带来了很大的压力;评审结束之后, 很多问题不知下文;不能充分统计需求评审问题以便跟踪问题并作为组织改进的依据。

2.2 需求变更控制问题

当基于问题、客户新需求等对需求进行变更时, 目前国内相关单位基本上都参考[2]提交更改申请, 但更改申请往往是纸质的或是基于变更管理系统的, 没有与需求管理工具进行集成 (IBM Rational Doors除外) , 且对需求变更的描述一般比较粗, 不能有效记录需求变更历史 (如需求项、问题提交人、需求修改时间等信息) 。

2.3 需求版本控制问题

目前业界内相关商业需求管理工具[3] (如IBM Rational Doors等) 基本不具备或不能与版本管理工具进行集成, 从而使得相关技术文档不能直接进入版本管理系统中, 使得技术文档管理源头不唯一, 可能导致各个系统中软件技术状态不唯一, 增加了管理的难度。

2.4 需求跟踪问题

目前业界内很多相关单位通过手工方式使用excel进行需求追踪管理, 导致需要额外存储需求跟踪矩阵, 且记录不方便。

3 解决问题的方法

因此, 需求管理的理想模式 (见附图) 是:在需求评审的过程中能够通过一个工具自动记录需求评审的问题, 自动记录需求变更的历史并做好需求追踪、 在时机成熟时将需求文档提交到开发库、受控库或产品库。 为了实现该模式, 在嵌入式软件产品平台中借助配置管理手段辅助需求管理, 确保需求的变更控制、版本管理与配置管理融合的同时, 解决2.1、2.2、2.3、2.4 的问题。

3.1 有效的评审

针对2.1 中存在的不能有效记录评审人、评审问题、问题落实情况、问题对应的需求项、分析统计问题等问题, 在软件需求管理的过程中, 相关人员在嵌入式软件产品平台上按附图对需求管理范畴内所有文档 (软件研制任务书、需求规格说明、软件设计说明、软件代码、单元测试用例、部件测试用例、配置项/系统测试用例) 进行项目级评审, 对软件研制任务书、需求规格说明、 配置项/系统级测试用例及项目级评审达不成一致意见的问题进行院级评审。在需求评审的过程中设置一名精通软件工程过程改进并从事过软件研发与管理的人员担任项目管理秘书, 负责跟踪、协调评审过程中问题, 并从评审问题中提炼相关内容纳入到组织的评审检查单中。

首先进行项目级评审。 软件研制任务书、软件需求规格说明等需求文档 (一个需求文档包含若干个需求项) 的编制人首先按照[4]格式要求在嵌入式软件产品平台中进行需求定义 (需求定义内容主要包括需求项名称、需求项内容) , 然后提交需求定义内容, 使其转换为需求项列表 (需求项列表主要内容包括每一个需求项唯一编号、需求项名称、需求项内容、版本 (初始版本为1) 、审查列表等信息) 在评审人员的审查界面中显示。评审人员参考组织的评审检查单在审查列表中填写评审问题, 并给出评审结论 (通过或不通过) 。 对每一需求项, 如果有一个人的结论为不通过, 则该需求项评审的结论为不通过 (其中初始结论为待审状态) , 否则为通过。 对于不通过的需求项, 如果编制人接受修改意见, 则修改完成之后, 所有评审人员对修改的需求项重新进行项目级评审直至问题关闭。对于编制人和评审人员达不成一致意见的需求项, 则由项目管理秘书提交院级评审进行决策。

院级评审时机为项目级评审结束 (包含项目级评审通过、项目级评审未通过但需要项目管理秘书提交院级评审进行决策) 之后, 对属于院级评审范畴内的内容进行评审。如果院级评审不通过, 则按图1 反馈问题给修改人进行修改, 然后重新进行项目级评审和院级评审, 直到通过。与项目级评审相比, 院级评审需要院级型号副总师和用户参与评审。

在评审的过程中, 通过在嵌入式软件产品平台中进行问题记录和跟踪, 确保了被评需求文档的质量, 并有利于组织过程改进。

3.2 需求与变更、版本紧密关联

对2.2、2.3 中存在的需求管理与变更管理、 版本管理分离的问题, 相关人员在嵌入式软件产品平台中按图1 对需求的变更与版本控制采取以下处理方式:

(1) 对于提交项目级评审之前的需求项, 文档编制人员在嵌入式软件产品平台中可以任意对需求进行修改, 且不形成需求项版本;

(2) 对于已提交项目级评审, 未进行院级评审的需求项, 文档编制人员可以对需求项进行修改, 但每修改1 次都会记录修改前后的状态, 且当前需求项版本在原有版本上加1 (如只修改了1 次的需求项版本为2) 。 当所有的需求项都通过项目级评审之后 (即需求文档具备提交开发库条件) , 需求文档编制人在嵌入式软件产品平台中提交入开发库申请, 开发库配置管理员依据配置管理规定在嵌入式软件产品平台中对需求文档给出开发库配置标识 (以便冻结状态, 供软件测试人员进行单元测试、部件测试等) ;

(3) 对于项目级评审结束 (包含项目级评审通过、项目级评审未通过但需要项目管理秘书提交院级评审进行决策) 之后提交院级评审的需求文档, 如果院级评审不通过, 则文档编制人员修改需求项, 系统自动记录需求项修改历史;如果院级评审通过 (即需求文档具备提交受控库条件) , 需求文档编制人在嵌入式软件产品平台中提交入受控库申请, 受控库配置管理员依据配置管理规定在嵌入式软件产品平台中对需求文档给出受控库配置标识 (以便冻结状态, 供测试人员开展配置项/系统测试等) ;

(4) 当需求文档入受控库或产品库之后, 如果需求需要变更 (含测试发现问题等原因需要更改的非新增需求, 新增需求等) , 则文档编制人员必须提交需求变更申请并选择需要修改的需求项 (说明更改原因、进行影响域分析等) , 并通过型号副总师审批之后, 需要修改的需求项才处于可修改 (对于非新增需求) 或可评审 (新增需求) 状态。 然后相关人员重新进行需求修改、进行项目级评审、提交开发库、进行院级评审、提交受控库、提交产品库操作等。

在需求的变更与版本控制的过程中, 通过在嵌入式软件产品平台中融合需求管理与配置管理, 解决了需求变更历史不能有效记录, 需求文档不能直接进入软件版本管理系统导致源头不唯一可能产生的技术状态不唯一的问题。

3.3 基于平台的需求跟踪

对2.4 中存在的用excel进行需求跟踪不利于记录的维护和存储的问题, 通过在嵌入式软件产品平台中设置需求追踪功能, 相关文档编制人只需在下游的需求项列表中选择上游的需求项并进行关联, 系统自动建立任务书-需求规格说明-设计说明-代码-测试用例之间的需求跟踪矩阵并可随时查询。 通过此方式解决了使用excel等进行追踪不方便管理的问题。

4 结语

本文针对业界内需求评审、需求的变更与版本控制等过程中存在的问题, 从理论上将需求管理与软件配置管理 (包括软件变更管理和配置管理) 有机融合, 并在此基础上创新性提出了一种新的需求管理模式, 并将该模式通过工具来实现, 确保了需求能够有效评审与跟踪, 需求的变更和版本管理能够与软件配置管理业务有效融合, 使得企业能够高效进行需求管理, 从而保证了软件产品的质量, 并减少了管理成本。

摘要：针对需求评审过程中存在的不容易记录和跟踪评审问题、需求的变更申请不能很好与需求条款相对应问题、需求管理工具中管理的需求文档不能直接进入软件配置管理系统导致需求文档的源头不唯一问题以及通过手工方式进行需求追踪的问题等, 考虑到需求管理活动包含的需求变更管理与版本控制属于软件配置管理需要控制的核心要素, 从理论上将需求管理与软件配置管理有机融合, 以两者融合解决需求管理过程中存在的问题为出发点, 在此基础上提出了一种新的需求管理模式, 并将该模式通过嵌入式软件产品平台来实现, 以有效解决需求管理过程中存在的问题。

关键词：需求管理,需求评审,需求变更,版本控制,需求跟踪

参考文献

[1]需求管理:IBM Rational技术白皮书[EB/OL].[2004-08-01].http://www.ibm.com/developerworks/cn/rational/r-rm/index.html.

[2]中国人民解放军总装备部.GJB 5235-2004, 军用软件配置管理[S].北京:总装备部军标出版发行部, 2004.

[3]国内外需求管理工具比较[R/OL].[2014-07-11].http://download.csdn.net/detail/kingr2014/7620925.

软件项目的需求变更管理 篇3

需求管理的常见误区

软件项目的范围控制应该是在需求分析阶段就开始的，然而很多项目经理针对需求分析存在不少认识误区。

误区1：开发商和用户仅就软件需求的基本轮廓达成一致即可，具体细节准备日后协商。

从项目管理角度分析，这是非常危险的，许多软件项目失败的最主要原因就是需求分析阶段对问题、流程、细节的描述不够准确，导致后期预算超支或者工期延误。

正确的方法是：在需求分析阶段，双方必须对项目的应用背景、功能需求、性能需求、可靠性需求、可用性需求、操作界面需求、外部接口需求，以及项目评审的方法、标准、过程进行全面、细致地研究讨论，逐一进行明确。

误区2：软件需求是软件必需向用户提供的功能和界面，功能上满足需求就足够了。

从软件需求工程角度分析，这只是认识到了软件系统的功能需求，忽略了软件的非功能需求和设计约束，需求捕获不够全面。软件需求工程理论认为，软件需求包括功能需求、非功能需求和设计约束三方面内容。

正确的方法是：除了要明确软件的功能需求，还需要进一步明确非功能需求（即软件产品所必备的属性和品质，包括可靠性、可用性、安全性、可扩展性、可移植性等）和设计约束（即软件研发必须遵守的特定规约、限制条件、政策标准,如软件必须采用国内自主知识产权的数据库产品）。

误区3：需求调研的对象是用户，用户就是软件产品的最终使用人员。

从项目管理角度分析，该观点缺乏对项目相关人全面、系统的认识，对用户的概念理解不到位。“用户”是一种泛称，它可细分为客户、最终用户和间接用户三种类型。例如，很多企业的一把手并不直接参与软件的采购和操作，但是其对于软件项目实际上起到了关键意义的决定作用，属于最重要的间接用户。

正确的方法是：要充分认识用户的多重性、层次性、复杂性，在进行需求调研时应首先对用户进行分析、分类，根据重要性、优先级、特殊性对各类用户进行排序；其次，是针对不同类别的用户分别制订不同的需求调研计划，全面开展需求调研。需要重点指出的是，对于由多个业务部门共同参与的软件项目，在确认软件需求时一定要得到全部参与部门的共同认可。

误区4：按照“需求、设计、编程、测试”步骤研发出的软件不必考虑需求跟踪问题。

从软件工程角度分析，这是对于需求变更过程缺乏系统的认识的表现，严格线性顺序的开发模型并不能保证各个开发阶段的工作成果与需求保持一致。实际上，由于需求变更的不可预见性和必然性，各个阶段往往以螺旋的方式渐进。

正确的方法是：需求跟踪应该贯穿于整个软件需求管理阶段，需求跟踪的目标是实现《产品需求规格说明书》和软件产品之间的双向可追溯。

做好需求工程

需求分析是软件工程项目最重要、最基础的起始阶段，为后续的规划设计阶段提供参照依据。在软件研发项目过程中一定要树立需求工程的意识，将需求视为一项系统工程。为了能够全面做好需求管理，应根据项目实际情况严格划分项目阶段，清晰界定、定义项目阶段的基线，在每个项目阶段制订、执行阶段性需求管理计划，逐一认真落实。

1．需求工程的结构及目标任务

需求工程是一个包括创建和维护系统需求文档所必需的一切活动的过程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。需求工程结构如图1所示，需求开发与需求管理的流程如图2所示。

需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。需求开发过程有3个主要活动：需求调查、需求分析、需求定义。需求开发过程可分为两个阶段：用户需求调查阶段和产品需求定义阶段，两个阶段在逻辑上通常是以迭代的形式进行的。需求开发过程产生的主要文档有《用户需求说明书》、《产品需求规格说明书》（对于软件产品而言就是《软件需求规格说明书》）。

需求管理的目的是在用户与开发商之间建立对需求的共同理解，维护需求与软件工作成果的一致性，并控制需求的变更。需求管理过程有三项主要活动：

（1）需求确认:开发商和用户共同对需求文档进行评审，双方就需求达成共识后做出书面承诺，使需求文档具有商业合同效果。

（2）需求跟踪:通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。

（3）需求变更控制:依据“变更申请、审批、实施、重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。

需求管理过程产生的主要文档有《需求评审报告》、《需求跟踪报告》、《需求变更控制报告》等。

2．需求的跟踪

需求跟踪的目的是建立与维护“需求、设计、编程、测试”过程的一致性，确保所有的工作成果符合用户需求。需求跟踪有两种方式：

（1）正向跟踪：检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。

（2）逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。

正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵。

组建变更控制管理机构

项目变更是指项目实施过程中由于环境或者其他因素的变化而对项目部分或者全部功能、性能、架构、技术指标、集成方案、进度、质量等方面做出改变。

1．变更控制管理的任务及目标

信息系统项目实施过程中变更是无法避免的。变更控制管理的任务是：建立规范、严格、可行、高效的变更控制体系机制，组建变更控制管理机构，出台变更管理制度；对用户提交的变更请求进行快速的响应、受理；及时分析、研究、评估变更的可行性、成本、代价、范围；对于确定接受的变更请求制订变更实施计划方案及配套应对措施，实施变更任务，进行变更测试检查，做好变更记录。需求变更控制的最终目标是：通过建立严格规范的变更控制管理流程,拒绝不切合实际的变更，减少变更带来的风险，防止变更范围扩大、蔓延，杜绝随意的变更申请及受理过程等。

2．变更控制管理机构的建立

组建有效的变更控制管理机构和制订配套的变更控制管理制度，是进行变更控制管理的重要基础和前提保障，否则变更控制管理将成为一纸空文。变更控制管理机构（形式上可以是“变更控制管理委员会”、“变更控制管理办公室”、“变更控制管理组”等）是一个特殊组织，对项目负责人直接负责，它不受现存的职能组织结构的束缚,可由来自不同机构、不同部门、不同专业、不同岗位的人员组成，各成员划分权限岗位、明确职责、落实责任、协同工作。一般情况下，变更控制管理机构内部应至少配备以下四种角色的成员：

项目管理人员（类似于“项目经理”）：主要负责制订项目管理制度和项目管理计划，督促、检查、落实、考核项目执行过程，做好项目干系人之间的沟通协调工作。

技术负责人员（类似于“总工程师”）：主要负责项目中信息技术平台的分析、建模、设计、测试、实现。

业务管理人员（类似于“业务经理”）：主要负责收集整理业务需求、编写需求说明书、验证和评审需求、管理和控制需求变更。

通信联络人员：主要负责项目组织内部成员之间的信息发布。

需求变更控制 管理工作程序

需求变更的目的是希望软件产品更加符合用户的需求，但是变更涉及的人员多、范围广、影响大，在进行变更控制管理时必须建立严格、规范的变更控制管理工作程序，这样才能使项目始终按照预定的方向、模式、进度进行。

需求变更控制过程中最难办的事情不是“满足用户提出的变更请求”，而是“在用户认同支持、追加项目投资经费的前提下尽快完成变更任务”。用户往往认为提出变更需求是基本权利，而软件开发商往往认为只有义务解决在《用户需求说明书》、《产品需求规格说明书》中预先定义的各类需求，除此以外都应该拒绝或者在用户追加投资的前提下解决。

现实中信息系统项目的目标是具有一定弹性的，这一点尤其重要，用户和软件开发商之间为了达成共同目标不可能针锋相对，项目管理人员需要利用高超的管理艺术、沟通技巧、人格魅力，在对立博弈的关系之中寻求最佳的平衡点。

另外，有必要强调的是，在项目实施过程中，变更处理越早，难度越小，损失越小；变更处理越迟，难度越大，损失也越大。而且，任何变更都必须经过项目建设全部相关方（建设单位、承建单位和监理单位）多方确认后才能计划实施，严禁任何一方擅自变更。对项目变更的范围要有明确的界定，而且项目建设全部相关方对变更范围的理解上都没有任何异议。

《××项目软件需求变更说明书》 篇4

项目名称： 长益高速收费数据分析系统一、概述

因湖南省高速公路联网拆分系统软件升级，导致长益下属收费站入口和出

口交易数据、拆分数据、代收拆分数据无法获取。而现阶段省高管局监控中心无法在上报报表日期内提供拆分数据，从而导致长益高速收费数据分析系统无法输出相关报表。经过深入了解和分析，在与业主方多次探讨后，提出以下变更说明。

二、变更内容

 MTC实收和流量

原始情况：

人工收费系统出口站收费数据和出口流量的导入，是由收费站工作

人员从站级拆帐网下载的“收费数据统计报表”并再录入部分细分数据，导入长益收费数据分析系统。

变更后：

收费站工作人员在分析系统中MTC实收功能模块中只录入出口各车

型实收收入、各车型流量、免费车流量、绿通车流量、系统外收入、绿通车减免金额、免费车减免金额、手工票金额。

运营部工作人员在分析系统中MTC实收功能模块中导入本路段各站

进，其他路段出的代收流量的各车型估算流量。其中包括各车型流量、绿通车流量、免费车流量。

 MTC实得

原始情况：

人工收费系统实得数据的导入，是由收费站工作人员从站级拆帐网

下载的“拆帐统计报表”，导入长益收费数据分析系统。

代收实得的导入，是由运营部工作人员从拆帐网下载的“长张高速

公司名称，版本号

2公路联网收费实际分配收入统计表”，导入长益数据分析系统。

变更后：

运营部工作人员在分析系统中MTC实得功能模块中导入估算MTC各

车型拆分收入。其中包括本路段各车型收入、系统外收入及代收业主各车型收入、系统外收入。

 报表输出

由于原始基础数据的变更，所导致从数据模型上的建立发生了变化，从而将导致原长益数据分析系统输出报表无法根据原来基础数据的数据输出，需要转换为估算的数据输出，需要对所有的报表进行修改。

需要修改的报表有以下：













































 公司－绿色通道车辆 公司－收费站拆帐情况表 公司－单车收费标准计算表 公司－流量对比表 公司－各类车流量收入比重对比图 公司－各类车流量收入比重表 公司－实征率 公司－高速免费车 公司－收费车流量统计 公司－ETC收费车与免费车 公司－月流量分析 公司－ETC征费情况 公司－月收入图 公司－月收费情况总表 公司-收费车流量与收入统计 路劲-收入影响因素对比表 路劲-项目每月输入及车流汇总表 路劲-各站每月收入及车流汇总表 路劲-历年路费收入图 路劲-历年次票车流量图 路劲-日报 省局-交通流量统计月报表 省局-绿色通道和免费车公司名称，版本号

 省局-其他收入分项统计

 三年同天对比-1月

 三年同期对比-2月

 三年同天对比-3月

 三年同期对比-4月

 三年同期对比-5月

 三年同期对比-6月

 三年同期对比-7月

 三年同期对比-8月

 三年同期对比-9月

 三年同期对比-10月

 三年同期对比-11月

 三年同期对比-12月

 周报-高速公路

 周报-总表

 周报-流量图

 周报-收入图

 周报-老路

 月报-月收费

 月报-财务系统内金额拆帐

 月报-月度收费情况

图书馆管理系统(软件需求说明书) 篇5

1.1.系统简述

本系统是为了给图书管理人员和读者借、还书带来便利，除了图书馆内管理的一般功能还外，还包括网上在线查询图书信息、查询本人的借阅情况和续借等功能。

系统名称 ：XX大学图书馆信息管理系统 项目委托单位 ：XX大学图书馆

项目开发单位 ：XX大学管理学院信息管理与信息系统专业 系统最终用户 ：XX大学图书馆工作人员

1.2.编写目的

系统功能需求有：

编目

：分类，标注主题词；录入所有图书的目录及部分图书的内容 借书证管理

：办新证、换证、清理借书证（注、吊销）提供检索服务 ：查图书的目录、在馆状态；查图书内容 流通服务

：借、还、续借、罚款、冻结借书证

图书清理

：遗失、损坏、过时图书及相应目录的清理 统计分析

：分类统计图书、读者、借阅等信息

该文档是为了明确系统需求，规划设计进度，更好地安排系统开发测试，在开发过程中防止错误的出现，本文档供项目经理、开发人员和设计人员参考。

1.3.参考资料

UML基础与Rose建模教程

蔡敏 徐慧慧 黄炳强编著 信息系统分析与设计教程

陈佳

谷锐 李朝辉编著

1.4修订版本记录

本版本为第一版本，暂无修订版本记录

2.术语表

读者信息注销：采集学生或教师的离校信息，对相关借阅信息进行注销，并收回借阅证。

借阅证办理：根据新生入校时技术部采集的新生信息或新进教师信息进行借阅证办理

图书借阅：对读者的借书进行登记，并将资源的状态改为借出，同时修改读者的借阅信息。

图书归还：根据读者的还书，将资源信息改为在馆，修改读者的借阅信息。冻结借阅证：根据读者是否有过分的行为达到冻结借阅证的地步，然后冻结借阅证收回读者借阅书籍的权利。

图书编目：根据图书的ISBN号将图书编码，规放到特定的位置中的一个编码。罚款：读者由于借阅的书籍或者光盘超出规定的时间，超出的时间将要收取一定的现金作为处罚。

3.系统业务流程

3.1概述

图书馆管理系统业务主要是对读者和图书的管理，将具体业务分到分到3个部门来进行管理，分别是：办公室、流通管理部和采编部，各个部门管理相关的业务，并通过相互配合，来完成实现系统的各种功能。

3.2概要调查

采编部门图书目录采购员购进图书名单1图书编目分类3检索服务所需图书信息表读者信息办公室图书管理员借阅证图书管理员借阅证4流通服务图书记录5图书清理图书信息读者读者管理2借阅证管理读者信息借阅证办公室分析报表6统计分析图书管理员读者办公室办公室读者

总体业务流程图

3.3详细调查

3.3.1.办公室业务的详细调查

图书管理员借阅证管理员提交凭证2.1发新证借阅证办公室读者读者登记入馆读者档案图书管理员2.2读者信息变更处理读者登记表2.4注销借阅证注销卡号报表办公室管理员申请挂失表管理员读者退卡申请2.3卡回收管理员办公室

借阅证管理业务流程图

描述：办公室的主要任务是对读者信息以及借阅证的管理，借阅证的办理、挂失、注销等处理。

3.3.2.图书流通管理部业务的详细调查

图书信息借阅证3.1图书借阅所借图书信息读者管理员读者管理员借阅证3.2图书归还所还图书信息图书信息

图书活动业务流程图 描述：

图书借阅：读者从图书馆中找到所需图书拿到图书流通管理部的管理员处，管理员根据读者的借阅信息和图书的基本信息来处理读者的借阅请求。

图书归还：读者将借阅到的图书拿到图书流通管理部管理员处，管理员根据读者的借阅信息处理归还业务，如果读者借阅超期则通知读者缴纳罚款，否则将无法借阅图书。

遗失图书分析报告5.1遗失图书处理遗失图书处理报告管理员3管理员2管理员1损坏图书分析报告5.2损坏图书处理损坏图书处理报告5.4更新报告图书目录更新流通管理部管理员2过时图书分析报告5.3过时图书处理过时图书处理报告

图书管理业务流程图 描述：

3.3.3.采编部业务的详细调查

图书采购业务流程图

3.3.4.详细业务流程描述

1.购书业务管理 1.1清单讨论 采编部根据近期出版的图书和比较典型的书籍，列出一个预采购图书的清单，流通管理部门的职工也可以根据情况提出相应的购书方案，然后通过讨论确定最终的购书方案。

1.2购买图书 通过会议的讨论确定购书清单，采编部将购书清单发送给商家，并交纳购书的金额

1.3派送购买图书 2.编目图书 2.1编目图书 编目部将从出版社购得的图书，根据ISBN号，以及图书馆图书存放的位置，将图书进行编目输入到图书的数据库中，并商家根据采编部的购书清单和交纳的金额，将相应的书本通过邮递的方式发送到采编部

采编部 采编部

商家 采编部 采编部 编目部，流通管

理部 将编目过的图书交予流通部上架

3.读者请求处理 3.1请求借书 读者在图书馆中找到自己想借阅的图书，将图书和自己的借阅证交到流通部的借阅管理员处，由管理员处理借阅事务

3.2处理借阅请通过读者提交的图书和借阅证，先判断读者的借阅信息，是求 否有超期的图书或者借阅的图书数量是否达到上限，如果条件都达到，就修改读者的信息和书籍的信息

3.3请求归还 读者将自己借阅的书本交予流通部归还处的管理员，向管理员提出归还图书的请求

3.4处理归还请流通部管理员通过读者提交的书本，判断所借图书是否超期，求 是否有污损，提醒读者是否要缴纳罚款，并处理书籍的信息 3.5缴纳罚款 由于读者所借图书超期或者图书有破损，处罚读者的行为，读者将相应金额的罚款和自己的借阅证交到罚款处的管理员，由管理员处理

3.6处理罚款 根据读者提交的借阅证，查询读者所需缴纳罚款的信息，并收取读者相应的金额罚款，处理读者罚款的信息

4.办公室职能 4.1请求信息处读者提出自己办证入馆、挂失或者注销信息的请求，并填写理 表格提交自己的个人信息，交予办公室的管理员

4.2处理请求 办公室的管理员根据读者提交的请求以及相应的信息，判断是否能够处理请求的信息，若能处理便处理，否则提醒提交信息者。

4.系统用例模型

4.1参与者描述

流通管理部 读者，流通管理

部 流通管理部

读者，流通管理

部 流通管理部 读者，流通管理

部 流通管理部 办公室 读者 办公室

描述：系统的参与者主要是按照部门划分的，每个部门可以有多个员工，但每个部门的员工只能处理本部门的业务。

4.2高层用例模型 4.2.1.总体用例图

描述：系统中各个参与者与系统功能的关系

4.2.2.办公室高层用例图

描述：办公室的主要功能就是对读者信息的增删改查

4.2.3.流通管理部高层用例图

描述：流通部处理读者图书的借阅归还、图书信息处理和罚款处理

4.2.4.采编部高层用例图

描述：采编部的主要功能就是采购图书、编目图书和更新图书信息

4.2.5.读者高层用例图

描述：读者在系统中的功能主要就是查询个人信息、借阅图书、归还图书、缴纳罚款

4.3 分层用例模型

4.3.1.办公室工作的子用例图

用例说明：

（1）简要说明：在操作界面上选择需要的功能选项，包括登记办证入馆、借阅证挂失、借阅证挂失的取消、借阅证注销、，选择特定的功能后进入相应的操作界面，界面内主要包括查询、新增、修改、删除、退出功能。

（2）前提条件：操作者拥有操作权限。

（3）事件流

打开办公室管理员操作界面 登录管理界面

显示权限内的功能选项

提供查询、新增、修改、删除、退出操作选项

选择查询功能

获得读者的借阅证号或者学号

按读者借阅证号或者学号以及其他重要信息查询 判断是否得到查询结果 如果未得到查询结果

则提示：“无符合条件的读者信息” 否则

显示查询结果

选择新增功能

获得读者的学号，姓名等重要必须的信息 输入相应的信息并提交存盘 判断是否成功 如果存盘成功 则提示：“新增读者成功”

否则

提示：“新增读者操作失败”

选择修改功能

获得读者的借阅证号或者学号 显示查询出的结果 输入相应的修改信息 提交并保存修改信息 判断是否修改成功 如果修改成功

则提示：“修改读者信息成功” 否则

提示：“修改读者信息失败”

选择删除功能

获得读者的借阅证号或者学号 显示查询出的结果 选择删除操作

判断删除操作是否成功 如果删除成功

则提示：“删除读者信息成功”

否则

提示：“删除读者信息失败”

选择退出功能

终止管理者的用例

（4）事后条件：正确的信息保存在数据库中（5）非功能性需求：

在输入和修改操作中，对输入的错误信息要迅速提示

4.3.2.采编部工作的子用例图

用例说明：

（1）简要说明：在操作界面上实现图书编目的处理

（2）前提条件：获得图书的关键信息，操作者拥有操作权限

（3）事件流：

打开图书编目界面 输入图书的重要信息 进行图书编目 判断处理是否成功 如果处理成功

显示处理后图书的编号 并提示：“处理成功” 否则

提示：“处理失败，请确定输入信息的正确性” 返回至图书编目界面

（4）事后条件：正确的图书编号保存在数据库中（5）非功能性需求

在输入和修改操作中，对输入的错误信息要迅速提示

4.3.3.流通管理部子用例图 4.3.3.1.图书借阅用例图

用例说明：

（1）简要说明：在操作界面上显示处理图书借阅

（2）前提条件：获得借阅图书的编号和读者的借阅证号，操作者

拥有操作权限

（3）事件流：

打开借阅处理的界面 输入读者的借阅证号 显示读者的借阅信息 如果有图书超期、拖欠罚款未交或借阅已达上限

提示读者未能借书的信息，不能借阅图书

否则

输入图书的编号

显示图书的信息

处理借阅请求

判断借阅操作是否成功 如果处理成功

提示：“借阅图书处理成功”

显示读者借阅的信息 否则

提示：“借阅处理失败，请确定所输入信息的正确性”

返回至借阅处理界面

（4）事后条件：正确的借阅处理信息保存在相应的数据库中（5）非功能性需求：

在输入和修改操作中，对输入的错误信息要迅速提示 4.3.3.2.图书归还用例图

用例说明：

（1）简要说明：在操作界面上显示处理归还图书信息

（2）前提条件：获得归还图书的编号，操作者拥有操作权限（3）事件流：

打开归还处理的界面 输入图书的编号

显示图书借阅的信息以及借阅者信息 如果图书超期

提示读者超期信息 处理归还图书操作 判断归还操作是否成功 如果处理成功

提示：“归还处理成功” 显示归还后读者的借阅信息

否则

提示：“归还处理失败，请确定输入信息的正确性” 返回至归还处理界面

（4）事后条件：正确的罚款处理信息保存在数据库中（5）非功能性需求：

在输入和修改操作中，对输入的错误信息要迅速提示

4.3.3.3.罚款处理用例图

用例说明：

（1）简要说明：在操作界面上显示处理罚款处理信息

（2）前提条件：获得读者的借阅证号，操作者拥有操作权限（3）事件流：

打开罚款处理的界面 输入读者的借阅证信息 显示读者的超期记录 处理读者的罚款信息 判断罚款处理是否成功 如果处理成功

提示：“罚款处理成功” 显示处理后的罚款记录 否则

提示：“罚款处理失败，请确定输入信息的正确性” 返回至罚款处理界面

（4）事后条件：正确的罚款处理信息保存在数据库中（5）非功能性需求：

在输入和修改操作中，对输入的错误信息要迅速提示

4.3.3.4.图书处理用例图

用例说明：

（1）简要说明：在操作界面上实现图书信息的处理

（2）前提条件：获得图书的关键信息，操作者拥有操作权限

（3）事件流：

打开图书处理界面 输入图书的重要信息 修改或删除图书的信息 判断处理是否成功

如果处理成功

显示处理后图书的信息 并提示：“处理成功” 否则

提示：“处理失败，请确定输入图书信息的正确性” 返回至图书处理界面

（4）事后条件：正确的图书信息保存在数据库中（5）非功能性需求

在输入和修改操作中，对输入的错误信息要迅速提示

4.3.4.读者子用例图 4.3.4.1.借阅图书用例图

用例说明

（1）简要说明：在操作界面上显示借阅图书处理的信息

（2）前提条件：获得读者的借阅证号和所借图书的信息、操作者拥有权限

（3）事件流：

打开读者借阅图书处理的界面 输入读者的借阅证号 判断读者能否借书 如果能够借书

则提示：“读者已借X本书，可借Y本书，无罚款信息” 输入所借图书信息 处理借阅

判断借阅处理是否成功 如果成功

则提示：“读者借阅图书处理成功”

返回至功能选择界面 否则

提示：“读者借阅处理失败，请确定读者信息的正确性”

返回至借阅处理界面

否则

提示：“读者借书已满”或者“有图书逾期记录”

返回至功能选择界面

（4）事后条件：正确的借阅处理信息保存在数据库中（5）非功能性需求：

在输入和修改操作中，对输入的错误信息要迅速提示

4.3.4.2.图书归还用例图

用例说明：

（1）简要说明：在操作界面上显示归还图书处理的信息

（2）前提条件：获得读者借阅证号和归还图书的信息，操作者拥有处理归还图书的权限

（3）事件流

打开读者归还图书的操作界面

输入读者借阅证号显示读者的借阅信息 显示读者图书是否超期并提醒读者 处理归还操作 判断操作是否成功 如果成功

则提示：“读者归还图书成功”

选择返回功能

界面返回至管理员登陆成功后的功能选择界面 否则

提示：“归还图书失败，请确定输入信息的正确性”

返回至归还图书界面

（4）事后条件：正确的图书归还后保存在数据库中（5）非功能性需求：

在输入和修改操作中，对输入的错误信息要迅速提示

4.3.4.3 个人信息查询用例图

用例说明：

（1）简要说明：在登录后显示具体的详细信息（2）前提条件：了解个人的借阅证号和密码（3）事件流

打开读者登录的页面 输入借阅证号及密码 判断是否登录成功 如果登录成功

则提示：“登录成功” 显示读者的个人信息 选择退出功能

退出读者查询 否则

提示：“密码错误”、“借阅证号错误”和“查询不到相应的结果”

（4）非功能性需求：

在输入信息操作时，对输入的错误信息要立即提示

4.4主要用例间的活动描述 4.4.1 采编部活动图

4.4.2流通管理部活动图

4.4.3 借书活动图

4.4.4 还书活动图

4.4.5 办公室活动图

4.5核心对象的状态变迁描述 4.5.1借阅证状态图

4.5.2图书状态图

5.需求原型系统

5.1需求原型总体结构

5.2各用例的需求原型

5.2.1流通管理部门的用例情景描述 5.2.1.1借阅图书的情景描述

5.2.1.2还书处理的情景描述

5.2.1.3罚款处理的情景描述

5.2.1.4图书处理的情景描述

5.2.1.5删除图书的信息情景描述

5.2.2读者的情景描述 5.2.2.1查询借阅书籍信息

5.2.3采编部门的情景用例描述 5.2.3.1图书编目入馆的情景描述

5.2.4办公室的情景描述

5.2.4.1读者信息的添加情景描述

5.2.4.2读者借阅证的挂失情景描述

5.2.4.3读者信息的删除情景描述

6.其他需求

学生成绩管理系统需求分析说明书 篇6

1． 引言

1.1 摘要

 开发系统的名称：学生成绩管理系统  开发系统的目标：

节约资源，提高学籍信息的精确度。方便快速操作，精简人员，节约开支。结合学校管理的实际需要，实现对学生成绩等数据进行有效管理，提供查询分析功能等。 开发系统的功能：

学生查询功能，管理员查询功能、添加功能、修改功能、删除功能、汇总功能、统计功能。1.2 背景

它已进入人类社会的各个领域并发挥着越来越重要的作用。作为计算机应用的一部分,使用计算机对学生成绩信息进行管理,具有手工管理所无法比拟的优点。例如，检索迅速、查找方便、可靠性高、存储量大、保密性好、寿命长、成本低等。这些优点能够极大地提高学生档案管理的效率,也是企业的科学化、正规化管理,与世界接轨的重要条件。因此，开发学生成绩管理系统很有必要。 项目的承担者：软件工程0511班小组：李志洋，卢金华，周波  用户：某大学相关技术人员、管理人员及学生

 本系统是学校教学管理系统的一个功能模块，可以快速方便地对学生成绩进行管理、输入、输出、查询，和教务管理系统、教材管理系统、班务管理系统是紧密相连的。例如，教务管理系统要通过成绩管理系统来存储学生成绩信息；班务管理系统也要通过成绩管理中的数据库对学生成绩进行管理。1.3 参考和引用资料

《管理信息系统》.薛华成.清华大学出版社 《软件文档编写》.潘孝铭，辛明海.高等教育出版社 《软件工程》.钟珞.清华大学出版社 1.4

专门术语定义  随着科学技术的不断提高,计算机科学日渐成熟,其强大的功能已为人们深刻认识,2． 项目概述

2.1 项目的主要工作内容

2.1.1 确定对系统的综合要求  系统功能要求

系统必须完成的功能有学生查询功能，管理员查询功能、添加功能、修改功能、删除功能、汇总功能、统计功能。此阶段必须确定下来。 系统性能要求

必须考虑到系统的响应时间、系统需要的存储容量以及后援存储、重新启动和安全性等方面。 运行要求

必须确定支持系统运行的系统软件是什么，采用哪种数据库管理系统，需要什么样的外存储器和数据通信接口等。 将来可能提出的要求.应该明确的列出那些虽然不属于当前系统开发范畴，但是根据分析将来很可能会提出来的要求。2.1.2 分析系统的数据要求

通过建立概念模型的方法来分析系统的数据要求。例如，利用数据字典可以全面准确地定义数据。2.1.3 导出系统的逻辑模型

用数据流图、数据字典等，根据对系统的综合要求和数据要求的结果导出系统的详细的逻辑模型。2.1.4 修正系统开发计划

根据在分析过程中获得的对系统的深入、细致的了解，比较准确地估计系统的成本和进度，修改以前制定的开发计划。2.1.5 开发原型系统

构建原型系统用来检验关键设计方案的正确性及系统是否真正满足用户的需要。

2.2 系统需求说明

2.2.1 现行系统的现状调查说明

学生成绩管理系统主要提供方便高效的管理功能以及网上的信息查阅平台，学生可以通过该系统查阅相关信息，管理员可以管理所有信息。 现行系统的目标：

(1)管理员能够方便的对信息进行添加、修改、删除、查询、汇总、统计等操作。

(2)可以将数据库发布到网上，进行资源共享。

(3)学生可以在自己的权限内对信息进行访问，查询相关信息。 现行系统的主要功能：

(1)学生查询功能：为了方便学生查找成绩等信息，将所有信息按照需要进行分类。这样学生就能很方便的找到自己所需要的信息。

(2)管理员查询功能：管理员可以通过条件选择查询所有信息，并进行排序。

(3)添加功能：管理员可以通过填写表格的形式输入学生成绩等相关信息。系统可以自动避免重复信息。

(4)修改功能：管理员可以对数据库中的信息进行修改。系统能够通

过管理员给出的条件查找出所要修改的信息，对修改后的信息进 行保存，并自动查找是否是重复信息。

(5)删除功能：管理员可以对数据进行删除操作。系统能够通过管理员给出的条件查找出要删除的信息，并提示是否确定删除，如果确定删除，则把相关信息从数据库中删除。

(6)汇总功能：管理员可以通过此功能对信息进行汇总。

(7)统计功能：管理员可以通过此功能对信息进行统计。

2.2.2 业务流程说明

 学生成绩管理业务流程图1

图1

从以上的业务流程图可以看出学生成绩管理的基本业务及动态走向，从各科教师给出成绩到学生拿到成绩单要经过系部、教务处等部门。

 学生成绩管理业务流程图2

图2  学生成绩管理业务流程图3

图3 2.3

系统功能说明

 成绩管理系统数据流程图

单科成绩

F3

成绩单

成绩统计信息

F2

F8

顶层图

单科成绩

F3

成绩

F10

学生成绩

F8

F2.1

F2.3

F2.2

补考成绩单

二层图

S1学生科，S2学生，S3教师，S4教务处

P3.1录入，P3.2统计，P3.3查询，P3.4发布

F2成绩单，F2.1学生成绩，F2.2学生成绩单，F2.3补考成绩单，F3单科成绩，F8成绩统计信息，F10成绩，D3学分，D4成绩档案

2.4 系统的数据要求说明  编写数据词典

3． 实施总计划

图书馆管理系统(软件需求说明书) 篇7

本文将以软件需求工程为侧重点、从软件需求变更的原因、影响、原则及管理方案为研究领域进行分析和讨论。

一、软件需求变更的主要原因分析

1、客户需求因素。

在软件的开发过程中, 客户会随着项目开发的进程逐渐达成对软件系统的深入了解和认识, 在不断的思考过后形成了新的需求信息或改进的需求信息, 进而会提出满足其新需要的软件变更条款。2、系统内部因素。在软件开发过程中, 计算机外部硬件设备、系统软件、系统数据等内部系统之间的相互适应要求都会引起软件需求的变更。这种需求变更将会以硬件设备、操作系统、系统软件等原始系统因素为基础进行更新、升级、换代, 以此确定软件设计的安全性、兼容性和准确性。3、业务环境因素。在软件开发过程中, 与软件开发相关联的制度、规范、政策等的重新改写与设定, 或是软件开发业务要求的不断改变都将会引起软件需求变更。例如, 软件的需求会随着保险制度的变化而变更, 会随着交通制度的变化而变更等等。4、需求开发缺陷因素。在软件需求开发过程中, 需求信息调查研究、需求文档的编写及评审等工作的不足都是影响软件需求变更的主要原因。

二、软件需求变更的主要影响分析

1、影响软件开发的实际进度。

频繁的需求变更不仅需要大量项目人员的支持, 还需要投入大量的经费, 如果投入的力度过大, 将会导致软件开发项目超过预期甚至导致失败。

2、影响软件开发质量的优良。

在软件开发过程中, 需求的不断变更将会导致原有的需求链断裂, 对原定需求的部分环节造成影响, 而这些影响又将导致软件开发项目设计的改变, 最终导致系统质量的下降, 开发效率的降低。

3、影响客户与开发者之间的相互合作。

软件开发是客户与开发者之间的一种相互信任、相互合作的过程。如果二者之间在软件需求变更上产生不同意见, 而且没有得到妥善的处理, 将会导致二者之间的合作关系破裂, 甚至造成软件开发中断等严重后果。

三、软件需求变更的处理原则

1、完整性原则。

完整性是软件安全的基本要点。在软件开发过程中, 要保证需求变更信息的采纳收集、汇总整理、评判审核、监视追踪等环节的完整性, 保证软件需求变更能够按照规范的流程进行操作。

2、合理性原则。

在软件开发过程中, 客户与需求分析人员将会以不同的视角、不同的态度评估需求变更条件, 要想达成软件开发的精确性, 就需要在用户需求、软件技术和整体开发能力的基础上, 达成需求变更的合理性, 实际性。

四、软件需求变更的有效管理方案

1、达成开发者与客户之间的有效沟通。

在发生软件需求变更时, 需求分析人员要与客户进行及时有效的沟通和反复的确认, 向客户说明开发建议和解决方案并制定相应的合同规范, 以此来达成对客户的承诺和软件修改后的满意度。2、制定软件需求变更信息的整理报告。在软件需求变更过程中, 要对客户需求的规范、变更后的功能、软件质量目标、变更解决方案等信息进行整理、分析和记录, 制定明确的需求分析整理报告, 以此来确保需求变更的准确性、实际性与科学性。3、进行明确、合理的人员分工。在需求变更达成协议后, 就需要对开发人员进行合理的安排和组织, 对操作人员和测试人员进行明确的分工;利用合理的需求变更管理工具, 达成整体软件项目开发的高效和优质。4、做好需求和产品特性的评审和测试工作。做好需求变更相关信息的记录后, 需求分析人员要组织开发、测试与客户等相关人员对更改后的需求进行评审和测试, 筛出掉不符合实际的变更需求, 确保需求变更流程的顺利进行。在软件变更实施的最后阶段, 要对软件产品系统进行测试, 以检验其是否满足客户的原定需求、是否达到了预期的效果和期望, 以保证更改后产品系统的基准性和安全性。

总之, 在出现软件需求变更状况时, 首要的就是与客户做好沟通和协商, 其次要做好需求变更信息的详细记录, 最后做好软件需求变更后的测试。只要做好这关键的三部, 就能够充分确保软件开发的规范化和优质化。

参考文献

[1]李厚明.软件项目需求变更风险管理[D].山东大学2012

机票订票系统需求规格说明书 篇8

三、需求规格说明书

1．引言................21.1编写目的...............2

1.2项目背景...............2

1.3参考资料...............2

2．任务概述...................2

2.1目标...................2

2.2运行环境...............2

2.3条件与限制.............2

3．数据描述...................33.1静态数据...............3

3.2动态数据...............3

3.3数据库介绍.............3

3.4数据词典...............3

4．功能需求...................44.1功能描述...............4

5． 性能需求..................55.1系统处理的准确性和及时性.............5

5.2系统的开放性和系统的可扩充性................5

5.3系统的易用性和易维护性...............5

5.4系统的标准性...........5

5.5系统的先进性...........6

6． 运行需求..................6

7．其它需求...................6

第 1 页

1．引言

1.1编写目的本机票预定系统在可行性研究的基础上，是为了进一步明确机票预订系统的软件需求，以便安排项目规划和进度，组织软件开发与测试，撰写本文档。

本文档供设计人员、开发人员参考。

1.2项目背景

开发软件名称：机票预订系统

项目任务提出者：兰州理工大学软件工程学院 项目开发者：第13小组 用户：航空公司

实现软件单位：兰州理工大学软件工程学院

1.3参考资料

1.《软件工程导论》，张海藩，清华大学出版社。2.《实用软件工程》，郑人杰等，清华大学出版社。3.机票预定系统项目计划任务书。4.机票预订系统可行性研究报告。

2．任务概述

2.1目标

旅客在飞机起飞前一天凭取票通知和帐单交款取票，系统核对无误即打印出机票给旅客。此外航空公司为随时掌握各个航班飞机的乘载情况，需要定期进行查询统计，以便适当调整。

2.2运行环境

操作系统：Microsoft Windows 7 支持环境：IIS 5.0

数 据 库：Microsoft SQL Server 2000

2.3条件与限制

1.人力、资金、时间的约束

机票预订系统实施的目标就是要带给轮胎生产公司看得出见的效益，其开发过程中也要考虑到人力、资金和时间的约束。因此，在设计中，重点是企业间信息的网络交流，能提供各部门间的方便快捷的联系，并提高数据统计的即时性、准确性、方便性，给公司带来良好的效益。

2.在分析系统功能时要考虑有关证件的合法性验证。

3．数据描述

3.1静态数据

系统管理员，售票员，服务器终端显示数据，客户机终端显示数据，客户机终端显示数据。

3.2动态数据

事务航班信息的更新，查询请求。

3.3数据库介绍

数据库采用sql server。

3.4数据词典

名字：订票申请表单 描述：旅客订票时所填的资料

定义：订票申请表单=旅客姓名+旅客性别+起飞日期+飞行目的地+座位类型位置：在客户端由旅客填写 名字：航班信息

描述：所有从本地起飞的班机信息

定义：航班信息=航班号+起飞日期+飞行目的地+座位空数+商务仓票价+经济仓票价 位置：从服务器端查询后，发送到客户端 名字：帐单信息

描述：已定票的旅客信息资料

定义：帐单信息=帐单号+旅客姓名+旅客性别+旅客身份证号+工作单位

位置：在服务器端产生，发送回客户端（client端）名字：机票信息 描述：旅客所定机票

定义：机票信息=旅客姓名+旅客性别+身份证号码+航班号+起飞时间+飞行目的地+座位号

4．功能需求

4.1功能描述

5．性能需求

5.1系统处理的准确性和及时性

系统处理的准确性和及时性是系统的必要性能。在系统设计和开发过程中，要充分考虑系统当前和将来可能承受的工作量，使系统的处理能力和响应时间能够满足企业对信息处理的需求。在系统开发过程中，必须采用一定的方法保证系统的准确性。

5.2系统的开放性和系统的可扩充性

机票预订系统在开发过程中，应该充分考虑以后的可扩充性。例如企业中管理模块的加入（人事管理、工资管理、日常事务管理等）也会不断的更新和完善。所有这些，都要求系统提供足够的手段进行功能的调整和扩充为ERP系统。而要实现这一点，应通过系统的开放性来完成，即系统应是一个开放系统，只要符合一定的规范，可以简单的加入和减少系统的模块，配置系统的硬件。通过软件的修补、替换完成系统的升级和更新换代。

5.3系统的易用性和易维护性

机票预订系统是直接面对使用人员的，而使用人员往往对计算机并不时非常熟悉。这就要求系统能够提供良好的用户接口，易用的人机交互界面。要实现这一点，就要求系统应该尽量使用用户熟悉的术语和中文信息的界面；针对用户可能出现的使用问题，要提供足够的在线帮助，缩短用户对系统熟悉的过程。

5.4系统的标准性

系统在设计开发使用过程中都要涉及到很多计算机硬件、软件。所有这些都要符合主流国际、国家和行业标准。例如在开发中使用的操作系统、网络系统、开发工具都必须符合通用标准。如规范的数据库操纵界面、作为业界标准的TCP/IP网络协议及ISO9002标准所要求的质量规范等；同时，在自主开发本系统时，要进行良好的设计工作，制订行之有效的软件工程规范，保证代码的易读性、可操作性和可移植性。

5.5系统的先进性

目前计算机系统的技术发展相当快，做为机票预订系统工程，应该保证系统在一段时间内是先进的，在系统的生命周期尽量做到系统的先进，充分完成企业信息处理的要求而不至于落后。这一方面通过系统的开放性和可扩充性，不断改善系统的功能完成。另一方面，在系统设计和开发的过程中，应在考虑成本的基础上尽量采用当前主流并先进且有良好发展前途的产品。

6．运行需求

1、服务器端子系统的运行要求：系统软件：windows 7数据库管理系统：SQL server

硬件要求：英特尔至强 2.0Ghz、1G RAM、100G HD2、客户端子系统的运行要求：系统软件： Windows 7 数据库管理系统：SQL server

硬件要求：CPU：英特尔奔腾III 1.0Ghz、256M RAM、10G以上可用空间

7．其它需求

酒店管理系统软件设计说明书 篇9

需求规格说明书

目录

1.引言……………………………………………………….3 1.1目的……………………………………………………..3 1.2 定义…………………………………………………….3 1.3 产品的范围和产品特性……………………………….3 1.4 参考文献……………………………………………….4 2.综合描述………………………………………………….4 2.1 产品的前景…………………………………………...4 2.2 产品的描述…………………………………………...4 2.3 用户类和用户特性…………………………………...4 2.4 运行环境……………………………………………...5 2.5 设计和实现的约束条件……………………………...5 2.6 假设和依赖…………………………………………...5 3.外部接口需求…………………………………………….5 3.1 用户接口……………………………………………...5 3.2 硬件接口……………………………………………...6 3.3 软件借口……………………………………………...6 3.4 通信接口……………………………………………...6 4.系统特性………………………………………………….6 4.1前台管理………………………………………………6

4.2 消费管理……………………………………………...8 4.3 收银管理……………………………………………...9 4.4 客房服务……………………………………………...11 5.其他非功能需求…………………………………………13 5.1 性能需求……………………………………………..13 5.2 安全性需求…………………………………………..13 5.3 软件质量需求………………………………………..13 6.附件………………………………………………………14

附录 分析模型…………………………………………...14

1.引言 1．1目的

随着旅游业的民展，酒店、餐饮娱乐行业日趋发达，引入全方位的电脑服务和电脑管理日益流行。同时，酒店和餐厅娱乐业引入电脑服务和管理也取得了优良的经济效益和社会效益。酒店管理系统将先进的电脑技术和现代酒店服务管理管理完美地结合起来，实现了住宿，餐饮全新概念的服务和管理方式。

酒店管理的电脑化，不仅是体现酒店现代化形象的一个重要标志，而且对于提高员工的工作效率，加速资金周转，降低各项成本及改善服务质量都有十分积极的作用。

1．2定义

1.客房预定系统:可以处理散客预定、团体预定、客房预定、预定未到处理、预售查询等事务。

2.前台接待系统：可以处理散客入住登记，合约入住，团体自动入住和手动入住，补填客单，修改客人信息、转房、调房、设置房态、客人留言，预定客房查询、可售客房查询等事务。

3.前台必银系统：处理记账、埋单、限制客人消费、退房、押金加入、查账、转账、设置跑单、客用保险箱管理、团体埋单及退房业务。

4.账务系统：除具有收银的功能外，还具有纠错、报表输出等功能，能将损失降至最低。5.管家系统；可处理设置净房、脏房、坏房及取消坏房，设置SKIP房、SLEEP房，查询诌房表、脏房表、坏房表，房间状态，新入住查询等业务。

6.电话系统：具有自动计费、夜间稽核，客人信息查询、动态房态查询、房间明细账查询、收银员报表、当日入住客人报表等功能。

7.客历系统：能处理客人手工、自动输入，客人资料查询与修改，黑名单，入住客人自动查询客历、入住客人自动归入客历。

8.合约系统：可将酒店签约的单位或个人的资料输入电脑，并可随时查询和更新。

9.经理系统：可修改客房定价，增加、删除、修改各级密码，个性特别客单，设置系统参数，内部银行系统，数据整理，自我诊断，数据备份。

10.总经理系统：具有客单查询，查询客房状态，查询可售情况，客房占用统计，账务查询，万能查询，报表输出功能

11.密码管理系统：可以管理客户和酒店的各种密码。

12.报表系统：主要是对处理一些非账务表单。主要有客房占用表、转房改租表、预定未到表、客房取消表、房租分析表、经营统计表、可售情况表、房间状态表、坏房状况表、日租统计表、合约销售表。

13.账务报表：主要是处理酒店的日常的账务报表，有收入报表（前台收入明细表、现付收入明细表）、消费报表、顾客账务（住房账务、离店客人账务各跑单账务）、交班报表、信用卡报表、街账报表、应收报表、催账报表、转账报表、借贷报表、联网消费、酒店总表。

1．3产品的范围和产品特性

“酒店管理系统”允许酒店工作人员对酒店的客房、员工以及入住酒店的顾客进行客房入住、酒店服务等一些管理。“酒店管理系统”实施后，能节约人力资源，提高服务质量，方便各项管理。账务处理的时间明显减少，数学计算上的错误也会消失。对客房状态（如是否入住，入住顾客信息等）的查询与统计也显得非常方便，减少了顾客等待与员工分类统计的时间。详细的项目描述请参见酒店管理系统前景和范围文档。文档中这一部分的标题为“初始版本和后续版本的范围”，列出了按照进度计划在这一版本中实现的全部或部分特性。

1.4 参考文献

1）《软件需求》Karl E.Wiegers(美)著 清华大学出版社

2）前期所写的《酒店管理系统的前景和范围文档》

3）《现代软件工程》 孙涌等著 北京希望电子出版社

2.综合描述

2.1 产品的前景

随着计算机技术的飞速发展，信息时代的到来，信息改变了我们这个社会。各类行业在日常经营管理各个方面也在悄悄地走向规范化和网络化。客房管理的信息化程度体现在将计算机及网络与信息技术应用于经营与管理，以现代化工具代替传统手工作业。无疑，使用网络信息化管理使客房管理更先进、更高效、更科学，信息交流更迅速。

酒店客房管理系统是酒店经营管理中不可缺少的部分，它的内容对于经营的决策者和管理者来说都至关重要,所以客房管理系统、信息管理系统应该能够为用户提供充足的信息和快捷的查询手段。但一直以来人们使用传统人工的方式管理文件档案，这种管理方式存在着许多弊端，如:效率低、保密性差，容易出现差错等，且对于查询空房间及已定房间等极为不方便。在当今时代，这些完全可以改用计算机来代替人的手工操作。

作为计算机及网络应用的一部分，使用计算机对客房信息进行管理，具有手工管理所无法比拟的优点。例如:检索迅速、查找方便、可靠性高、存储量大、保密性好、寿命长、成本低等。这些优点能够极大地提高客房经营管理的效率，也是企业的科学化、正规化管理，与世界接轨的重要条件。且办事效率也是决定收入的一个关键因素。

“酒店管理系统”代表了酒店管理的信息化，不仅是体现酒店现代化形象的一个重要标志，而且对于提高员工工作效率，加速资金周转、降低各项成本及改善服务质量都有十分积极的作用。

2.2 产品的描述

一个成熟的酒店管理系统不仅仅是记录酒店客人的信息，提供查询，报表打印等一 系列简单的工作，它能让工作人员从烦琐的手工操作中解脱，并且酒店管理系统本身就 代表着一种管理方法。随着它的深入，将带动企业的运作，为管理和决策提供支持。本项目在经过对各酒店软件进行分析和研究后，参考国际上的先进酒店软

件管理思想，结合中国酒店的实际特点，认为可将整个酒店管理系统细分为五个子系统：（1）前台管理系统（2）消费管理系统（3）收银管理系统（4）客房服务系统（5）系统维护

2.3 用户类和用户特性

酒店前台工作人员（优先考虑）：前台服务员的主要职能是负责订房和退房，以及查询入住的客户信息。所有该角色只可以使用部分功能，包括客房经营管理、客户信息查询、个人密码修改以及注销功能。前台工作人员对客房信息进行管理，包括对客房的基本信息(如客房号、客房类型客房位置等)进行检索、录入和修改。工作人员根据酒店规定可 定义客房类型，并对其进行管理，包括对客房类型的基本信息(如类型名称、面积、床位、价格等)进行检索、录入和修改系统。界面会自动显示各种房类的订房情况，以方便前台接待控制房态。按客人姓名系统可自动调出回头客信息 及历次住店统计信息以确定房价优惠、优惠时段和客人具体的消费记录等。

酒店管理人员：酒店管理员享有最高权限，可以使用酒店客房管理系统所提供的所有功能，包括员工信息维护、客房类型维护、客房信息维护、客户信息查询、经营状况统计、个人密码修改以及注销功能。

顾客：顾客可以在酒店提供的网上酒店管理系统进行自助查询酒店的一些相关信息，以及预定客房等。

财务管理部门：根据酒店客房的业务记录，酒店财务管理部门的工作人员可选择客房类别和日期的统计方式对营业额进行统计。他们需要接受培训，学会如何让使用计算机以及一些office应用。

酒店房务服务人员：酒店的房务服务人员利用系统可看到系统根据自家酒店的实际情况按顺序房号列出客房，很直观地显示客房所属的房间类型及用图形及颜色表示不同的房态，有没有顾客入住、退房等，客房需要什么样的服务，是否需要打扫、服务。

2.4 运行环境

为了达到系统要求，必须依靠高起点的硬件环境和软件开发工具来保证系统的稳定和正常运行。酒店电脑系统要求24小时连续运行，数据量大，可靠性要求高，因此整个电脑系统供电采用专线方式，加配lips（不间断供电系统），并合理接地，以便保障整套系统的正常运行。

2.5 设计和约束条件

CO-1:部分子系统将使用酒店本来的业务流程。

CO-2:系统必须操作简单、用户手册通俗易懂。

CO-3：该服务器实现要使用由公司批准的Red Hat Linux版本和Apache HTTP Server.2.6 假设和依赖

AS-1: 酒店拥有一台打印机和传真机，能方便打印报表，以及对预定客房的商务传真进行处理。

AS-2: 酒店有链接外网的服务器或计算机，能提供网上预定功能，方便顾客预定。DE-1: 对于经常光顾或要求打折的顾客以及节假日或者店庆优惠活动，应具备折扣管理功能。

DE-2: 对于使用酒店管理软件前的电话预定等，该管理软件应该有专门的录音功能。

3.外部接口需求

3.1 用户接口（User Interfaces,UI）

UI-1:入住登记界面应包含：部门，可选设施图标区，宾客登记信息区，选定设施列表。

UI-2：消费点单操作界面应包含：部门选择，总账单列表区，子账单列表区，消费记录区，消费品选择区。

UI-3:外卖零单消费界面应包含：消费品选择区，消费记录区，支付方式选择区。UI-4:在退房结账界面应包含：部门选择，总账单列表区，子账单列表区，消费明细表，结账操作面板。

3.2 硬件接口（Hardware Interfaces,HI）

HI-1:采用基于超5类双绞的综合布线系统，同时支持语音和数字的传输。HI-2：对机器的指示是：CPU2400转以上，显示器支持800*600分辨率，基本内存512兆推荐2G，Windows兼容打印机。

3.3 软件借口（Software Interfaces,SI）

“人事管理系统”。“人事管理系统”通过程序界面与“酒店管理系统”进行通信，完成下面这些工作：

1：提取人员业务完成情况，作为进行绩效考核的依据。

2：根据酒店管理系统中各部门的项目消费情况，作为合理分配人员的依据。

3.4 通信接口（Communications Iterfaces,CI）

CI-1：“酒店管理系统”接收熟客的电子邮件预订，由操作员将预订信息输入系统。

CI-2：“酒店管理系统”将向宾客发送电子邮件消息，以确认收到预订或者预订失败信息。

4.系统特性

4.1 前台管理

（1）描述和优先级

为住店客人提供预订信息，并为顾客办理登记入住手续，将登记信息录入电脑。并可以为客人增加房间，更换房间，还能根据操作员的权限不同，对客人登记信息及房间价格加以修改，提高系统的灵活性，满足不同客人的要求。

（2）刺激/响应序列

预定

刺激：选择客人准备预约登记的部门，如客房…等，点击“新增预订”。响应：系统给出预定登记区。

刺激：在预订登记区填入相关信息、选择具体需预订的设施项目及数量。填写无

误后按“保存”按钮。

响应：系统记录预定信息，并返回预定成功。刺激：反之选择“取消”按钮。响应：系统取消预定。

入住登记

刺激：进入“接待画面”后，先选择当前需接待登记的部门，如：客房、餐饮…．．

再选择设施规格，默认状态下是“标准”。

响应：建立客户消费帐，为每位客人安排一个房间、床位、桌号、牌号、及其他相关登记类型索引记录。

刺激：选择和填写完毕，按“确定”按钮。响应：完成接待操作。

刺激：按“取消”按钮。响应：取消所有操作。

顾客换房

刺激：进入“登记调整”界面，响应：系统调出所有已登记宾客和空余设施。

刺激：首先选择需调整宾客当前所登记的“部门”，在界面“原登记”列表框内移动光标选择需调整的宾客。在“设施列表”中选择想调换的设施。按“调换”按钮。

响应：完成调换。

刺激：按“取消”按钮。响应：取消所有操作。

追加登记

刺激：进入“追加登记”界面，在客人列表框内直接移动光标选择需追加登记的客人。

响应：系统调出该客人已登记的项目。

刺激：在“可供追加项目”列表框内双击鼠标添加新的项目到该宾客资料中，点击“确定”。

响应：系统更新该客人的已登记记录，并返回追加成功。刺激：选中追加项目，通过点击“—”取消追加。响应：系统将新追加项目从该宾客资料中移除。刺激：按“取消”按钮。响应：取消所有操作。

4.2 消费管理

（1）描述级和优先级

根据客人需求，为已登记在店客人提供店内能提供的消费服务，并自动建立消费档案。每位顾客发生消费前必须进行登记，需要建立客户帐，然后是顾客在酒店里进行了各种消费，例如：就餐点菜、会议室的租用、沐浴按摩、酒水消费等等，将这些消费信息录入在客户帐上，对这些消费进行管理满足顾客不同的消费。

（2）刺激/响应序列

点单

刺激：进入“总帐单列表区”界面，通过移动上下键或直接用鼠标在此区域选择需

要消费的客人，或者直接在“定位框”中输入需要消费客人的编号或姓名直接进行定位选择客人，选定客人，点击客户姓名。

响应：弹出选定顾客的消费总账单，包含总帐单下的所有子帐单。子账单也会并行

显示在“子帐单列表区”。

刺激：根据客人的需求通过移动上下键或直接用鼠标在此区域选择具体子帐单人，点击进入。

响应：系统进入选定顾客的消费品选择区，系统并行弹出消费品选择区和消费记区界面。

刺激：先选择消费品所在部门，然后根据该部门所提供的消费品列表双击某消费品 或按［添加］按钮。

响应：系统添加该客人的本次消费品记录，并返回添加成功。

刺激：所有消费品点单完成后，按“保存”按钮。

响应：系统将本次操作所产生的消费额记录在该客人的帐单数据表中，并生成消费

品记录单反馈到消费服务部门，提示服务人员提供消费服务。

外卖

刺激：先选择消费品所在部门，然后根据该部门所提供的消费品列表双击某消费或 按“添加”按钮。

响应：系统添加该客人的本次消费品记录，并返回添加成功。

刺激：所有消费品点单完成后，在顾客支付方式选择区，根据客人的支付方式，如：

现金、支票、信用卡…等支付方式，进行选择，按“保存”按钮。

响应：系统即刻将消费记录在消费记录区等待顾客付费并弹出提示框，提示客人进 行付款。

刺激：点击“付款”按钮，输入顾客已付款数额。响应：弹出应找零金额。

刺激：点击“付款完成”按钮。

响应：系统即刻生成客人消费记录单反馈到服务部门，弹出提示框服务人员提供服务。

查单

刺激：进入“消费查询（未结帐）”界面后，选择需要查询的部门，如选择：进店 日期、消费部门这两个项目，点击“确定”按钮。

响应：系统确定所查询的范围，弹出客人列表框。

刺激：在画面左边的客人列表框中移动光标，进一步确定某位客人的具体“消费明 细”和“收银明细”情况。通过鼠标点击“消费明细”和“收银明细”页框。

响应：系统显示“消费明细”或“收银明细”页面。

刺激：可再进一步用鼠标点击“只显示电话费”明细。

响应：系统显示电话费明细信息。

4.3 收银管理

（1）描述和优先级

每一个客人从入住房间起，系统就需要自动产生该客人的帐号，住店的客人享受酒 店的短期贷款，可以在酒店绝大部分签单，这将刺激客人的消费心理，增加酒店收入，酒店管理者还应可根据客人的情况锁住其帐号，以限制其消费。

前台收银的埋单应允许客人一帐多单，分期埋单，分类别埋单，退房时能自动检测：客人的帐务余额为零；客人帐号的帐项为空；否则不能退房。

系统还应具有合并、分拆帐户的功能，既不但可以把几个帐号的消费转入另一帐号，也可把某一帐号特定时期特定几类消费转入另一帐号，便于满足客人的多种结帐要求。

细分为如下四个需求：退房结帐、取消结帐、合并帐户、订金管理。（2）刺激/响应序列

退房结账

刺激：客人提出退房结账申请。响应：系统给出退房结账界面。

刺激：在“总账单列表区”选择登记客人、在“子账单列表区”选择该客人账目下项目。

响应：系统在“消费明细表”区域显示“待结账客人列表框”或“子客列表框”中光标焦点所指客人的记录，在“结账操作面板”中显示结算金额、已收金额，计算出实际收款。

刺激：选择付款方式、付款。

响应：系统更新数据库，提示结账成功。刺激：按“取消”按钮。响应：取消所有操作。

取消结账

刺激：客人登记后随即提出“退单”。

响应：系统给出退房结账界面。

刺激：在“退房处理”处打勾，点击结账按钮。

响应：完成取消结账操作，其所有消费不作营业额统计。刺激：按“取消”按钮。响应：取消所有操作。

合并账户

刺激：选择需要合并帐单的客人所在的部门。响应：系统调出所有已登记宾客的账户信息。刺激：在 “已登记在店客人”列表框内移动光标或直接用鼠标指定客人，也可在“已登记在店客人”文本框内输入宾客姓名或房间编号迅速查找定位相关宾客。“已登记在店客人”列表框内按回车键或双击鼠标。

响应：将当前光标所指的客人记录移动到“合并区”列表框。刺激：重复操作，选择另一位需合并的客人。

响应：将当前光标所指的另一位客人记录移动到“合并区”列表框。

刺激：在“合并区”移动光标，可确定合并后以哪个帐单号作为合并后的帐单 号。点击“合并”按钮。

响应：系统将合并的账单存储到合并后账单号下，另一个账号账单清空，并提示合并成功。

刺激：按“取消”按钮。响应：取消所有操作。定金管理

刺激：在“客人列表框”，通过直接用鼠标在此区域选择欲缴款客人。也可 以在“定位框１”中输入客人的编号或姓名直接进行定位选择欲缴款客人。也可在 “子帐单列表区”直接接用鼠标在此区域选择的欲缴款客人。响应：根据选择的客人，其账户作为缴款账号。

刺激：在“单据编号”文本框中输入收款单据号（“单据编号”文本框为可选项，可通过“需要单据号”是否打勾确定）。

响应：根据单据号调出客人信息，作为缴款账号。刺激：选择“付款方式”，系统默认付款方式为“现金”。响应：等待输入现金金额。

刺激：在“续缴金额’框中输入具体金额。点击“确定”

响应：系统将定金信息存储到该客人的账单号下，并提示缴纳定金成功。刺激：按“取消”按钮。响应：取消所有操作。

4.4 客房服务

（1）描述和优先级

酒店提出需要一个专门的子系统用于客房部检查客房等项目设施状态，根据多家酒店调研得出，通常将客房分为五种状态：清洁、有客、清理中、待修理和有预约，在电脑系统中应以五种图标代表。为增加灵活性，可以对其进行修改或调整。客房部根据电脑中的资料对脏房进行清洁，并能将清洁后的房态更改为清洁房。也可将部分房态改为待修理，使前台不能出售此类房间。可显示各部门的设施利用率，对已离店宾客的详细情况进行查询或打印。

（2）刺激/响应序列

房态管理

刺激：光标在“接待状态表”主画面上，直接用鼠标点击图标来选择设施，如果该设

施状态为：“有客”。

响应：系统在界面右下部会显示使用该设施客人概况。

刺激：在房态标示为“有客”图标上双击鼠标左键。

响应：系统弹出该客人的基本情况表。

刺激：点击右键。

响应：系统弹出一菜单，供选择改变当前指定设施的状态。

刺激：如果改变了当前客房的房房态。

响应：被改变客房的房态图标下面的文字变为红色文字。

刺激：进行的更改完成，按“保存”按钮完成保存操作。

响应：系统自动进行保存。

员工留言

刺激：系统界面设计有员工留言窗口，员工登录留言。

响应：系统提示员工输入登录用户名。

刺激：员工输入用户名点击登录。

响应：系统界面跳转到员工留言窗口输入框。

刺激：员工进行留言输入，点击完成发表。

响应：系统将员工的留言进行记录在员工留言数据表中。

刺激：操作员登录留言窗口进行查看时，如有“未接受”留言一提示，点击查看。

响应：系统将“未接受”留言从数据表抽取出来显示在界面上。

刺激：操作员查看完留言，进行回馈，点击“完成”按钮。

响应：系统将状态为“未接受”留言改为“已接受”留言。将操作员的回复信息显示在员工留言窗口。

设施利用统计

刺激：系统有一个查看酒店各部门的项目设施利用率，出租率情况的界面。酒店员工点击查看。

响应：系统弹出输入员工ID号的输入框。

刺激：员工输入自己的ID号，点击“确定”按钮。响应：系统判断此员工是否有查看的权限。

刺激：如果有，系统弹出选择框，选择需查看的酒店部门，点击“确定”按钮。响应：系统弹出员工确认查询的酒店部门项目设施利用率以及出租情况。

刺激：如果有部门项目设施利用率发生变化，员工要求更改记录，点击“修改”按钮。响应：系统再次要求输入员工身份认证密码，弹出密码输入框。刺激：员工输入密码，点击“确认”按钮。响应：系统进行确认是否有修改权限。

刺激：如果有修改权限，进入设施记录修改界面进行修改，修改完成，点击“保存”按钮。

响应：系统将新的记录保存在酒店各部门的项目设施利用率，出租率报表中，进行更新。

客史资料查询

刺激：系统有一个“登记人信息”界面，移动鼠标选择要查询客人的姓名，点击“确定”。

响应：系统弹出输入酒店工作人员ID号的输入框。刺激：工作人员输入自己的ID号，点击“确定”按钮。响应：系统判断此员工是否有查看的权限。

刺激： 如果有，系统弹出进入指示，提示工作人员选择进一步要查询某位客人的信息

类别。

响应：系统根据员工的选择弹出需查询某位客人具体的登记情况。

刺激：在“其他人信息”区中移动光标，选择进一步确定某位客人的查询。

响应：系统根据员工的选择弹出需进一步查询某位客人的具体情况。

刺激：有一个“登记人信息”界面，点击“查找按钮”。

响应：系统弹出的“查找窗口”。

刺激：输入“姓名”、“住址”和“证件号”，点击查询。

响应：弹出查询客人信息。

5.其他非功能需求

5.1 性能需求

PE-1：当查询空余项目时，系统的响应时间不能超过2秒。

PE-2：用户向系统提交信息后，系统将在1秒钟内向用户显示确认信息。

5.2 安全性需求

SE-1：用户安全性需求：

（1）限制不必要的用户。经常检查系统的用户，删除已经不再使用的用户。

（2）创建两个管理员账号。创建一个一般权限用户用来处理一些日常事物，另一个有管理员权限的用户只在需要的时候使用。

（3）开启用户策略，分别设置复位用户锁定计数器时间为20分钟，用户锁定时间为20分钟，用户锁定阈值为3次。

SE-2：密码安性需求：

（1）使用安全密码，注意密码的复杂性，还要经常改密码。（2）设置屏幕保护密码。

（3）开启密码策略。设置密码长度最小值为6位，设置强制密码历史为5次，时间为3天。

SE-3：系统安全性需求：

（1）安装防毒软件，经常进行系统扫描并升级病毒库。（2）关闭默认共享。

SE-4：服务安全性需求：

（1）关闭不必要的端口。用端口扫描器扫描系统已开放的端口，确定系统开放的哪些服务可能引起黑客入侵。

（2）设置好安全记录的访问权限。安全记录在默认情况下是没有保护的，把它设置成只有管理员和系统账户才有权访问。

（3）要把一些重要的用户数据（文件、数据表、项目文件等）定时备份在另一个安全的服务器中。

5.3 软件质量需求

Available（可用性）-1：“酒店管理系统”将具备每天24小时可用。

Robustness（健壮性）-1：如果在缴纳定金或退房结账时客户机和服务器中断，那么当时的操作全部视为无效，系统不记录到数据库。

6.附件

附录 分析模型

图1是酒店管理系统用例图。用例视图是表示整个系统需求。这个用例视图反映了：参与者为系统管理员（总经理）和各部门经理，用例为各部门子系统，除了系统管理员（总经理）能与所有的用例进行通信外，每位部门经理只能与一个用例进行通信。

图2为酒店管理系统的局部DFD图。