《软件需求分析》实验指导书

《软件需求分析》 验 指 导 2013 年 9 月 实 书 中文 软件需求分析 课程

Software Requirement

名称 英文

总学时

Analysis 32

课 程 编 号 适 用 专 业 5011011093 软件工程 理论教学学时 28

课 内

4

学 分 2 实践教学学时

课

8

外

执笔者

刘冰 编 写 日 期 2012 年 3 月

《需求工程—软件建模与分析》（骆斌主编、丁二

讲授 玉编著，高等教育出版社，2009 年 4 月第一版，ISBN

978-7-04-026295-7）

教材

《软件需求》（第 2 版）（（美）Karl E.Wiegers 著，

参考 刘伟琴、刘洪涛译，清华大学出版社、2004 年 11 月

第 1 版，ISBN 978-7-302-09834-8）

1

目 录 一、实验目的…………………………………………………………….3

二、实验的软硬件环境………………………………………………….3

三、实验要求与任务…………………………………………………….3

四、实验步骤…………………………………………………………….3

五、《软件需求规格说明书》内容、格式要求………………………..4

六、思考题………………………………………………………………6

【附录一】软件需求规格说明模板…………………………..………..7

【附录二】 评分标准…………………………..………………………13

【附录三】前景与范围文档写作范例………………………………..14

【附录四】需求文档完整范例…………………………………………20

【附录五】软件需求规格说明书（样例一）…………………………..40

【附录六】软件需求规格说明书（样例二）……………………………52

2

实验名称：“××管理信息系统”软件需求规格说明书的编写 一、实验目的

需求开发的最终成果是：客户和开发小组对将要开发的产品达成一致的协议。这一协议 综合了业务需求、用户需求和软件功能需求。从前面实验中所得出的一些分析文档中，我们 可以知道：项目视图和范围文档包含了业务需求，而使用实例文档包含了用户需求。我们还 必须编写从使用实例派生出的功能需求文档，还要编写产品的非功能需求文档，包括质量属 性和外部接口需求。至此，我们综合前面的相关分析结果，来进行需求说明书的编写，进一 步理解由业务需求，用户需求，功能需求三个部分综合而形成软件需求说明书的过程。

二、实验的软硬件环境

硬件：微型计算机，打印机；

软件：Windows XP/7 ，Office 2003/2007，Visual Studio 、Delphi，SQL Server 等 要求实验环境为网络环境。

三、实验要求与任务

1、要求：

完成软件需求规格说明书的编写：

（1）用好的结构化和自然语言编写文档型文档 （2）建立图形化模型。

（3） 编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。 2、具体任务：

开发“××管理信息系统”（如人事管理信息系统、财务信息管理系统、酒店信息管理系统、 设备信息管理系统、仓库管理信息系统、进存销管理信息系统、学生信息管理系统、图书馆 信息管理系统，图书销售信息管理新系统等等）。

通过调查获取用户需求，按照需求的内容进行分析，按照内容、格式要求撰写完整的软 件需求规格说明书。

四、实验步骤

1、 参考相关模板，初步理解软件需求规格说明书的结构 2、 结合项目实际，完成软件需求规格说明书

3、 进一步检查、完善相应的需求部分，尽量避免需求遗漏，和定义的不清晰。同时，

3

应确保采用规范图例。

4、 重复进行前面几个步骤，经过小组成员多次讨论，并得到客户的认可，最终达到客 户和开发小组对需求的认识一致。

五、《软件需求规格说明》内容、格式要求

1、形成软件需求规格说明，要包括以下内容： 文档名称 文档版本号 1． 文档编写人 文档编写记录 2． 审核人 3． 文档每次修订时间，每次修订人 文档编写目的 说明编写这份软件需求说明书的目的，指出预期的读者 a． 待开发的软件系统的名称； 背景描述 b． 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算 机网络； c． 该软件系统同其他系统或其他机构的基本的相互来往关系。 定义，缩写， 术语 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 a． 本项目的经核准的计划任务书或合同、上级机关的批文； b． 属于本项目的其他已发表的文件； 参考资料 c． 本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够 得到这些文件资料的来源。 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说 明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的 任务 概述 目标 关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这 一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本 产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说 明该系统的组成和本产品同其他各部分的联系和接口。 列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育 用户的 水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重 特点 要约束 4

假定和 约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 用列表的方式（例如 IPO 表即输入、处理、输出表的形式），逐项定量 和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、 得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。 对功能 的规定 需求 规定 P：按照既定的数据帧存储格式，存储到离线文件中

O：数据帧文件 I:原始捕获的数据帧 例子： 对性能 的规定 解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精 输人输 出要求 数据管 理能力 要求 故障处 理要求 其他专 门要求 度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括 对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报 告的描述。 说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的 增长对数据及其份量的存储要求作出估算。 列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处 理的要求。 1． 1． 精度 2． 2． 时间特性要求 3． 3． 灵活性 a． 处理器型号及内存容量； 运行 环境 的规 定 设备 b． 外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量； c． 输入及输出设备的型号和数量，联机或脱机； d． 数据通信设备的型号和数量； e． 功能键及其他专用硬件 5

支持软 件 接口 控制 列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支 持软件等。 说明该软件同其他软件之间的接口、数据通信协议等 说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源 2、形成软件需求规格说明，格式和编写体例要依据【附录一】模板。 六、

思考题

1、软件需求规格说明应该包括哪些方面的内容，如果没有模板，你准备么样组织材料， 来编写需求说明？

2、总结自己撰写软件需求规格说明的心得与收获。

6

【附录一】软件需求规格说明模板（参见教材 P345-350）

1．引言

引言是对整个软件需求规格说明的概览，以帮助读者更好地阅读和理解文档。包括文档 的意图（目的）、主要内容（范围）、组织方式（文档组织）、参考文献（参考文献）和阅读 时的注意事项（定义、首字母缩写和缩略语）。

1.1 文档的意图（目的）

目的是说明软件需求规格说明的主要目标，描述软件规格说明所定义的产品或某些产品 部分。限定预期的读者。

1.2 主要内容（范围） 在这一节中：

①根据名称确定将被开发的软件产品。

②解释软件产品的预期功能，并在必要的时候解释没有纳人软件产品预期的功能。 ③描述软件产品的应用，包括相关的好处、目标和目的。

④如果在此软件需求规格说明之外，还存在着一个更高层次的规格说明（例如系统需求 规格说明），那么该部分的描述应该与更高层次文档的相关段落保持一致。

1.3 阅读时的注意事项（定义、首字母缩写和缩略语）

定义了正确理解软件需求规格说明所必需的术语、首字母缩写和缩略语。 这部分内容也可以通过添加附录或者引用其他文档来提供。 1.4 参考文献 在这一节中：

①提供需求规格说明文档引用的全部文档的清单列表。

②利用标题、报告编号（如果适用）旧期和出版机构来标识文档。 ③指出参考文献的来源，在该来源中可以获得文献。 这部分内容也可以通过添加附录或者引用其他文档来提供。 1.5 组织方式（文档组织） 在这一节中：

