功能需求，性能需求，出错管理需求，逆向需求，接口需求，约束，将来可能提出的需求，安全性要求，可靠可用性要求
1.引言
1.1编写目的
1.2背景
A.项目名称：基于小程序的图书馆选座助手
B.开发人员：XXX
C.指导老师：XXX
D.系统描述:
2.任务综述
2.1目标
本应用的目标是使图书馆资源得到充分利用，为同学们提供更好的学习环境，减少图书馆人力资源的使用和降低其管理维护成本，并且提高信息的准确度和可靠性。
相应的需求有：
1.能够对一定数量的读者进行相应的信息存储与管理，包括读者信息登记、删除和修改；
2.能够提供图书馆座位的实时预定，包括
-实时展示当前图书馆的空闲座位；
-供读者预约当前图书馆的座位；
2.2用户特点
-图书馆管理员，对座位的权限进行管理。
-学生读者，注册系统账户，使用图书馆座位。
3.需求规定
3.1功能需求
通过对用户的需求收集（包括但不仅限于访谈，问卷，新闻采访搜集），在调研现有图书馆业务流程和数据分析的基础上，基本可以确定系统设计所必须达到的目标。
3.1.1层次方框图
图3.1.1
3.1.2E-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座位保留功能
3.学生违规记录功能：对于选择保留座位功能但是多次超时的同学进行相应的违规记录，并根据违规情况设定相应的处罚方式。
上述为学生角度的图书馆座位助手的功能分析，其状态转换图如图3.1.3.2.
图3.1.3.2
3.1.3.3座位管理功能
1.座位信息更新功能：管理员可以选择图书馆座位的座位开放区域，所以需要授予管理员相应的修改区域权限，来对图书馆的座位进行管理。管理员可以手动关闭或者打开图书馆的座位。
2.学生违规处理功能：管理员可以手动对于学生的违规记录进行修改，并可以在后台对违规处理办法以及方式进行修改。
上述为管理员角度的图书馆座位助手的功能分析，其状态转换图如图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.资源占用非常严重的
5.其它所有交互功能及反应速度应不超过5秒；
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小时不死机；
3.9.2可恢复性要求
3.9.3操作与数据可靠性要求
系统具有操作可靠性，保证读者及管理人员访问小程序时都能进行正常操作，例如在选已被选定的座位时，不能出现可选取提示或直接可以选取；同时也应具备数据可靠性，数据信息由管理人员定期更新，具有实时、准确和可靠性。被用户预定的座位必须实时更新到后台，另一人选座时应出现已被选座无法选取的字样。