宿舍管理系统需求规格说明书.docx

宿舍管理系统需求规格说明书.docx

《宿舍管理系统需求规格说明书.docx》由会员分享，可在线阅读，更多相关《宿舍管理系统需求规格说明书.docx（11页珍藏版）》请在冰点文库上搜索。

需求规格说明书

1.引言

1.1编写目的

本学生宿舍分配系统以公寓房间、入住学生为基础信息源，可以对房间和床位分配，可以使教务处、学生处、保卫处、公寓管理中心、财务处等学校职能部门及学校学院领导随时获得全方位的公寓管理信息，实现信息共享，提高工作效率。

本文档从用户、功能、性能、运行环境等各方面对系统进行了分析，以确保在系统开发过程中，确定好具体目标，使工作能有条不紊的进行，提高工作效率。

1.2背景

很多学校特别是中等及高等院校中，学生在校住宿的情况极其普遍。

随着高校的扩招，需要住宿的学生人数和学生公寓楼房越来越多，宿舍管理人员的需求量也相应地增加。

许多高校后勤实施社会化改革，学生住宿条件得到了很大改善，宿舍安排上打破了原来按专业班级强制集中住宿的限制，可供学生选择的余地也越来越大，相关部门对公寓管理的要求越来越高，导致公寓管理的难度越来越大，原来的手工管理已经无法适应，需要用信息化手段来实现。

因此，开发一个学生宿舍分配软件是十分必要的，希望能够为广大教师、校院领导、宿舍管理员和学生提供便利，加强学生住宿管理、规范高校公寓日常工作、提高公寓管理效能的有效工具。

1.3定义

用例图（UseCase）：

是指由参与者（Actor）、用例（UseCase）以及它们之间的关系构成的用于描述系统功能的动态视图。

呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。

顺序图：

是将交互关系表示为一个二维图。

纵向是时间轴，时间沿竖线向下延伸。

横向轴代表了在协作中各独立对象的类元角色。

类元角色用生命线表示。

类图（Classdiagram）：

是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。

类图不显示暂时性信息。

状态图（StatechartDiagram）：

是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应的。

活动图（activitydiagram）：

是阐明了业务用例实现的工作流程。

工作流程通常包括一个基本工作流程和一个或多个备选工作流程。

工作流程的结构使用活动图来进行说明。

协作图/通信图（CommunicationDiagram）：

而“协作”作为一个结构事物用于表达静态结构和动态行为的概念组合，表达不同事物相互协作完成一个复杂功能。

1.4参考资料

（1）殷建民主编，《软件系统分析与设计》，中国水利水电出版社，2008

（2）《学生宿舍基本需求》

（3）《2012级软件系统分析与设计实验指导书（16学时宿舍分配系统）》

2．任务概述

2.1目标

本学生宿舍分配系统以公寓房间、入住学生为基础信息源，可以对房间和床位分配，可以使教务处、学生处、保卫处、公寓管理中心、财务处等学校职能部门及学校学院领导随时获得全方位的公寓管理信息，实现信息共享

2.2用户特点

学生：

若要住宿需提交住宿申请，然后等待分配。

如有特殊要求，务必专门说明。

一旦得到批准通知，可以查询个人宿舍安排。

住宿后若有特殊原因，可以申请调整宿舍或床位，但依然要经过审核、批准。

一旦调换了宿舍，其所使用的设备也要随之变更记录。

教师：

分为班主任和辅导员。

辅导员负责查看、初审学生提交的住宿申请，对基本符合要求的，转交给宿舍负责人。

班主任和辅导员可以随时查看、了解所负责班级住宿学生的情况。

宿舍负责人：

负责对住宿申请进行综合审查，通过的则以班为单位分配床位。

可以随时查看和了解宿舍的基本情况、所有住宿情况和设备使用情况，对特殊情况及时进行统计，并报送相关领导。

学生一旦毕业或提出退宿，其宿舍和床位会立即变空，等待重新分配使用。

宿舍管理员：

负责宿舍设备情况的记录（购入登记、各建宿舍配置、损坏和修理登记、报废登记）、每日查房结果记录、学生晚归记录、宿舍具体情况管理（新房间登记、房间撤消、格局调整）。

校院领导：

可以随时查看、了解学校和学院宿舍的详细信息、学生住宿状况和宿舍管理员的基本情况以及每日查房的情况。

2.3假定与约束

经费限制：

由于是学习之作，资金的不足限制了本软件的研发。

开发期限;在时间方面，只能在课余时间完成本软件，对时间的安排需做到合理，恰当才能很好的完成本工程。