①描述软件需求规格说明余下部分所包含的内容。 ②解释软件需求规格说明的组织方式。

2．总体描述

从总体上描述影响产品和需求的因素。这部分并不涉及将在文档第 3 部分（详细需求描 述）中描述的具体的需求，而是为其提供背景知识，使其更加易于理解。

2．1 产品前景

该节将所定义的产品和其他相关的产品联系起来，在联系中描述产品的起源和背景，进

7

而说明对产品的总体预期。

如果产品是一个独立的、完全自包含的系统，那么就应该在这里进行声明。

如果像常见的情况那样，产品仅仅是较大系统的一个组件，那么就应该将较大系统的需 求和软件的功能联系起来进行说明，并标识它们之间的接口。如果能够开发一个可以显示较 大系统的主要组件、内部连接和外部接口的框图，将会有很大帮助。

这一节还应该描述较大系统的其他部分对软件产品的操作预期。这些部分包括： ①系统接口：系统接口对软件产品的功能要求。

②用户界面：软件产品和用户之间接口的逻辑特征和优化要求。 ③硬件接口：软件产品和较大系统中硬件组件之间接口的逻辑特征。 ④软件接口：其他软件系统对软件产品的要求。： ⑤交流接口：本地网络协议之类的交流接口要求。～

⑥内存：软件产品在主存储器和辅助存储器上的局限性和可适用特性。 ⑦操作：用户要求的正常和特殊操作。

⑧地点改变需求：对指定地点、任务或者操作模式的需求，调整软件装置而需要改变的 地点或者任务的相关特征。

2.2 产品功能－

概述软件将要执行的主要功能。此处只需要概略的总结，其详细内容将在第 3 部分（详 细需求描述）中描述。例如，一个账目管理程序的软件需求规格说明会在本节中描述顾客账 目维护、顾客描述和发票处理等功能，但不会提及上述功能的大量细节。如果存在为软件产 品分配功能更高一层的规格说明，那么这个部分的功能概述应该直接从更高层次规格说明的 相关部分提取。

为了清晰起见：－

①功能的组织应该能够让第一次看到文档的顾客或者其他人理解功能列表。 ②可以使用文本或者图形化的方法显示不同功能及其联系。 2.3 用户特征

描述产品预期用户的一般特征，包括受教育水平、经验和技术能力等。这些描述信息可 以用来解释第 3 部分（详细需求描述）中特定需求出现的原因，但是本节并不涉及这些特定 的需求。

2.4 约束

对限制开发人员开发方案选择的事项进行一般性描述。这些事项包括： ①规章政策。 ②硬件限制。 ③和其他应用的接口。 ④并发操作。

8

⑤审计功能。 ⑥控制功能

⑦高阶语言要求（即程序开发语言）。

⑧信号握手协议（即信息交流的可靠性要求）。 ⑨应用的临界状态。 ⑩安全性考虑。 2.5 假设和依赖

列举并描述了那些会对文档中所述需求产生影响的因素。这些因素并不是软件的设计限 制，但是这些因素的任何变化都会影响到文档中的需求。例如，有这样一个假设：软件产品 的目标硬件上会有某个特定的操作系统。而在实际情况中，如果这样的情况并不存在，那么 文档中的需求将不得不进行相应的改变。

3.详细需求描述

这通常是软件需求规格说明中最多和最重要的部分。它要对所有的软件需求进行充分的 描述。这部分的内容应该包括设计人员进行设计时所需要的所有细节，足以让设计人员设计 出一个满足需求的系统。它还需要清楚地告诉测试人员需要怎么样的测试才能保证得到一个 满足需求的系统。

在这一部分：

①细节需求的描述要符合优秀需求的特性要求（参见 2. 5 节），文档的组织和内容整合 要符合优秀软件需求规格说明文档的特性要求（参见 15.5 节）。

②细节需求要能够回溯到相关的前期文档，形成前后参照。 ③所有的需求都要被唯一的标识。 ④需求的组织应该尽可能的提高可读性。

该部分内容的最佳组织方式要依赖于软件产品的应用领域和特性。〔IEEE 830-19981 为该部分的文档组织提供了 8 种不同的模板方式，图 15 一 5 所示的模板为其中之一。 图 15 -6 所示的模板是按照系统特性来进行需求组织的，除此之外也可以按照操作模式、 类／对象、刺激／响应、功能分解、用户类别等方式进行组织。关于其他几种组织方式可参 见教材的附录一（P423-428）。

