【文章说明】
- 《软件工程概论》课程介绍与其他作业 👉《软件工程导论》笔记
- 本作业主要涉及的软件工程相关图表：
- 层次方框图 - 功能（图3-1）
- 交互接口原型图（3.6.1节）
- 实体 - 联系图（图3-2）
- 层次方框图 - 软件、硬件（图3-3）
- 层次方框图 - 服务（图3-4）
- 软件交互原型稿设计（附件2）
- 本作业涉及的需求分析相关图表：
- 软件相关人员（表2-1）
- 系统功能分类综述表（表3-1）
- 数据精度需求（表3-2）
- 软件运行时所需要的硬件设备情况（表3-3）
- 支持软件（表3-4）
- 文章版本：
- V2.0 2020年6月 Word 2.0 版本定稿，文档名称：绿原酒店客户服务系统LYHCSS《需求分析说明书》2.0
- V3.0 2026年2月25日 将 Word2.0 版本改编为 Markdown 版本，并公开发布为博客文章
目录
- 一、引言
-
- [1.1 编写目的](#1.1 编写目的)
- [1.2 背景](#1.2 背景)
- [1.3 定义](#1.3 定义)
- [1.4 参考资料](#1.4 参考资料)
- 二、任务概述
-
- [2.1 目标](#2.1 目标)
- [2.2 系统概述](#2.2 系统概述)
- [2.3 用户的特点](#2.3 用户的特点)
- [2.4 假定和约束](#2.4 假定和约束)
- 三、需求规定
-
- [3.1 功能综述](#3.1 功能综述)
- [3.2 功能需求](#3.2 功能需求)
- [3.3 性能需求](#3.3 性能需求)
-
- [3.3.1 精度](#3.3.1 精度)
- [3.3.2 时间特性要求](#3.3.2 时间特性要求)
- [3.3.3 处理能力](#3.3.3 处理能力)
- [3.3.4 灵活性](#3.3.4 灵活性)
- [3.4 安全性要求](#3.4 安全性要求)
- [3.5 运行环境需求](#3.5 运行环境需求)
-
- [3.5.1 设备](#3.5.1 设备)
- [3.5.2 支持软件](#3.5.2 支持软件)
- [3.6 接口需求](#3.6 接口需求)
-
- [3.6.1 交互接口](#3.6.1 交互接口)
- [3.6.2 软件接口](#3.6.2 软件接口)
- [3.6.3 硬件接口](#3.6.3 硬件接口)
- [3.7 数据](#3.7 数据)
-
- [3.7.1 数据模型](#3.7.1 数据模型)
- [3.7.2 数据管理能力要求](#3.7.2 数据管理能力要求)
- [3.8 其他专门要求](#3.8 其他专门要求)
- 四、其他说明
-
- [4.1 基于系统流程图的分析过程](#4.1 基于系统流程图的分析过程)
- 附件（待发布）
一、引言
绿原酒店客户服务系统（LYHCSS）需求分析小组在虹软科技股份有限公司指导和相关人员的大力支持和配合下，认真而全面地调查了用户对绿原酒店客户服务系统的需求。根据CSS 系统的业务分类、业务操作规程及其数据结构等具体要求，调查了单位的组织结构、相关部门的业务范围，业务逻辑结构，业务操作规程，业务样本，业务数据规格，确定了系统性能要求，系统运行支持环境要求，数据项的名称、数据类型、数据规格。以上这一切为进行下一步的开发工作奠定了良好的基础。
本软件需求说明书全面、概括性地描述了LYHCSS系统所要完成的工作，使软件开发人员和用户对本系统中的业务流程及功能达成共识。通过本需求说明书可以全面了解LYHCSS系统所要完成的任务和所能达到的功能。
1.1 编写目的
- 作为软件系统开发技术协议的参考依据，为双方提供参考；
- 根据自身项目的特点，对被开发软件系统的主要功能、性能进行完整描述，为软件提供接口和用户界面需求以及属性、设计约束等，为软件开发者进行详细设计和编程提供基础；
- 为软件提供测试和验收的依据，即为选取测试用例和进行验收的依据。
本文档的预期读者：技术管理人员、项目设计人员、项目开发人员及有关人员。
1.2 背景
1.3 定义
- LYHCSS：LuYuan Hotel Customer Service System，绿原酒店客户服务系统
- CSS：Customer Service System，客户服务系统
- 其他中文术语、概念的定义见附件1中的数据字典。
1.4 参考资料
-
第十一届中国大学生服务外包创新创业大赛的通知系列文件
-
《软件工程导论(第6版)》（张海藩等编著，清华大学出版社）
-
《绿原酒店客户服务系统（LYHCSS）可行性研究报告》及其参考资料
-
《绿原酒店客户服务系统（LYHCSS）设计方案》
-
《绿原酒店客户服务系统（LYHCSS）项目审批表》
-
校《软件工程概论大纲（2017版）》
-
《软件设计文档国家标准GBT8567-2006》之《11 - 软件需求规格说明(SRS)》
二、任务概述
2.1 目标
本软件产品作为为虹软科技股份有限公司定制的酒店客户服务系统，旨在对虹软科技股份有限公司和各大酒店提供：
- 以酒店客户服务为核心的集成环境；
- 以项目为核心、基于用户角色的权限机制。
通过本系统的应用，可实现：
- 顾客的脸成为"通行证"，酒店业务无卡（券）化；
- 酒店内部各系统间数据信息的共享；
- 顾客数据的实时操作；
- 房客的状态、消费记录等信息的快捷查询。
本系统应用于中国各大智慧酒店（包括具备基础环境及有智能化意向的酒店）中各场景的终端以及酒店内部管理部门。
2.2 系统概述
绿原酒店客户服务系统（LYHCSS）主要的功能如下：
-
为房客提供自助入住/退房服务，包括自动人证核验。
- 房客需要提前在第三方平台预定好房间（暂不支持现场选房）。到达酒店后，在自助机上刷脸、刷身份证进行身份验证，即可完成入住，系统会自动录入房客的人脸数据。
- 退房时，顾客在酒店终端上刷脸验证身份后，即可进入退房流程。
-
房客身份人脸识别。
- 房客无需持物理证件，只需在场景终端上刷脸即可验证身份，进行后续操作。
-
智能门禁控制。
- 房客在想要进入的区域（房间）的出入口验证身份后，系统会检查房客是否拥有进入该区域的权限。如果有，系统会发出放行指令给门禁。若为自动门禁，系统会发出解锁/开启的控制指令给房门控制部件；若为手动门禁，系统会指示入口处的工作人员放行。
-
一体化的消费服务支持，包括自助点单与自动记账、账单查看与统一结账。
- 服务系统与点单系统对接，自动将房客在各场景的消费行为记录在房客名下。房客无需即时结账，而是在退房时统一结账；与支付平台对接，房客可使用支付宝、微信支付等流行的移动支付软件完成支付；房客和酒店财务人员均可对账单进行主动查询。查询功能为辅助功能，由于时间限制，暂不展开进一步的讨论。
-
会员功能
- 本系统支持会员功能，在各基础功能页面均可设置会员功能辅助入口，帮助酒店提高顾客粘性、增加收入。在终端界面的首页设有会员功能主入口，用户进入后可以进行会员信息查看、会员购买和会员特权使用。
系统流程图如下，分析过程见4.1：
2.3 用户的特点
本软件的最终用户的特点：
- 酒店方面，以商务型酒店为主，度假型酒店为辅。商务型酒店的房客教育水平较高，软件使用水平中等。他们对服务的需求呈现多样化特点，包括预订的准确性、办理手续的便捷性、房间的舒适性、人身财产安全考虑等，归结为对安全、舒适、便捷等方面的服务需求特征。
- 酒店的房客（在酒店内有住宿消费的群体）方面，分为2类。
- 偶然房客，因出差或旅游等原因临时在酒店住宿，光顾酒店的频次较低。
- 常客。该类房客光顾酒店的频次较高，其中有一部分是享有特权的会员（VIP）。他们对酒店的服务较为熟悉。
操作人员除了具有一定的计算机应用能力外，还必须各司其职，不得越权操作，不得随意泄露口令，以共同维护整个系统的安全和正常运行。
系统管理员（维护人员）必须具备一定的网络及数据库的操作和管理知识,并具有高度的责任感和强烈的安全意识。
本软件的预期使用频度：
- 以中型酒店为例，有500左右客房，峰值人数1000人左右，同时使用人数峰值出现在就餐及退房时，最高不超过100人。[尾注1]
2.4 假定和约束
-
编号规定：
- 功能编号采用FX[-X-X...] 的方法，用横杆"-"作为编号字段分隔符，第一字段的数值表示系统一级功能等级的编号，第二字段的数值表示系统二级功能等级的编号，以此类推。
- 数据流图中处理的编号采用教材标准，与功能编号独立，两者并不是完全一一对应的。
-
来自任务提出者与分析员的假定和约束：本项目以第十一届中国大学生服务外包创新创业大赛的企业命题作为选题，赛事组织方和命题企业（虹软科技股份有限公司）对项目的具体要求进行了说明[尾注2]，分析员结合团队实际情况，提出了以下的假定和约束。
- 软件对开源项目的引用无限制。
- 软件对应的硬件可以制作模型或实物，硬件不实现控制功能。
- 项目的自动人证核验功能需要身份证读卡器。
- 软件在设计时需要酌情考虑顾客个人隐私保护的问题。
- 由于时间限制，软件不包含酒店人员信息管理的功能。
- 本软件的人证核验、硬件控制、支付功能采用模拟实现。
- 在退房流程中，本软件实际上需要与订房系统通信，但在本方案中不予考虑。
- 本软件使用的虹软SDK主要针对Android、IOS、Windows和Linux操作系统，对macOS支持性较差。
- 本报告中用于绘制系统流程图、数据流图的软件是Microsoft Visio专业版2019，图形符号受到形状库的限制，与教材给出的标准符号有细微差别。
- 对报告第3节（需求规定）的假定和约束：以实际应用时用户接受的各种服务[见3.7.1（数据模型）-层次方框图-服务]来进行功能划分。3.1（功能综述）列出了所有的大小功能，指出了功能之间的层次关系。3.2（功能需求）对大部分功能进行了详细说明。每张表说明的功能包括支持模块（功能）和关键模块，关键模块的命名通常与功能名相同。支持模块为大部分功能都要使用的基础模块，关键模块一般是每个功能独有的。关键模块遵循"低耦合"的设计原则。
- 本报告的版面采用A4竖向，为了将图、表的显示区域尽量控制在页边距之内，对图、表的呈现形式、外部尺寸、内部区域划分进行了调整。
-
其他假定和约束
- 以《软件设计文档国家标准GBT8567-2006》和本校往届的软件解决方案作品作为开发阶段文档的模板；虹软科技股份有限公司提供相应的企业标准（软件开放平台SDK），软件开发与典型实例考核相结合。
- 酒店必须提供相关运行软件有效的数据库接口标准，并在改动的过程中及时通知本软件开发商，以保证从中正确读取预决算参数，进行成本预算。
- 用户必须按照操作规程运行本软件，不得进行恶意破坏性操作。
- 本软件没有专门的开发经费来源。
- 开发软件运行的最短寿命需达到5年。
三、需求规定
在阅读本节之前，请先阅读与本节相关的假定和约束。
3.1 功能综述
3.2 功能需求
见附件1。
3.3 性能需求
3.3.1 精度
软件必须保证有足够的数据精度，不影响正常业务。部分数据的具体要求如下表。
3.3.2 时间特性要求
- 响应时间：软件应尽量做到响应快速，具体值应参照各类中小型软件，最慢不超过500ms；
- 更新处理时间：本软件的主要用户为房客，人脸识别是关键处理，为保证其处理速度，避免房客产生焦躁心态，总体更新处理时间应不大于2s；
- 数据转换和传送时间：软件中主要的数据转换为人脸图像到人脸特征数据的转换，传送的数据多为标准化前后的人脸信息和用于产生账单的房客各类服务消费记录，信息量不算很大，故数据转换和传送时间应不大于5s。
3.3.3 处理能力
- 以中型酒店为例，有500左右客房，峰值人数1000人左右，同时使用人数峰值出现在就餐及退房时，最高不超过100人。
3.3.4 灵活性
- 操作方式上的变化：为了节约成本，客房门上的终端不支持输入操作，后续可配备实体按钮以实现简单的输入操作；其他终端的操作方式均为触摸屏幕，后续可增加对语音控制的支持；当触摸屏发生故障时，应支持外接鼠标进行操作。
- 运行环境的变化：当前运行环境仅限于酒店内部的终端；后续运行环境将扩展到用户手机，形式为独立APP或小程序；加入管理功能后，运行环境将进一步扩展到电脑。项目采用跨平台网页为主要交互形式，减少后续的界面设计工作量。
- 同其他软件的接口的变化：当前为实现人证离线核验，需要读取身份证和拍摄身份证人像照片，后续可接入公安系统，则人证核验的接口需要调整；当前房客点单由另外的点单系统处理，后续点单系统可集成到服务系统中；当前房客支付时需要扫描二维码，后续运行环境将扩展到用户手机时可直接拉起支付软件。
- 精度和有效时限的变化：当前项目的目标客户为中国公民，后续随着国外客户群体扩大，"姓名"的长度需要增加，"手机号"的长度也需要增加；当前房客的服务消费记录存档时间为一个月，后续随着客户粘性提升，可能需要延长存档时间。
- 计划的变化或改进：当前方案使用的人工智能技术主要为人脸识别，后续可能需要与语音识别、物联网硬件控制等智慧酒店常见的技术相配合。
3.4 安全性要求
用户数据加密存储、传输，获取用户数据需要一定的权限。其中房客人脸数据离店即删，其他数据在硬盘上存档一个月。系统还应具备一定的恢复能力，能够恢复丢失的数据。
3.5 运行环境需求
3.5.1 设备
配置：预留给软件的计算机设备硬盘容量应大于3GB。
3.5.2 支持软件
3.6 接口需求
3.6.1 交互接口
（1）入住
（2）刷脸过门禁之客房
客房门周围设有距离传感器，门控终端平时处于休眠状态，当检测到有人靠近时自动唤醒（打开摄像头、亮屏）。
（3）刷脸过门禁之消费场景（餐厅、健身房、超市等）
餐厅用正餐时，自助机旁堆有号码牌，房客需拿取一块号码牌，在自助机上输入牌号（对应界面属于点单系统），方可进行点餐。点餐完成后，房客任意选择位置就坐，并将号码牌放在桌上，厨房完成菜肴制作后，根据牌号送餐到桌。
（4）退房
酒店工作人员会在退房时间进入客房，检查物品损坏或丢失情况。房客在订房的时候已经填写过计划退房的时间。房客在入住后通过大堂或客房内的终端申请退房，显示已预约，预约时间为原计划时间。房客可更改预约时间，若通过大堂自助机更改，最早可更改为5分钟之后；若通过客房内自助机更改，最早可更改为30分钟之后。查房通过后房客会收到通知短信，之后房客前往大堂，通过自助机查看账单并结账。
（5）会员中心
房客可通过客房内的自助机（目前仅支持该场景）进入会员中心。
3.6.2 软件接口
- 向门禁传送"放行指令"的信息格式是
exp<bool>，其中<bool>是人员是否拥有通行权限的标志变量。 - 接收订房平台"住房信息"的格式是
exp<string>，其中<string>是包含房客个人信息、房间好、入住时间段等数据的字符串。 - 向点单系统传送"房客编号"的信息格式是
exp<int>。 - 接收点单系统"消费记录"的信息格式是
exp<string>，其中<string>是点单系统生成的包含消费项目、时间、金额等数据的字符串。 - 向支付平台传送"订单信息"的信息格式是
exp<double>，其中<double>是从账单中提取的订单金额。 - 接收支付平台 "支付信息"的信息格式是
exp<time>，其中<time>是支付平台记录的支付时间。 - 数据通信协议：TCP/IP。
3.6.3 硬件接口
- 服务器端：RK3288 处理器，16GB 内存，1T 硬盘，100M 网卡以上配置
- 客户端：2G 显存、10M 网卡以上配置。
- 输入设备：身份证读卡器、摄像头、终端屏幕。
- 输出设备：终端屏幕、扬声器、指示灯、微型打印机。
3.7 数据
3.7.1 数据模型
说明："房客"的属性还有身份证号、姓名、性别、联系方式等；事务信息包括类型、规范、内容。另有实体、关系、属性一览表可参阅（附件3）。
说明：元素的呈现顺序部分取决于空间节省需要，如果多个数据元素同时包含一个子元素，且这种同时包含情况显而易见，则可能仅呈现部分包含情况。
3.7.2 数据管理能力要求
需要管理的文卷有4个（对应数据存储），表有7+8=15张（对应实体联系数量）。运行本软件系统所需的各种基础数据及前期的其他数据的规模约为 300M，数据的平均增长约为2M／人月，系统用于日志等记录的数据增长约为5M／月。具体增长速度由用户的使用频率及所发生业务的数据量决定。
3.8 其他专门要求
- 对使用方便的要求：软件应尽量做到响应快速、操作简便，按照使用频率对操作步骤进行合理安排。
- 对可靠性的要求：软件应保证系统运行稳定，避免出现系统崩溃。系统对用户操作的的合法性进行检查，关键操作提示用户确认。
- 对可维护性的要求：需要明确软件质量目标和优先级，改进程序文档；软件必须提供对系统中各种码表的维护、补充操作；软件必须按照需求规定记录各种日志。
- 对可补充性的要求：该系统应尽可能使开发者能够便利地添加新的功能或进行扩充与删改，使该项目更加完善。一个方法是合理划分、统一管理软件各功能模块。
- 对易读性的要求：该软件的编写时应使用规范的语法和格式，适当添加注释，方便其他开发者对其进行修改或重构。
- 对可靠性的要求：该系统应尽可能降低出现故障的次数，以提高用户的使用体验。服务系统在一个月内不能出现2次以上故障。
- 对故障的处理的要求：出现故障时要记录到日志文件中，并及时报告维护维护人员；软件需要定期进行故障排查和处理，并对可能出现的故障采取对应的应对措施，以防止不必要的损失。
四、其他说明
4.1 基于系统流程图的分析过程
某酒店需要为顾客提供基于人脸识别的服务，因此需要有效管理房客的各类数据。房客数据，包括人脸数据、消费记录以及房客信息存储在房客数据库中。当房客进行涉及到人脸识别的消费行为或房务时，应该及时操作房客数据库，如果房客发起退房请求，则应该及时报告给酒店收款系统和房客以便核对，规定在房客发起退房请求时才生成账单给酒店收款系统和房客。
酒店使用一台中型计算机处理操作房客数据库和产生账单的任务。房客涉及到人脸识别的消费行为和房务统称为事务，通过酒店各场景中的终端把事务传输到计算机处；系统中的事务处理程序对事务进行处理，操作处理在磁盘上的房客数据库。最后，房客在退房时读取磁盘，并且把账单交给终端显示或打印成纸质文件。由此画出的系统流程图描述了上述系统的概貌。
附件（待发布）
-
附件1：基于数据流图的分析过程模型
-
附件2：软件交互原型稿设计
- 附件3：数据模型中的3种信息
尾注1\] [《绿原酒店客户服务系统（LYHCSS）可行性研究报告》](https://blog.csdn.net/holeer/article/details/143749202) - 2.4 性能描述 \[尾注2\] [V16.0 A类赛题答疑（截止至20200413）](http://www.fwwb.org.cn/attached/file/20200413/20200413214938_451.pdf)