3.需求分析建模

3.1功能需求

3.1.1系统需求描述

本学生宿舍分配系统以公寓房间、入住学生为基础信息源，可以对房间和床位分配，可以使教务处、学生处、保卫处、公寓管理中心、财务处等学校职能部门及学校学院领导随时获得全方位的公寓管理信息，实现信息共享。

基本流程图如下:

3.1.2总体功能分析

各类角色的大体功能分析：

学生:

填写申请表、提交住宿申请、查看申请结果、申请宿舍调整

辅导员:

查看学生住宿情况、查看住宿申请、初审、返回申请结果给学生

班主任：

查看本班学生住宿情况

宿舍负责人：

复审、分配床位、查看住宿信息、宿舍住退更新、特殊情况报送领导

宿舍管理员:

宿舍查房记录、宿舍设备情况记录、晚归记录、宿舍集体情况

校院领导：

查看宿舍详细信息、查看住宿情况、宿舍管理员情况、每日查房情况

具体用例图如下：

3.1.3功能模块分析 （详述学生申请）

☆由学生申请住宿用例：

当学生登录后，进入申请界面，填写申请报告，出现两种情况，即填写正确或错误/部分错误，对应的成功提交申请或返回重新填写申请...构建活动图、协作图、顺序图等来完成功能的具体分析。

活动图：

状态图：

学生申请这一事件对应的状态：

首先是要进行申请表的填写预准备工作，即新建一张空白申请表，进行填写，完成后进行提交，即等同于进入等待审核状态；等待后台审核完成后，学生进行查看可以找到‘审核通过’‘不通过’以及‘不通过（部分不符合要求）’三种状态，一次审核通过后二审，产生‘批准’‘不批准’两种状态，批准通过，进入入住状态。

顺序图:

根据流程图和活动图，可以建立学生申请的工作顺序图，首先是登陆到首页>进入申请界面，申请表的填写与是否可以成功提交由提交控制检测并返回可申请/不可申请/有错重新填写，提交成功则学生等待来自辅导员以及宿舍管理员的的审核结果以及宿舍分配结果。

协作图：

3.2性能需求

3.2.1精度

在进行向数据库文件提取数据时，要求数据记录定位准确，在往数据库文件数组中添加数据（如申请表，住宿信息等）时，要求输入准确学生姓名，身份证，学号，班级，宿舍号等，按需求设定字符数。

3.2.2时间特性要求

（1）查询类页面响应时间<=3s

（2）更新处理时间，如新建、提交等最长时间不超过2s。

（3）数据的转换和传送时间，如远程数据传输不超过5s。

3.3数据需求

3.3.1输入\输出数据要求

1）宿舍的详细数据、学生住宿的情况以及宿管人员的具体数据要完整保管，且一旦发生变化，必须及时变更记录。

2）上述数据要能够导出到excel文件中，或从excel文件导入。

3）分配床位时可以采取二种方法：

●第1是按照一定的算法进行自动分配，

●第2是针对特殊要求进行手工分配

4）学生住宿需要记录的内容主要包括：

学号、姓名、所属学院、所属系、宿舍房间号、床铺号、柜子号、入住时间、联系电话等。

5）每个房间需要记录的内容主要包括：

宿舍房间号、面积、可容纳人数、目前空床数、

6）为简化宿舍分配过程中学生信息的重复录入，保证数据的一致性和统一性，最好可利用现行的学籍管理系统中的信息。

3.3.2数据分析模型（类图）

类图分析：

用户主要分为学生和职工两大类，学生类和职工类继承于people类，而教师类、领导类、宿舍负责人类和宿舍管理员类继承于职工类，辅导员和班主任类继承于教师类；学生与辅导员、班级、住宿登记表、床位、宿舍、住宿申请等都是关联关系。

3.4故障处理要求

正常使用时不应出错，对于用户的输入错误应给出适当的改正提示。

若运行时遇到不可恢复的系统错误，也必须保证数据库完好无损，可以通过日志来了解故障现象、发生时间。

3.5其他专门要求

（1）进度需求：

系统开发的阶段进度要求。

（2）运行环境需求：

平台、体系结构、设备要求。

（3）培训需求：

无实体培训，系统配备《用户使用手册》，提供多媒体教学光盘。

4.运行环境规定

4.1设备

服务器

PC机（建议配置：

操作系统windows2000/XP/VistaCPUPentiumⅣ以上内存128M以上硬盘空间100M以上）

DVD光驱，打印机等。

4.2支持软件

软件运行基于windows平台上的2000，NT，XP,Vista等。

数据库：

MySQL

4.3接口

无