[IEEE 830-1998」将需求分成了 5 种类别，并据此进行内容的组织。这 5 种内容是： ①功能需求。 ②性能需求。 ③约束。 ④质量属性。 ⑤对外接口。

软件需求规格说明模板中第 2 章已经详细解释了 5 种类型需求的区别，本章将仅仅对文

9

档内容的组织进行介绍。

3.1 对外接口需求

描述了设计人员正确开发与软件外部实体的接口所需要的所有信息。 对软件产品对外接口中的输人／输出项，可以参照下列方式进行描述： （1）名称。 （2）目的描述。 （3）输人源／输出目标。

（4）有效范围，精确度和误差范围。 （5）度量单位。 （6）时间要求。

（7）和其他输人／输出项的关系。、 （8）屏幕布局／组织。 （9）窗口布局／组织。 （10）数据格式。 （11）命令格式。 （12）结束消息。 3.1.1 用户界面

描述系统所需的每个用户界面的逻辑特征。本节可能包括下列内容： ①对图形用户界面(GUI)标准的引用或者将要采用的产品系列的样式指南。

②有关字体、图标、按钮标签、图像、颜色选择方案、组件的 tab 顺序、常用控件等的 标准。

③屏幕布局或解决方案的约束。

④每个屏幕中将出现的标准按钮、功能或者导航链接。 ⑤快捷键。． ⑥消息显示约定。

⑦便于软件定位的布局标准。 ⑧满足视力有问题的用户的要求．， 3.1.2 硬件接口

描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型、软硬件之 间交流的数据和控制信息的性质以及所使用的通信协议等。

3.1.3 软件接口

描述该产品与其他外部组件（由名字和版本识别）的连接，包括数据库、操作系统、工 具、程序库和集成的商业组件等。声明在软件组件之间交换数据、消息和控制命令的目的。 描述其他外部组件所需要的服务以及组件间通信的性质。确定将在组件之间共享的数据。

10

3.1.4 通信接口

描述与产品所使用的通信功能相关的需求，包括电子邮件,Web 浏览器、网络通信标准 或协议及电子表格等。定义了相关的消息格式。规定通信安全或力。密问题、数据传输速率 和同步通 信机制等。

3.2 功能需求

描述了软件产品在接收和处理外部输入（或者处理和产生对外输出）中发生的基本行为。 需要描述的内容有： ? 对输人的验证 ? 操作的顺序 ? 对异常的响应，例如

? 数值越界 ? 通信间题 ? 错误处理与恢复 ? 参数的说明 ? 输出和输人的关系

? 输人／输出序列

? 将输人转换为输出的公式和规则 3.2.x 系统特性

系统特性是外部期望的系统服务，它接收一系列的输入，并产生外界预期的输出。 3.2.x.1 特性描述

提出了对该系统特性的简短说明。 3.2.x.2 刺激／响应序列

列出输入刺激序列（用户动作、来自外部设备的信号或其他触发器）和系统的响应 序列。

3.2.x.3 相关功能需求

详细列出与该特性相关的功能需求。这些是必须提交给用户的软件功能，使用户可以 使用所提供的特性执行服务或者使用所指定的使用实例执行任务。描述产品如何响应可预知 的出错条件或者非法输人或动作。

3. 2.x.3.n 功能需求 x.n

对单个需求（功能的某个步骤或者某个方面）的清晰描述，常见形式为“RID：系 统应该…”。

3.3 性能需求

阐述了不同的应用领域对产品性能的需求，并解释它们的原理以帮助开发人员做出合理 的设计选择。确定相互合作的用户数、所支持的操作、响应时间以及与实时系统的时间关系。

11

还可以定义容量需求，例如存储器和磁盘空间的需求或者存储在数据库中表的最大行数。尽 可能详细地确定性能需求。可能需要针对每个功能需求或特性分别陈述其性能需求，而不是 把它们都集中在一起陈述。

性能需求描述的详细内容和形式示例可参见 2.3.3。 3.4 约束

描述可能由法律法规、标准、规范或者硬件限制等因素带来的设计约束。 约束描述的详细内容可参见 2.3.6. 3.5 质量属性

详尽陈述对客户或开发人员至关重要的产品质量属性。这些特性必须是确定、定量的而 且在可能时是可验证的。

关于质量属性的详细内容可参见 2.3.4. 3.6 其他需求

定义在软件需求规格说明的其他部分未出现的需求，例如国际化需求或法律上的需求。 你还可以增加有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和容错， 以及登录和监控操作等方面的需求。

附录

附录是对软件需求规格说明正文信息的补充。虽然它并不总是必需的，但是必要的附录 可以增加文档对需求的描述能力。

常见的附录内容包括：

①I/O 格式示例、成本分析研究、用户调查结果。

②有助于阅读软件需求规格说明的背景信息，常见的有术语表、数据字典和分析模型 图示。

③需要解决但是目前还悬而未决的问题列表。

④为了满足安全、导出、初始加载或者其他需求而对代码和数据媒体进行特殊打包处理 的说明。

索引

对文档重要内容的位置引用，可以利用文档编辑工具自动生成。

需求规格说明文档的写作原则与技巧参见教材 P350“需求规格说 文档写作”。

12

【附录二】 评分标准

1、优（90 以上）：文档非常规范、思路很清晰，能较好反映、概括当前项

目内容以及客户各个方面的需求。

2、良（80 以上 ）：文档比较规范、思路比较清晰，能较好反映、概括当前

项目内容以及客户各个方面的需求。

3、中（70 以上）：文档基本规范、思路清晰，能反映、概括当前项目内容

以及客户各个方面的需求。

4、及格（60 以上）：文档组织基本合理，思路基本清楚，能基本反映、概

括当前项目内容以及客户各个方面的需求。

5、不及格（60 下）：文档组织混乱，思路含混，不能反映、概括当前项目

内容以及客户各个方面的需求。

13

【附录三】前景与范围文档写作范例

——自助餐厅在线订餐系统

业务需求、高层次解决方案和系统特性都应该被定义到项目前景与范围文档 之中，以为后续的开发工作打好基础。

前景与范围文档目录如下：

1 业务需求 1.1 应用背景 1.2 业务机遇 1.3 业务目标 1.4 业务风险 2 项目前景 2.1 前景概述 2.2 主要特性 2.3 假设与依赖 3 项目范围 3.1 第一版范围 3.2 后续版本范围 3.3 限制与排除 4 项目环境 4.1 操作环境 4.2 涉众 4.3 项目属性 词汇表 参考资料 附录 1、业务需求

（要求说明：该项内容主要目的是清晰地解释系统的业务需求。业务需求描述了新系统 将带给投资人、购买者和用户的主要利益，说明了项目的最终目标。）

1.1 应用背景

（要求说明：概述系统开发的应用背景，描述原有的应用状况，说明新系统开发的动 机。必要的情况下，还需要说明应用的历史延续过程。）

目前，Process Impact 公司的大多数员工平均每天要花费 60 分钟去白助餐厅 用午餐，其中大约有 20 分钟要花在公司和自助餐厅之间的往返、选择午餐和以

14

现金或信用卡方式结账上。当员工到自助餐厅之外去用午餐时，他们平均有 90 分钟时间不在岗。有些员工提前给自助食堂打电话预订午餐，请自助餐厅准备好 他们选择的午餐。但是，员工并不总是能够如愿以偿，因为自助餐厅有些食物已 卖完。而与此同时，自助餐厅又在浪费大量的食物，因为有些食物没有卖掉而只 好倒掉。早餐和午餐同样面临着这样的问题，只是到餐厅用餐的员工人数比午餐 要少得多。

1.2 业务机遇

（要求说明：如果开发的是商业产品，这部分描述的是存在的市场机遇以及产品要参与 竞争的市场。如果是企业信息系统，则应描述要解决的业务问题或需要改进的业务流程，以 及系统的应用环境。

这部分内容还应对已有的产品和可能的解决方案进行比较评估，指出新产品的优点。 说明有哪些问题因为没有该产品而在当前无法解决。还要说明该产品怎样符合市场潮流、技 术发展趋势或企业的战略方向。另外，还应有一段简短的说明描述如果需要为客户提供一个 完整的解决方案，还需要哪些其他的技术、过程和资源。）

许多员工都通过自助餐厅的一个在线订餐系统提出订餐请求，要求在指定的 日期和时间内将所订的午餐送到公司的指定地点。通过这样一个系统，使用这一 服务的员工可以节约相当可观的时间，而且订到自己喜欢食物的机会也增大了。 这既提高了他们的工作生活质量，也提高了他们的生产率。自助餐厅提前了解到 客户需要哪些食物，就可以减少浪费，并提高高员工的工作效率。要求送货上门 的订餐员工将来还可以从本地的其他饭店来订餐，这就大大扩大了员工对食物的 选择范围，并通过与其他饭店的大量购餐协议而有可能节约费用。Process Impact 公司也可以只在自助餐厅订午餐，而在其他饭店订早餐、晚餐、特定事件的用餐 和周末会餐。

1.3 业务目标与成功标准

（要求说明：用量化和可衡量的方式概述产品提供了哪些重要的业务利益。如果其他 文档（如业务用例文档）中已包含了这些信息，此处指明参考文档即可，不必重复其内容。 这一部分还应明确涉众如何定义和判断项目的成功。说明哪些因素对项目获得成功的影响最 大，无论这些因素是否处于组织的控制范围内。还要定义可衡量的标准，用于评估各项业务 目标是否已实现。）

15

BO -1：在第一版应用之后的 6 个月内，减少食物的浪费。 度量标准（Scale）：每周被自助餐厅工作人员扔掉的食物的价值。

SC -1：在第一版应用之后的 s 个月内，目前在自助餐厅用午餐的员工中，75 ％的人使用在线订餐系统。

SC -2：在第一版应用之后的 3 个月内，对自助餐厅满意度的季度调查评价 要提高 0.5，而在第一版应用之后的 12 个月内，这种满意度要提高 1.0。

1.4 业务风险

（要求说明：概述与产品开发相关的主要风险。风险类别包括市场竞争、时间安排、 用户认可、实现技术以及可能对业务造成的负面影响。．要评估每一项风险可能造成的损失、 发生的几率以及对它的控制能力。找出所有可能降低风险的必要措施。如果在业务用例分析 或类似文档中已经给出了这些信息，此处只需指明出处而不必重复该信息。）

RI -1：使用该系统的员工太少，减少了对系统开发和变更自助餐厅经营过程

的投资回报。

可能性 0.3，影响为 9。

RI -2：其他本地饭店可能并不认何减价是员工使月这一系统的正当理由，这

会减低员工对该系统的满意度，并可能会减少他们对这一系统的使 月。

可能性为 0.4，影响为 3。

2 项目前景

（要求说明：这一部分建立系统的战略前景，该系统将实现业务目标。前景为产品生 命周期中所有的决策提供了背景。详细的功能需求或项目计划信息不应包括在这一部分内。)

