宿舍管理系统需求规格说明书
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
需求规格说明书
1.引言
1.1编写目的
本学生宿舍分配系统以公寓房间、入住学生为基础信息源,可以对房间和床位分配,可以使教务处、学生处、保卫处、公寓管理中心、财务处等学校职能部门及学校学院领导随时获得全方位的公寓管理信息,实现信息共享,提高工作效率。
本文档从用户、功能、性能、运行环境等各方面对系统进行了分析,以确保在系统开发过程中,确定好具体目标,使工作能有条不紊的进行,提高工作效率。
1.2背景
很多学校特别是中等及高等院校中,学生在校住宿的情况极其普遍。随着高校的扩招,需要住宿的学生人数和学生公寓楼房越来越多,宿舍管理人员的需求量也相应地增加。许多高校后勤实施社会化改革,学生住宿条件得到了很大改善,宿舍安排上打破了原来按专业班级强制集中住宿的限制,可供学生选择的余地也越来越大,相关部门对公寓管理的要求越来越高,导致公寓管理的难度越来越大,原来的手工管理已经无法适应,需要用信息化手段来实现。因此,开发一个学生宿舍分配软件是十分必要的,希望能够为广大教师、校院领导、宿舍管理员和学生提供便利,加强学生住宿管理、规范高校公寓日常工作、提高公寓管理效能的有效工具。
1.3 定义
用例图(Use Case):是指由参与者(Actor)、用例(Use Case)以及它们之间的关系构成的用于描述系统功能的动态视图。呈现了一些参与者和一些用例,以及它们之间的关系,主要用于对系统、子系统或类的功能行为进行建模。
顺序图:是将交互关系表示为一个二维图。纵向是时间轴,时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。
类图(Class diagram):是显示了模型的静态结构,特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图不显示暂时性信息。
状态图(Statechart Diagram):是描述一个实体基于事件反应的动态行为,显示了该实体如何根据当前所处的状态对不同的事件做出反应的。
活动图(activity diagram):是阐明了业务用例实现的工作流程。工作流程通常包括一个基本工作流程和一个或多个备选工作流程。工作流程的结构使用活动图来进行说明。
协作图/通信图(Communication Diagram):而“协作”作为一个结构事物用于表达静态结构和动态行为的概念组合,表达不同事物相互协作完成一个复杂功能。
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 功能模块分析(详述学生申请)
☆由学生申请住宿用例:当学生登录后,进入申请界面,填写申请报告,出现两种情况,即填写正确或错误/部分错误,对应的成功提交申请或返回重新填写申请...构建活动图、协作图、顺序图等来完成功能的具体分析。
活动图:
状态图:
学生申请这一事件对应的状态:首先是要进行申请表的填写预准备工作,即新建一张空白申请表,进行填写,完成后进行提交,即等同于进入等待审核状态;等待后台审核完成后,学生进行查看可以找到‘审核通过’‘不通过’以及‘不通过(部分不符合要求)’三种状态,一次审核通过后二审,产生‘批准’‘不批准’两种状态,批准通过,进入入住状态。