功能需求，性能需求，出错管理需求，逆向需求，接口需求，约束，将来可能提出的需求，安全性要求，可靠可用性要求
1. 引言
1.1编写目的
本文档为基于小程序的图书馆选座助手的需求分析说明书。在确定了系统开发的可行性后，需要具体了解并明白基于小程序的图书馆选座助手到底要做什么，能做什么，即对此类应用做需求分析。同时，通过借鉴行业内人士在相关应用开发总结的经验来进一步了解开发过程中可能遇到的问题，为解决相关问题和为升级提供可能，也给未来应用的设计开发给予一定的指导意见。
1.2背景
图书馆，作为大学校园里最可宝贵的资源，为广大师生提供了学习求知的场所，且其海量的藏书构成了“知识的海洋”。经过近几年的发展，高校图书馆在阅读环境上改善了很多，空调、Wi-Fi 热点、电源插座等设施基本都已配备。这些资源和设施都免费提供给在校学生使用。随着到图书馆学习、查阅文献的学生越来越多，特别是在期末、重大考试前，图书馆经常是早早地排起了“长龙”，这时的“占座”现象也尤其突出。占座的工具花样百出，给图书馆管理带来了很多问题。而且有些读者占着座位，却一天都不使用，造成了极大的资源浪费。如何使图书馆的资源得到充分利用，实现对座位的最佳分配和规范管理，使同学们可以安心学习备考，是本项目开发设计的初衷。基于小程序的图书馆选座助手拥有查询空座、占座记录、使用座位权限和选择使用时间等功能，同时，此应用还要对用户的资料和各种数据信息做周密的备份和保密处理。
A.项目名称： 基于小程序的图书馆选座助手
B.开发人员：XXX
C.指导老师：XXX
D.系统描述:
基于小程序的图书馆选座助手为图书馆座位管理提供了一个方便的电子平台。该应用分为学生信息查询、预约座位、撤销座位、选择保留时间、短时间保留、违规记录等模块，给使用者方便快捷的体验，力图最大化利用图书馆资源。该系统依托微信小程序，使用WXML、WXSS和JavaScript来实现view模块和service模块，数据库选择MySQL，为确保安全性，可通过访问权限控制以及数据备份功能。
2. 任务综述
2.1 目标
本应用的目标是使图书馆资源得到充分利用，为同学们提供更好的学习环境，减少图书馆人力资源的使用和降低其管理维护成本，并且提高信息的准确度和可靠性。
相应的需求有：
1. 能够对一定数量的读者进行相应的信息存储与管理，包括读者信息登记、删除和修改；
2. 能够提供图书馆座位的实时预定，包括
– 实时展示当前图书馆的空闲座位；
– 供读者预约当前图书馆的座位；
– 当读者短时间内离开图书馆时，提供座位保留。
3. 能够提供一定的安全机制，提供数据信息授权访问，防止随意删改，同时提供信息备份的服务。
2.2 用户特点
基于小程序的图书馆选座助手针对的多是高校学生，座位数量和位置较为固定，读者的数量和来源受到一定的限制。主要的用户角色包括：
– 图书馆管理员，对座位的权限进行管理。
– 学生读者，注册系统账户，使用图书馆座位。
3. 需求规定
3.1 功能需求
通过对用户的需求收集（包括但不仅限于访谈，问卷，新闻采访搜集），在调研现有图书馆业务流程和数据分析的基础上，基本可以确定系统设计所必须达到的目标。
3.1.1 层次方框图
基于微信小程序的图书馆选座助手项目的选取主要目的在于围绕图书馆自习座位这一核心资源，完善和规范图书馆座位使用情况，避免资源浪费和其他问题的发生，故功能需求按照调查结果大致层次方框图如图3.1.1.
图3.1.1
3.1.2 E-R图
通过上述分析，该系统一共涉及到三个实体，分别为学生，座位以及管理员。根据之前数据字典的数据统计情况，对各实体的数据信息和数据关系进行整理：
1. 学生通过该系统预约座位和离开座位，输入自己的身份信息（学号，姓名等）和密码获取自己的个人信息（院系，座位预约状况等），并在图书馆接收管理员的管理。每个学生只能凭借有效身份信息选择一个座位。
2. 管理员拥有自己的工号，姓名，身份证号等信息，通过身份信息和密码的验证获取该系统相应的管理员权限。使用管理员权限可以管理后台座位使用情况，进行统一大批量座位管理，针对违规情况进行手动处理等，此外管理员还在图书馆中负责管理来馆学生。
3. 座位都有自己的座位编号，根据所在阅览室的不同和位置的不同设定不同的编号，此外还应该有座位的状态显示，包括“可选”，“不可选”，“保留”，“维修”等状态。学生一次只可选择一个座位，管理员可以对多个座位进行统一管理。
根据以上分析，系统E-R图如图3.1.2.
图3.1.2
3.1.3 具体功能分析
3.1.3.1 座位预定功能
1. 学生预定自习座位功能：系统的主要功能之一，学生在手机端打开小程序时，可以实时查看当前图书馆座位的使用情况，并根据自身需求进行座位的预约和使用。
2. 学生结束自习离座功能：当学生离开图书馆时，使用小程序进行离座的行为确定，系统会统计座位使用时长。
3. 学生信息查询功能：学生可以通过身份认证之后查询自己的座位使用情况，常选座位以及自己的违规记录及处罚等。
3.1.3.2 座位保留功能
1. 座位选定保留功能：在学生选择完座位后，系统会对该座位进行一段时间的保留，以防止学生无法及时到馆，根据实际情况选择保留时间。若学生多次没有在时间内到馆确认座位，则视作违规，多次违规可以限制其使用座位或者限制其使用座位时长。
2. 座位短时间保留功能：在学生中午或者晚上去吃饭，短时间离座的情况时，学生可以选择进行座位短时间保留，需要对学生离开时间进行记录，并在时间截止前一段时间和时间截止时短信或者微信通知学生，并在此时更新座位状态。违规处理同上。
3. 学生违规记录功能：对于选择保留座位功能但是多次超时的同学进行相应的违规记录，并根据违规情况设定相应的处罚方式。
上述为学生角度的图书馆座位助手的功能分析，其状态转换图如图3.1.3.2.
图3.1.3.2
3.1.3.3 座位管理功能
1. 座位信息更新功能：管理员可以选择图书馆座位的座位开放区域，所以需要授予管理员相应的修改区域权限，来对图书馆的座位进行管理。管理员可以手动关闭或者打开图书馆的座位。
2. 学生违规处理功能：管理员可以手动对于学生的违规记录进行修改，并可以在后台对违规处理办法以及方式进行修改。
3. 统计报表功能：管理员可以在后台导出一段时间内的图书馆座位的使用状态，根据统计报表对与图书馆内的座位进行更进一步的管理和使用优化。
上述为管理员角度的图书馆座位助手的功能分析，其状态转换图如图3.1.3.3.
图3.1.3.3
3.2 性能需求
3.2.1 经验数据统计
根据统计，软微图书馆座位为144个左右。由于以后可能存在图书馆扩张，并为了满足对其他图书馆具有性能上的支持，故注册用户数设定为20000个，最大座位容量设定为1000个。由于图书馆存在早高峰入场人数和晚高峰离场人数数目较多的特点，据各大图书馆的高峰入场人数经验数据约占20-30%的总座位数，并预防特殊情况浮盈10%，故并发用户数设定为400个，且绝大多数用户在使用完订座功能后都会离开，故在线用户数设定为700个。
3.2.2 性能需求点
性能需求点的选取，主要围绕以下三个方面
1.发生频率非常高的
2.关键程度非常高的
3.资源占用非常严重的
据此，我们选出了登录、授权获取微信信息、座位预定功能为主要的性能需求点，并对此做出分析。
3.2.3 速度及响应时间
1.登录、授权获取微信信息功能：程序必须在不超过 10 秒的响应时间内,处理50起登录任务；
2.座位预定功能：用户点击座位，程序必须在不超过2秒时间内响应；用户在确认选座、撤销选座时，程序必须在不超过5秒时间内响应；
3. 查询座位程序应在10秒时间内响应；
4.管理员进行登录、登出、座位管理等操作时，程序必须在不超过5秒时间内响应；
5.其它所有交互功能及反应速度应不超过5秒；
6.云服务器的带宽为2m/s，可供400名用户同时流畅使用登录、选座等基本功能；
7.数据的导入和导出也应在可接受时间内完成；
3.2.4主存容量
支持GB级的数据，数据库最大容量不超过10G。
3.2.5磁盘容量
服务器空间至少10GB以上。
3.2.6 压力测试
该程序在高于实际程序运行压力1倍的情况下，稳定运行12小时，即为通过压力测试，在小程序完成之后我们将会采用华为云性能测试服务 CPTS 工具进行压力测试。
3.3 出错处理需求
系统失效后能给出错误信息，提示用户采取适当手段处理故障。
使用本系统时可能出现如下故障：
1）输入用户名不存在：说明数据库没无此用户名，需开户。
2）密码错误：说明用户名和密码不匹配。弹出警告信息后需重新输入密码，一天内输入十次错误密码，将对此帐户进行冻结，需持身份证解冻。
3）由于管理员没有及时保存数据造成的数据丢失：可通过数据还原，还原成最近的数据备份。
4）要于不可抗拒力造成的损失：由用户自行承担。
3.4 逆向需求
逆向需求说明了软件系统不应该做什么，理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除发生误解的那些逆向需求。
首先要保证不出现数据的重复，比如图书馆座位的编号等；
其次要求用户与用户之间保证绝对的无关联，比如要保证每个用户所使用的用户名不可重复；
最后就是图书馆实时座位信息的更新，占座和离座都要第一时间更新以避免出现用户与用户需求的冲突，不能出现当管理员更新座位信息时，用户搜索的实时座位信息仍未更新。
3.5 接口需求
3.5.1 用户界面
采用微信小程序的形式，在微信中运行。
3.5.2 硬件接口
小程序不需要特定的硬件或硬件接口进行支撑，考虑到大量数据的备份等要求，需要保持与服务器的接口。
3.5.3 软件接口
主要考虑小程序与微信客户端之间的数据交换，以及小程序与定位接口的互联网和局域网连接。
3.6 约束
约束描述了应用系统应遵守的限制条件，在需求分析阶段提出这类需求，并不是要取代设计（或实现）过程，这只是反映了用户或环境强加给项目的限制条件，常见的约束有：精度约束、工具和语言约束、设计约束、应该使用的标准、应该使用的硬件平台等。
3.7 将来可能提出的要求
将来可能提出的要求，应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求，这样做的目的是，在设计过程中对系统将来可能的扩充和修改做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改预做准备和进行这种扩充和修改。
首先考虑到基于小程序的图书馆选座助手在投入使用之后，随着用户量的增加，用户在使用过程中反馈的数据也会增加。在用户反馈的数据处理方面，可对所有使用者占座情况等相关信息进行深度挖掘和大数据分析，得到一些有价值的信息，从而对系统进行迭代更新，开发出相应的功能来解决用户的一些“痛点”和共同需求以方便使用者进行占座。这将有利于对基于小程序的图书馆选座助手进行迭代更新和不断完善图书馆管理信息系统的各种功能；而且基于小程序的图书馆选座助手在后期的盈利也会不断增加，这更加需要图书馆管理信息系统的开发者围绕用户的需求对系统进行迭代和更新以实现更高的满意度和利润。
如果座位管理子系统发现有用户恶意占座和使用外挂进行抢座，则可以增加系统自动识别功能和举报功能进行制裁，净化图书馆管理信息系统的使用环境，避免影响其他用户的使用体验。
其次考虑到之后可能进行的盈利模式，比如帮助各种类似当当的商家进行活动宣传的推广来获取广告费，推广的活动不仅可以学生和老师，而且这笔广告费还能用于维持图书馆管理信息系统的平稳运行和迭代升级。这其中需要注意的是一定要保证商家推广的活动的真实性和质量以及与大学生需求的匹配度，避免对使用该系统的学生和老师造成不良影响。
最后要考虑未来图书馆座位扩充或减少，可对数据库中信息进行操作来进行调整，同时升级更高配置的服务器，使得系统更安全稳定的承担更大的访问量。并且当图书馆有了其他新的资源类似打印机的使用，可以一并加入小程序中方便学生使用，添加一个新模块或者一个新接口，来实现用小程序访问的目的。
3.8 安全性要求
3.8.1访问安全性要求
本系统用户主要为管理员和读者，读者必须登录并授权微信信息才能预定图书馆座位，管理员只有在登录之后才能对座位信息等进行管理操作。为了保护用户的账号密码不被泄露，我们将采用微信小程序安全性模块作为该系统的安全保障。
3.8.2 数据安全性要求
本系统的相关数据库都存储在数据库内。读者只能通过微信小程序作为入口预定座位。管理员成功登录之后可以对自己所管辖的座位信息和其他信息进行更改，其他人没有更改权限。小程序内部数据在更新时都要求有备份，并需要能够防止各类操作可能造成的数据丢失、破坏，同时防止用户非法获取内容；应检测出各种非正常情况，如设备的通信中断无法连接数据库等，避免出现长时间等待以及无响应。
3.9 可靠可用性要求
3.9.1 容错性要求
整个系统要求有很强的防错、抗错能力，保证数据的正常报送。当系统出现错误或者异常的时候，可以及时保存数据，确保重要相关数据、信息不会丢失。
例如：
1.小程序应保证7*16小时不死机；
2.小程序服务器宕机时间不超过1小时，平均故障间隔不低于200 小时；
3.小程序不能出现用户座位信息丢失的情况，如果出现，应迅速在微信消息中提示用户重新办理订座；
3.9.2 可恢复性要求
在进行图书或其他的数据信息录入或更新时，系统能够间隔固定时间自动保存，在系统出现异常时，数据可自动回复发生异常前的数据。
3.9.3 操作与数据可靠性要求
系统具有操作可靠性，保证读者及管理人员访问小程序时都能进行正常操作，例如在选已被选定的座位时，不能出现可选取提示或直接可以选取；同时也应具备数据可靠性，数据信息由管理人员定期更新，具有实时、准确和可靠性。被用户预定的座位必须实时更新到后台，另一人选座时应出现已被选座无法选取的字样。
4．运行环境规定
4.1 设备
建议小程序寿命：10年
硬件条件：智能手机
服务器：阿里云学生服务器
开发软件：MySQL、微信小程序开发软件等
开发时限：2019年12月31日前止
4.2支持软件
操作系统：Android/IOS
使用平台：微信
数据库系统：MySQL
Powered by Froala Editor