2.1 前景概述

（要求说明：用一个简洁的声明概括系统的长期目标和意图。声明应当反映能够满足不 同涉众需求的平衡的观点。前景声明可以理想化，但应当以当前或预期的市场现状、企业结 构、团体战略和资源限制为依据。）

对那些希望通过公司自助餐厅或其他本地饭店在线订餐的员工来说，“自助 餐厅订餐系统”是一个基于 Internet 的应月程序，它可以接受个人订餐或团体订 餐，结算用餐费用，并触发将预订餐送到 Process Impact 公司内指定位置的事件。

16

与当前的电话订餐和人工订餐不同，使用“自助餐厅订餐系统”的雇员并不需要到 食堂内去用餐，这既可以节约他灼的时间，又可以扩大他们对食物的选择范周。

2.2 主要特性

（要求说明：为新产品的每一项主要特性或用户功能进行固定的、唯一的命名或编号， 突出其超越原有产品或竞争产品的特性。给每项特性一个唯一的标号，这样可以追踪其去向 —用户需求、功能需求和其他系统元素。）

FE- 1：根据自助餐厅提供的菜单来订餐。 FE-2：根据真他本地饭店的送货菜单来订餐。 FE-3：请求送餐。

FE-4：创建、浏览、修改、删除用餐预订。

FE-5：通过公司的内联网访问系统，或者授权员工通过外部 Internet 访问系 统。

2.3 假设与依赖

（要求说明：记录构思项目和编写前景与范围文档过程中涉众所提出的每一项假设。 由于一方所做的假设往往不为其他各方所知，因此通过将所有的假设记录下来并进行检查， 各方就能对项目潜在的基本假设达成一致。这样便能够避免可能的混乱以及这种混乱会在将 来造成的影响。

这一部分还记录项目对不在自身控制范围内的外部因素的主要依赖关系。这类外部因素 包括悬而未决的行业标准或政府法规、其他项目、第三方厂商及开发伙伴等。）

AS-1：自助餐厅内有可以访问公司内网的计算机和打印机。

AS-2：自助餐厅有送货人员和送货车辆，最多比请求的送货时间晚 15 分钟。 DE-1：如果某饭店有自己的联机订餐系统，那么“自助餐厅订餐系统”必须能

与这一系统进行双向通信。

3 项目范围

（要求说明：项目的范围定义了解决方案的概念和范围，同时也要表明系统不能提供 哪些功能，它可以帮助涉众建立现实的期望。）

3.1 第一版范围

（要求说明：概述计划在产品的第一个版本中实现的主要特性。描述产品的质量特性，

17

产品依靠这些特性为不同类别的用户提供预期利益。

如果目标是集中开发力量和维持合理的项目进度，就不要企图在 1.0 版本中包含所有可 能的需求。那样会导致项目范围在不知不觉中增大，使得进度延误。应该把注意力集中在那 些能够在最短时间内，以最适宜的成本，为最大多数用户提供最大价值的特性上。）

3.2 后续版本范围

（要求说明：如果要采取阶段性的开发方式，需要决定推迟实现哪些特性，并为后续 的版本做出时间安排。后续版本能够实现更多的需求和特性，并可完善最初的功能。随着产 品的不断成熟，系统的性能、可靠性和其他质量特征也将得到改进。）

表 1 版本范围

3.3 限制与排除

(要求说明：管理范围蔓延的方法之一是，定义项目包含的需求与不包含的需求之间的 界线。此处应列出涉众可能希望得到、但不在产品或其某个特定版本计划之内的功能和特 性。)

LI-1：自助餐厅的有些食物不适宜送货，因此“自助餐厅订餐索统”的顾客使 用的送货菜单是食堂整个菜单的一个子集。

LI -2“自助餐厅订餐系统”只能用子 Process Impact 公司总部内的自助餐厅。

4 项目环境

4.1 操作环境

（要求说明：描述系统将用于什么样的环境，定义关键的可用性、可靠性、性能等质 量属性要求。这些信息对系统的结构定义有着重要的影响。

与操作环境相关的问题包括： ①用户是地理分散的还是集中的？

18

②不同的用户会在什么时间访问系统？ ③数据在何处生成，用于何处？

④访问数据时的最大响应时间是否已知？ ⑤用户能否容忍服务中断？

⑥是否需要提供访问安全控制和数据保护？）

4.2 涉众 （要求说明：描述项目涉众的相关信息，重点介绍不同类型的客户、目标市场和目标 市场中的用户类别，说明他们和系统密切相关的一些特征。）

4.3 项目属性

（要求说明：要想更有效地进行决策，涉众就必须就项目的相关属性及其优先级达成 一致。这些属性包歌括：特性（功能、范围）、质量、成本、进度和人员。

对任何一个特定的项目而言，上述每个属性都有三种影响因素： ①驱动因素(Driver)：重要的成功目标。

②约束因素（Constraint）：项目必须在一定的限制下展开工作。

③可调整因素(Degree of Freedom)：可以根据其他方面进行平衡和调整的因素。 项目经理的目标是：在约束因素施加的限制内，合理安排可调整因素，获得最大的驱 动因素。

在项目属性之间不可调和时，属性间的优先级顺序指导项目管理者采取正确的行动。 例如，对于急需面市的系统，其进度是第一优先级，这样在项目无法按照预定计划前进时， 就可能会推迟特定功能的实现，或者增加人员和投资。再例如，对于人员（或费用）受限的 系统，人员（费用）是第一优先级，在项目出现偏离时就可能延迟系统的完成期限，或者推 迟部分功能的实现。除特例情况之外，质量都是一个不应该被牺牲的项目属性。）

表 2 项目属性的示例

19

【附录四】 需求文档完整范例

本附录通过“自助食堂订餐系统(Cafeteria Ordering System COS)”这样一个假想的小型 项目，阐述了本书所描述的某些需求文档和图。这里包括如下这些内容：

