RUC自习助手_需求分析规格说明书

文档编号：2016051603

版本信息：v3.0

开发小组：找不到地方上自习组

成员：王丹丹、赵安、吴婧、杨轹丹、孟启飞、彭宇清

版本号	编写（修改）人	修改描述	修改时间
V1.0	吴婧	编写初稿	2016-3-14
V2.0	吴婧	对之前版本进行修改	2016-3-28
V3.0	吴婧	对之前版本进行修改	2016-5-16

I. 引言

　　i. 编写目的

编写这份需求分析规格说明书的目的是为了明确需求，规范化产品的编写，提高开发过程中的能见度，便于控制和管理产品的开发过程，同时安排项目规划与进度，便于程序员与用户之间的交流、协作，并进一步定制产品开发的细节问题，组织产品开发与测试，便于用户与开发商协调工作。这份需求分析规格说明书预期的读者主要是开发人员和管理人员。

　　ii. 背景

目前，中国人民大学教学楼的管理并不完善。与之相较，从预约到选座再到超时违规处理，图书馆已经建立了一套趋于完善的选座系统（但仍有不足，我们今后也会提出分析改进的建议）。

我们观察到，教学楼的管理存在着如下问题：

a) 自习教室选择随机：由于无法提前查看教室占用情况，同学们往往是随机选定教室自习，甚至由于绝大多数教室均处于上课占用状态（如白天明德主楼四层往往所有自习室均处于有课状态），很难找到合适的自习室，不得已更换教学楼，浪费了时间和精力；

b) 举办活动占用教室流程繁琐：经改进后的由中国人民大学教务处颁布的《教室借用流程》虽从审批时间及流程上一定程度地简化了申请借用教室的流程，但仍存在提交表单部门不一致、选择活动主管单位领导人审批不及时等问题；

c) 非上课时间借用教室无需申请：晚上的教室占用则无指定流程，许多组织举行例会前没有提前告知在该教室自习的同学，导致许多同学都有上自习到一半不得不更换教室，影响学习状态。

　　iii. 定义

RUC：Renmin University of China中国人民大学

　　iv. 参考资料

《构建之法》	邹欣	人民邮电出版社
软件工程6th Edition	[英] Ian Sommerville	机械工业出版社,中信出版社
软件工程导论第5版	张海藩	清华大学出版社(2008)
软件工程——实践者的研究方法	Roger S. Pressman	机械工业出版社

II. 任务概述

i. 目标

以中国人民大学为试点，开发一个微信公众号，为学校管理员与学生用户之间提供一个平台，初步实现教室预约的信息化、公示化以及自习地点的实时查询和推荐，保证教室资源的合理调控和利用。

具体为实现以下功能点：

针对学生用户：

　　a) 规范公共教学楼教室的非规定时间段的借用申请流程；

　　b) 公共教学楼教室使用状态的公示（包含自习人数占座比、是否被活动占用中等）；

　　c) 图书馆，藏书馆等自习地点选座情况实时查询；

　　d) 向学生用户推荐自习地点。

针对管理员用户：

　　a) 简化批准借用教室流程;

　　b) 观察教室使用情况，实现合理调控。

　ii. 运行环境

用户端运行：微信平台

开发工具：eclipse

后台数据库管理工具：SQL Server 2008

建模工具：Microsoft Visio

　 iii. 需求概述

现今中国人民大学在教师预约与自习资源管理等方面存在问题，我们将开发一款产品来协助学校进行宏观自习资源调控。

　iv. 条件与限制

a) 开发时间

　　一学期

b) 运行环境

　　用户端运行：微信平台

　　开发工具：eclipse

　　后台数据库管理工具：SQL Server 2008

　　建模工具：Microsoft Visio

c) 使用寿命

　　预期五年及以上

III. 功能模型

i. 用例

图1-1 RUC自习助手产品用例图

ii. 对性能的规定

i. 时间特性要求

响应时间：所有的操作响应时间一般不超过3秒

ii. 灵活性

该产品应该操作简单易上手，适合广大普通群众，有很好的可移植性，只要满足最低硬件要求即可运行次产品，同其他产品接口容易实现，试用的精度范围广，随计划的变动容易更改。

iii. 输入输出要求

解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对产品的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。

iv. 数据管理能力要求

管理员：

对用户信息、教室信息可以查询、增、删、改
修改登录密码

用户：

可以查询、修改个人信息
查询空闲教室
推荐自习地点

v. 故障处理要求

服务器出现故障，用户信息需及时多个备份防止信息丢失。

服务终端出现故障，用户可转到ITS服务台办理业务。

产品本身出现漏洞，导致用户信息出错，用户可反映到校方管理人员，寻求帮助。

vi. 其他专门要求

校方应履行对用户信息保密的义务，做好防护措施，防止黑客盗取或修改用户信息。此外应创建良好的工作环境，让用户流畅地使用产品。还要定期对产品和硬件进行维护或更新，保证产品的良好运行。

IV. 数据对象模型

1. 逻辑结构设计

所有数据存储在数据库ruc_zixizhushou中。

admin (admin_id, admin_name, admin_password, admin_loc, admin_status)

此为管理员用户对应的关系模式，管理员编号是关系的主码。admin_name, admin_password表示管理员登录姓名和密码，admin_loc是管理员所在的教学楼，admin_status是管理员此时是否在岗的标识

user (user_id, user_openid, user_status)

此为普通用户实体对应的关系模式，用户编号是关系的主码，open_id是通过微信登录接口获得的用户唯一标识码，user_status代表用户是否已入座自习

classroom (classroom_id, classroom_building, classroom_name, classroom_capacity)

此为教室基本信息对应的关系模式，教室编号是关系的主码和外码。classroom_building代表教学楼，classroom_name代表教室名称，classroom_capacity表示教室最多可容纳人数。

cls_status (classroom_id, cls_current, cls_people, cls_time)

此为教室状态对应的关系模式，教室编号是关系的主码。cls_current代表是否有课或被借出，cls_people代表教室现有自习人数，cls_time是时间段

library (lib_id, lib_area, lib_seat, lib_person, lib_outlet)

此为图书馆对应的关系模式，lib_id和lib_area是关系的主码。lib_seat代表座位号，lib_person代表是否有人，lib_outlet代表是否有插座。

request (request_id, user_id, user_stuid, user_name, user_school, request_time, request_building, request_classroom, request_reason, request_feedback)

此为教室借用申请对应的关系模式，请求编号是关系的主码。user_id是申请人的编号，user_stuid, user_school和user_name是申请人的学号、学院和姓名。request_time、request_building、request_classroom和request_reason是打算占用的时间、教学楼、教室名称和原因。request_feedback代表管理员对请求的处理

2. 物理结构设计

存取方法

a 在classroom表的classroom_id和classroom_building列上建立索引。由于教室号和教学楼号经常作为查找对象，建立连接操作，所以建立索引，可以提高查询速度。

b 在library表的lib_id列上建立聚簇，由于本校只有图书馆和藏书馆两个library，所以含有相同lib_id的元组比较多，所以适合建立聚簇，把lib_id列上具有相同值的元组集中存放在连续的物理块中。

数据库基本表概览