●●●● 前景和范围文档。

用例列表和若干用例描述。 部分软件需求规格说明。 某些分析模型。 ● 部分数据字典。 ● 若干业务规则。 因为这仅仅是一个范例，所以我们并不打算完善这些需求元素。我们的目标只是提供一 种思想，各种类型的需求信息之间彼此是如何关联的，并演示我们可能如何编写文档每一部 分的内容。在一个小型项目中，将不同的需求信息综合到单一的文档中，常常是有意义的， 因此我们可能没有单独的前景和范围文档、用例文档和软件需求规格说明。这些文档中的信 息能够以多种其他合理的方式来组织。基本的目标是确保需求文档清晰明了、完整和易使用。

这些文档总的来说都遵照前面章节所描述的模板，但是，因为这只是一个小型项目， 所以对这些模板稍微作了一些简化。有时，会将几个部分合并起来，这是为了避免信息重复。 每一个项目都应该考虑如何适应组织的标准模板，以尽量适合于项目的规模和本质。

1 前景和范围文档 1.1 业务需求

1．背景、业务机会和客户需要

目前，Process Impact 公司的大多数员工平均每天要花费 60 分钟去自助食堂选择、购买 并用午餐，其中大约有 20 分钟要花在公司和自助食堂之间的往返路程、选择自己喜欢的午 餐、以及以现金方式或以信用卡方式结算餐费上。当员工出去用午餐时，他们平均有 90 分 钟时间不在岗。有些员工提前给自助食堂打电话预订午餐，请自助食堂准备好他们所选择的 午餐。但是，员工并不是总能如愿以偿，因为自助食堂有些食物已卖完，而与此同时，自助 食堂又不可避免地会浪费大量的食物，因为有些食物没有卖出去而只好倒掉。早餐和晚餐同 样面临着这样的问题，只是到自助食堂用餐的员工人数比午餐要少得多。

许多员工都通过允许自助食堂用户在线订餐的一个系统而提出订餐请求，要求在指定的 日期和时间内将所订的午餐送到公司的指定地点。通过这样一个系统，使用这一服务的员工 可以节约相当可观的时间，而且订到自己所喜欢的食物的机会也增大了。这既提高了他们的 工作生活质量，也提高了他们的生产率。自助食堂提前了解到客户需要哪些食物，就可以减 少浪费，并提高自助食堂员工的工作效率。要求送货上门的订餐员工将来还可以从本地的饭 店来订餐，这就大大扩大了员工对食物的选择范围，并通过与饭店的大量购餐协议而有可能 节约费用。Process Impact 公司也可以只在自助食堂订午餐，而在饭店订早餐、晚餐、特定 事件的用餐以及周末会餐。

2．业务目标（Business Objective. BO）和成功标准（Success Criteria SC) BO-l：初始版本发布之后的 6 个月内，自助食堂的食物浪费减少 50%。 度量单位（scale）：自助食堂的工作人员每星期所倒掉的食物的价值。

20

计量(meter)检查“自助食堂存货系统（Cafeteria Inventory System）”的日志。 过去情况（past）[2002，初步调研］：30% 一般标准（plan）：小于 15%

最低标准（must）：小于 20%

BO-2：初始版本发布之后的 12 个月内，自助食堂的运作费用减少 50％。

BO-3：初始版本发布之后的 3 个月内，每个雇员每天的平均有效工作时间增加 20 分钟。 SC-1：目前通过自助食堂解决午餐问题的那些员工，在初始版本发布之后的 6 个月内， 他们中有 75%的人使用“自助食堂订餐系统”。

SC-2：初始版本发布之后的 3 个月内，对自助食堂满意度的季度调查评价要提高 0.5, 而在初始版本发布之后的 12 个月内，这种满意度要提高 1.0.

3．业务风险（RIsk)

RI-1：“自助食堂雇员联合会(Cafeteria Employees Union)”可能要求与雇员重新签订合 同，以反映新的雇员角色和自助食堂营业时间。（可能性为 0.6.影响为 3） RI-2：使用该系统的雇员太少，减少了对系统开发和变更自助食堂经营过程的投资回报。 （可能性为 0.3，影响为 9)

RI-3：本地饭店可能并不认同减价是雇员使用这一系统的正当理由，这会减低雇员对该 系统的满意度，并可能会减少他们对这一系统的使用。（可能性为 0.4，影响为 3）

1.2 解决方案的前景

1．前景陈述

对那些希望通过公司自助食堂或本地饭店在线订餐的员工来说，“自助食堂订餐系统” 是一个基于 Internet 的应用程序，它可以接受个人订餐或团体订餐，结算用餐费用，并触发 将预订餐送到 Process Impact 公司内的指定位置。与当前的电话订餐和人工订餐不同，使用 “自助食堂订餐系统”的雇员并不需要到食堂内去用餐，这既可以节约他们的时间，又可以 增加他们对食物的选择范围。

2．主要特性（FEature)

FE-1：根据自助食堂提供的选择菜单或送货菜单来订餐。 FE-2：根据本地饭店的送货菜单来订餐。

FE-3：创建、浏览、修改和删除用餐预订服务。 FE-4：注册用餐的付费方式。 FE-5：请求送餐。

FE-6：创建、浏览、修改和删除自助食堂菜单。 FE-7：预订自助食堂菜单上所没有的定做菜。 FE-8：生成自助食堂定做菜的食谱和配料列表。 FE-9：通过公司的内联网可以访问系统，或者授权的员工通过外部 Internet 访问系统。 3．假设(ASsumption)和依赖(DEpendency)

AS-1：自助食堂内有可以访问公司内联网的计算机和打印机，这样自助食堂的雇员就 可以处理期望的订单量，不会遗漏任何送货时间。

AS-2：最多比请求的送货时间晚 15 分钟，自助食堂有送货人员和送货车辆，这样就能 满足所有订单的送货要求。

DE-1：如果某饭店有自己的联机订餐系统，那么“自助食堂订餐系统”必须能与这一 系统进行双向通信。

1.3 范围和局限性

21

1．初始版本和后续版本的范围

2．局限性（Limitation）和排斥性

LI-1：自助食堂的有些食物不适宜于送货，因此“自助食堂订餐系统”的顾客所用的菜单 是食堂整个菜单的一个子集。

“ 自助食堂订餐系统”只能用于俄勒冈州 Clackamas 的 Process Impact 公司总部内 的LI-2：

自助食堂。

1.4 业务上下文

1．涉众概览

22

23

24

25

26

27

28

29

30

31

3 软件需求规格说明 3.1 介绍

1．目标

软件需求规格说明描述了“自助食堂订餐系统(Cafeteria Ordering System, COS)\ 版本 的软件功能性需求和非功能性需求。这一文档计划由实现和验证系统正确功能的项目团队成 员来使用。除非在其他地方另有说明，这里指定的所有需求都具有高优先级，而且都要在版 本 1.0 中加以实现。

2．项目范围和产品特性

“自助食堂订餐系统”允许 Process Impact 公司雇员向公司的自助食堂在线订餐，并送 餐到公司内的指定地点。详细的项目描述请参见 Cafeteria Ordering 枷 tem Visionand Scope Document(自助食堂订餐系统前景和范围文档）【1】。文档中这一部分的标题为“初始版本和 后续版本的范围”，列出了按照进度计划在这一版本中实现的全部或部分特性。

3．参考文献

（1） Karl Wiegers 所著的 Cafeteria Ordering System Vision and Scope Document，其 网址是 www.processimpact.com/projects/COS/COS vision and scope.doc

（2）Karl Widgers 所著的 Process Impact Intranet Development Standard 版本 1.3，其

网址是 www.processimpact.com/corporate/standards/PI intranet dev-std.doc

（ 3 ） Christine Zambito 所 著 的 Process Impact Business Rules Catalog, 其 网 址 是

www.processimpact.com/corporate/policies/PI_business rules.doc

（ 4 ） Christine Zambito 所 著 的 Process Impact Internet Application User Interface Standard 版本 2.0,其网址是 www.processimpact.com/corporate/standards/PI internet ui std.doc

3.2 总体描述

1．产品远景规划

“自助食堂订餐系统”是一个新系统，它取代了当前在 Process Impact 公司自助食堂内 以手工方式和电话方式预定和选择午餐的过程。图 D.1 是一幅关联图，它演示了 1.0 版本的 外部实体和系统接口。期望系统演化若干个版本，最终与本地若干饭店的 Internet 订餐服务 相连接，并提供信用卡和借记卡授权服务。

32

33

3．运行环境(Operating Environment，OE)

“自助食堂订餐系统”的操作将通过如下的 Web 浏览器来完成：Microsoft Internet OE-1：

Explorer 版本 5.0 和 6.0，Netscape Communicator 版本 4.7 和 Netscape 版本 6 和版本 7。

“自助食堂订餐系统”将运行在一个服务器中，该服务器运行当前由公司批准的 OE-2：

Red Hat Linux 版本和 Apache HTTP Server。

“自助食堂订餐系统”将允许用户通过公司内联网来访问，如果用户被授权在公 司OE-3：

的外部穿过防火墙来访问，那么用户也可以在家里通过 Internet 来访问该系统。

4．设计和实现的约束条件（constraint）

CO-1：系统的设计、编码和维护文档将遵照 Pruccss Impact Intranet Development Standard （Process Impact 公司内联网开发标准）版本 1.3 【2】。

CO-2：系统将采用公司标准的当前 Oracle 数据库引擎。 CO-3：所有 HTML 代码将遵照 HTML 4.0 标准。 CO-4：所有脚本都用 Perl 语言来编写。 5．用户文档（User Documentation, UD)

UD 小系统将提供一个分层的和跨链接的 HTML 联机帮助系统，它描述并演示了所有系 统功能。

UD-2 如果是一个新用户第一次使用该系统，系统可以根据用户的要求，提供一个联机 教程，这样用户可以使用静态教程菜单来具体实践一下如何订餐。系统不会将采用这一模板 的订餐订单存储到数据库中，也不会将这种订单提交给自助食堂。

6．假设（ASsumption）和依赖(DEpendency)

AS-1：只要是要求员工在岗的每一个公司工作日，自助食堂在早餐、午餐和晚餐时都 会营业。

DE-1:“自助食堂订餐系统”的运行依赖于“薪资核算系统”所做出的变更，它接受用 “自助食堂订餐系统”订餐的付费请求。 DE-2:“自助食堂订餐系统”的运行依赖于“自助食堂库存系统”所做出的变更，当接 受“自助食堂订餐系统”订单后，它更新食物条目的有效性。

34

3.3 系统特性

1．订餐

（1）描述和优先级

自助食堂的顾客其身份得到验证之后，他们就可以订餐，并可以要求送到公司内指 定

的地点，也可以去食堂内就餐。只要所订餐还没有准备好，顾客就可以取消或改变订单。 优先级为高。

(2）刺激／响应序列

刺激：顾客请求订餐，可以是一份或多份。

响应：系统向顾客询问订餐细节、付费方式和送餐说明。 刺激：顾客请求改变订单。

响应：如果订单状态是“己接受”，则系统允许用户编辑以前的订单。 刺激：顾客请求取消订单。

响应：如果订单状态是“已接受”，则系统取消订单。（ 3）功能性需求

35

36

订单日期=*顾客提交订单的日期；格式是 MM/DD/YYYY* 所订的食物条目

＝菜单食物条目 ＋所订的数量

顾客

＝顾客名字 ＋雇员 ID 号 ＋顾客电话号码 ＋顾客地点 ＋顾客电子邮件

顾客电子邮件＝*提交订单的雇员的电子邮件地址；由 50 个字母数字组成* 顾客地点＝*提交订单的雇员所在的大楼和房间号；由 50 个字母数字组成* 顾客名字＝*提交订单的雇员的名字；由 30 个字母数字组成*

顾客电话号码＝*提交订单的雇员的电话号码；格式为 AAA-EEE-NNNN xXXXX, 分别表示区号、电话局号、号码和扩展号码*

所付餐费=*以美元和美分表示的一个订单的总价格，具体计算按照 BR-12* 付费方式：［从工资中扣除|现金］*从版本 2 开始添加其他付费方式*

从工资中扣除餐费的事务号=*“薪资核算系统”为它所接受的每个从工资中扣除

餐费的事务分配一个数字，该数字是由 8 位数字组成的顺序整数* 数量*

特色菜

＝特色菜描述 ＋特色菜价格

*菜单经理可以为每个菜单定义一个或多个特色菜，这些特色菜

是以优惠价将某些食物条目组合在一起*

特色菜描述＝*每日特色菜的文本描述；最多为 100 个字符* 特色菜价格＝*以美元和美分表示的一份特色菜的价钱*

图 2 是“自助食堂订餐系统”1.0 版本的部分数据模型，展示了数据字典中描述的实 体

以及它们之间的关系。

37

订餐数量＝*顾客订的每一个食物条目的份数；默认值为 1；最大值为目前的存货

38

39

【附录五】软件需求规格说明书（样例一）

酒店管理系统 软件需求规格说明书 V1.00 【附录四】《软件需求规格说明书》（样例）

部 门: 软件工程项目实践 项 目: 酒店管理系统 编 写: 审 核:

编号：HMS102 密级：限制

计算机系酒店管理系统开发小组 2010 年 11 月 6 日 40

文档名称

文档编号

部门名称

项目名称

酒店管理系统软件需求规格说明书 CSMS102 软件工程项目实践 酒店管理系统

版 本 号 编 写 人 审 核 人

V1.00

密 级 总 页 数 编写日期 审核日期

限制 16 2010-11-6

摘 要 本文档是酒店管理系统的需求规格说明书，它定义了用户对酒店

管理系统在功能上和性能上的需求。

版本修订记录 编号 1

日期 2010.11.6

版本 1.00

修订人

初始版本

修 订 内 容

2010-11-06 第 41 页 共 68 页

软件需求规格说明书 市大学软件学院

天津

1. 引言

1.1 编写目的

本文档是酒店管理系统的需求规格说明书，编写该文档的目的在于明确酒店管理系统的 用户需求，使得软件开发人员与用户对待开发软件的需求有统一的、无二义性的认识，安排 项目规划与禁毒、组织软件开发与测试，该文档所描述的内容，可作为软件确认测试的依据。

本文档仅供项目经理、设计人员、开发人员参考。 1.2 项目背景

项目名称：酒店管理系统；

本项目是本科生《软件工程项目管理》课程的实验项目，通过该项目应该达到让项目组 成员了解并熟悉 RUP 开发过程，对软件工程这门课程有更加全面和深入的认识。

1.3 术语定义

参见《词汇表》

1.4 参考资料

[1] 酒店管理系统项目开发计划_v1.00

2. 用户特点

使用该系统的用户必须是经过专门培训的专业人士，熟悉计算机操作，具有一定的专业 知识，能够恰当及时处理紧急情况。

3. 假定和约束

4. 软件需求详细描述

4.1 客房部管理系统

客房部管理系统包括客房管理、前台预订、前台接待和前台收银四个功能模块； ▲客房管理

天津市大学软件学院

●房态管理 可选择按楼层、房态或房类显示当前的所有房间的状态，房间状态包括吉房、 住房、脏房、坏房、配房和锁房．

●客人查询 可按房号、客人姓名、团体编号、身份证号、客人类型、客人国籍、客房类 型、抵店日期、离店日期等条件组合查询在住客人的简表及详细资料．

●统计及报表 报表包括： 房态比率统计、房态分类列表、在住客人名单、预期离店客人、 实际离店客人

●操作员重登记

▲前台预订

●房态查询 可查询房态比率统计和预测将来某段日期内的订房情况

●订房管理 包括散客订房和团队订房两大功能，可通过预订编号、姓名、团队名称、预 订日期、预订客类或客人来源等条件查询已订房的客人情况，并可以取消预订或修改预订．

●报表统计 统计的报表包括： 当天订房报表、当天删除报表、预期到步报表、预期未到 报表、客人配房报表

●操作员重登记

▲前台接待

●散客管理 自动按客人要求的房类给出可选房号，完成客人登记手续； 可由预订单、历 史客人资料自动生成登记单，并可实现客人的续住；登记时若客人有历史记录的则自动显示 历史资料和以往的房租折头方便操作员参考． 提供预订单的输入、复制、修改，同行客人、 同住客人的登记，散客转团队（如为团队成员则按钮为团队转散客），设置酒店自用，制作 宾客卡，打印登记单功能； 入住客人是否开通ＩＤＤ功能； 提供设置ＶＩＰ，特殊需求、 口信、意见、同行客人查询、转账、客人其他信息查询等功能，协助酒店实现一流服务； 提 供同住客人的换房处理，客人调租处理，实现真正的酒店电脑管理．

●团体管理 完成对团体入住的登记或团体增加团员等操作

●房态管理 可选择按楼层、房态或房类显示当前的所有房间的状态，房间状态包括吉房、 住房、脏房、坏房、配房和锁房．

43

●客人查询 可按房号、客人姓名、团体编号、身份证号、客人类型、客人国籍、客房类 型、抵店日期、离店日期等条件组合查询在住客人的简表及详细资料．

●统计及报表 统计的报表包括： 在住客人名单、计划离店名单、 实际离店名单、 当 天入住客人、 常住客人报表、 特殊客人名单、特殊服务清单、职员用房报表、客人来源分 析、客人类型分析、 房租类型分析、 房租差异报表、转房客人报表、可用客房报表。

●操作员重登记

▲前台收银

客人账务分为房账和客账，方便的同住客人账务处理、团队账务处理和转账处理，每发 生一次操作需输入操作员密码，防止账务有误，且每一笔账有据可查，支持多种付款方式．

●费用：计入一笔费用及相应金额；

●付款：付一笔钱，提供付款、退款、金额转账、押金处理、信用限额处理功能．金额 转账中，可设定转账入房账还是客账，转多少金额．

●转账：转费用，可设定转账入房账还是客账，转哪几笔费用． ●账目更改：对输错的账目进行更改，并注明原因． ●账务调整：对已夜审的账务进行更改，并注明原因．

●账单查询打印：可重打已离店客人账单、历史客账单，记录账单打印次数，防目作弊． ●团队账务处理：可按设定的团队支付说明自动结账，分清团队总账和团员账．

●客人押金处理：预订客人直接入押金处理，关在其预订单上显示出来，登记客人交押 金或付款后，在登记单上显示出来，可设定开通 IDD 功能．

4.2 商务管理系统

商务管理系统包括电话管理、票务管理、传真管理和文书编辑排版四大功能； ●电话管理

●票务管理

44

●传真管理

●文书编辑排版

4.3 电话自动计费系统

本电话自动计费管理系统适用于多种电话程控交换机，能在不干扰交换机正常使用的 基础上，增加通讯系统和前台电脑系统接收交换机的所有话单，即自动过账；具有完善的 自动计费、结账、管理、统计汇总及查询功能；能打印出定期统计报表及各种分类报表。

●程控交换机类型:可以设置文件话单参数、串口参数和并口参数。

●电话费率设定：对电话基本费率设置。

●半价设置：可设置半价星期、半价时间及半价节日等。

●附加费设置：可对计费中的服务费率、地区代办费等附加费进行设置。 ●用户类型：根据不同的电话计费方式，将酒店用户分类。

●设置分机：设置酒店内各分机的号码，包括分机所在楼层、房号及其使用者的用户类 型。

●电话类型设置：根据被叫号码的不同种类，将酒店所打的电话分类。 ●部门代码设置：对酒店内部各部门代码及名称的维护。

●查询话单：可分别按日期时间查询、按主叫电话号码查询、按被叫电话号码查询、按 电话种类查询、综合查询等多种方式查询相应的话单。

●统计报表：可按时间将报表分成日报表、月报表、年报表。在每一时间段内，又可根 据用户需要生成某一分机号（主叫号）或所有分机号的电话流水账及汇总表，还可生成某一 种用户类型或酒店内部某一部门的电话流水账及汇总表等。

●数据维护：可以完成数据备份、数据恢复、数据删除等功能。

4.3 营业收银系统

45

●多市别经营 同一台号不同市别不同收费标准，包括不同的最低消费，不同的台费和 不同的加收率；同一收费项目不同市别不同的单价、不同的折扣方式与不同的加收服务费 方式；不同市别不同的帐单计算方法等。

●预订处理 对客人订餐及宴会预订情况的处理，即时生成预订单，以便相关部门做好 准备接待工作。

●帐单开单 即时开设帐单记录点菜情况，并具有增加、取消、修改和查询等功能，另 外帐单上记录服务员号、台号、人数等信息，以强调责任制或方便管理和统计数据。一台 可开多张帐单（即搭台开单），尤其适合早茶营业。

●帐单查询 可按未结帐单、已结帐单、并单帐单、作废帐单、退卡帐单等分类查询某 一天的某一市别或全天的流水帐单，并可分类打印报表。

●帐单点菜 提供灵活的菜单对照表，只需收银员熟记项目分类号码便可快速查找出该 类别的详细项目明细代码，十分方便输入。

●帐单折扣 支持灵活多变的折扣方式，每一消费项目都可设置是否可折扣，可按营业 部门设置不同的折扣额，对特殊客人可直接操作全单折。

●帐单结帐 多币别与多方式的结帐，可指定某贵宾签单或挂帐到某公司，若与酒店前 台收银连网更可实现自动转帐到指定的房号。

●帐单退卡 在征得管理人员的许可下，可将某帐单作退卡处理。

●帐单作废 结帐错误的帐单，可作废并自动生成对应的新帐单，打印账单时注明＂重 打＂字样和重打帐单，以便核数和查询。

●帐单分拆 根据客人的要求，将一张帐单分成若干张帐单。 ●帐单合并 根据客人需求，将若干帐单合并到一张单上结帐。

●帐单打印 将帐单从打印机输出，并提供了打印次数记录功能，即同一张帐单打印了 多少次都作好记录，减少收银因粗心造成的浪费。

●班结报表 一班结束需移交工作时，收银员所做的帐务总结。 ●日结报表 餐厅一天的营业完成之后，对各种营业数据的统计。 ●月结报表 统计某一月内的营业总额。

46

●成本核算 根据输入的开始日期与结束日期，统计某段日期内商品的销售情况，并可 根据设置好的成本项目统计出成本商品数目。

●部门核算 按营业部门统计某段日期内的营业额，并以图表方式进行对比，以便进行 部门独立核算。

●签单挂帐设置 设置可以签单的贵宾名单或可挂帐的公司名单。

●挂帐结帐 可列出某公司或某贵宾所有的挂帐帐单，并可进行部分结算或全部结算。 ●操作跟踪 系统强大的操作跟踪功能，包括每一操作员的登录系统和对系统资料的更 改等跟踪。

●操作帮助 提供按系统主题及关键词索引的详细帮助说明。

4.4 人事工资管理系统

人事档案管理主要是完成建立员工档案（在职员工、历史员工、应聘员工），并可附 上员工相片，定期统计人事变动报表、部门花名册等等；

设置工资项目，根据用户的工资制度设置工资结构和工资项目之间的计算公式； 自定义工资输出资料的内容和输出方式；

进行工资发放，可以输出各类工资发放表、工资发放单，并可以输出银行要求的工资 文件，实现银行代发工资，进行工资汇总，并进行费用的分配．

4.5 财务管理系统

▲凭证管理

●会计科目管理 按照资产负债表内容设置科目代码，有增加、修改、删除、打印、查 询功能，代码采用三级制．

●凭证管理 有凭证输入、修改、确定、打印、查询功能，修改功能由经理级管理，查 询功能指输入凭证号显示相应的凭证内容．

●账簿记载 凭证资料输入后，可按会计科目列入流水账，分三栏式及多栏式记录，并 设置现金及银行日记账．

47

●凭证查询 收银查询：包括桑拿、演艺中心、保龄等各部门的收银查询； 核数查询： 查询核数营收表并过账； 仓库查询：查询仓库每日物料（食品）进出数量金额； 工资查 询：查询人事工资核数情况．

●报表统计及打印 统计的报表包括： 负债表、损益表、成本控制表、公司营业收入明 细表、营业收入对比分析表、工资福利明细表、管理费用明细表、营业费用明细表、公司 财产明细表、应收应付明细账、财务费用明细表、餐饮成本月度报表

▲固定资产管理

设置固定资产卡片项目和固定资产卡片格式； 固定资产分类及设置固定资产类别档案； 自定义固定资产输出资料的内容和输出方式；

管理固定资产卡片，对固定资产进行卡片式管理，输出分类别＋部门的固定资产卡片， 选定条件下的固定资产明细台账，并可根据用户自定义的条件，输出固定资产清单和固定 资产汇总表．

管理固定资产增减变动的情况，对固定资产的更动情况进行管理，更新固定资产卡片， 输出各类变动情况．并由固定资产卡片，可查询到任何一个固定资产历年来的变支情况， 自动计提固定资产折旧，每月自动计算固定资产折旧和计算固定资产净值，并可进行折旧 费用分配，输出折旧计算表．

▲财务分析

●比较分析 比较分析是将企业连续期的相关财务数据进行比较，以揭示账务状况和营 业情况增减变化的性质及趋向，因此，在比较分析中提供的比较分析表就是来处理和汇 总各种财务数据的功能，以达到企业对财务管理上的需要．

●趋势分析 趋势分析主要是根据用户提供的数据设置，用直方图和折线图绘出相关的 趋势分析图，以达到能提示其财务状况和营业情况增减变化趋向的逼真效果，其特点是 形象和直观，容易理解．

●比率分析 比率分析是对一个会计主体某一经营期间内的有关财务数据互为比较，得 出它们的比率，以说明各财务数据之间的相互关系，从而帮助财务信息的使用者据以评价 企业的财务状况和发现经营中存在的问题．

48

●构成分析 构成分析表明了各财务项目的构成情况，在本功能中我们将两个时期的结 构分析结果相比较，这样更容易发现问题所在，如某一项目的百分比在某一年内突然变动 （增加或减少），这便需要引起管理当局的注意．

4.6 仓库管理系统

共分为总仓与工程部仓两个仓库管理。

库存商品管理和核算，提供进价和售价两种核算方式，并提供加权平均法，先进选 出法、后进先出法、分批认定法等多种存货计价方式．对仓库进行入库、出库、直拨记 录．商品入库业务管理及会计核算，按购货业务资料内容，生成购货记账凭证，处理增 值税进项业务，登记商品库存账簿，销售业务管理，处理增值税销项业务，自动进行销 售成本结转，完成有关销售业务的核算，输出各类资料，如收发存汇总表、商品进销差 价表、业务日报表等资料．

4.7 总经理查询系统

●在住客人资料查询 可根据房号、姓名、抵店日期、入住状态和账号组合条件查询 满足条件的在住客人简要资料及详细资料．

●客源分析 可由输入分析日期范围及要分析的客源名称及分析类别生成相应的分析 折线、直方、圆饼等各类ＷＩＮＤＯＷＳ图形报表．

●历史客人资料查询 可根据房号、姓名、抵店日期、入住状态和账号组合条件查询 满足条件的历史客人简要资料及详细资料．

●国籍分析 可由输入分析日期范围及要分析的国籍名称及分析类别生成相应的分析 折线、直方、圆饼等各类ＷＩＮＤＯＷＳ图形报表．

●实时房态显示 可按要求实时统计并显示全部或某种房类的房态，客房出租数，出 租率，吉房数，吉房率等．

●房价表显示 可根据房类出租的情况实时生成房价矩阵表．

●房间出租预测 自动预测从开始日期起一个月的房间出租情况，并可打印生成预测 图表．

●各部门营业收入查询 可实时查询和分析营业收入情况．

49

本文来源：https://www.bwwdw.com/article/047r.html