《宿舍系统需求分析(1)》由会员分享,可在线阅读,更多相关《宿舍系统需求分析(1)(18页珍藏版)》请在金锄头文库上搜索。
1、目录目录 第二章系统需求分析1 2.1功能需求1 2.1.1 基本功能需求1 2.1.2 报表需求1 2.1.3 用户界面需求2 2.2性能需求2 2.2.1系统安全性2 2.3 数据库的选择2 2.4 环境4 2.5 本系统总体框架5 2.5.1:用户分类及其功能需求5 2.5.2:功能需求6 2.6用例图7 用例18 用例28 用例38 用例49 用例59 用例610 用例711 用例811 用例912 用例1012 用例1113 用例1213 用例1314 用例1415 用例1515 用例1616 第三章宿舍管理系统概要设计17 3.1 系统功能模块17 3.1.1用户帐号模块18 3.
2、1.2 人员信息管理模块18 3.1.3卫生评比模块18 3.1.4查寝模块19 第二章 系统需求分析 2.1功能需求功能需求 2.1.1基本功能需求 本课题要实现的是高校学生宿舍管理系统,在设计该系统时,应尽可能的 贴近学生,便于用户操作。系统在实现上应该具有如下功能: 1.系统要求用户必须输入正确的用户名和密码才能进入系统。 2.系统应该提供学生住宿情况的基本登记。 3.系统应提供学生每学期学生的离校处理。 4.系统应提供查询功能,以方便用户对学生基本信息的查询(要实现按多种条件的 查询)。 5.系统应提供增加、删除、修改用户帐户的功能。 6.系统还应具有添加、修改、删除学生基本信息(学生
3、照片)的功能。 7.系统还应提供宿舍卫生管理功能。 8.系统应提供人员来访登记及结束访问的详细登记。 2.1.2 报表需求 学生宿舍管理系统的某些信息应当能够以报表形式打印出来。基本上应该能够 实现查寝和卫生统计的报表打印功能。 2.1.3用户界面需求 学生宿舍管理系统应提供简单、层次关系明了、清晰的操作界面,使用户一目 了然。尽可能的为用户的录入、查询等功能操作提供方便。快捷按钮的创建也 是非常需要的,以方便用户操作。 2.2性能需求性能需求 2.2.1系统安全性 学生宿舍管理系统中的增加用户、学生毕业离校等的某些模块都是相联系 在一起的,所以在系统的管理权限上应当进行严格控制,具体思想如下
4、: 1.要想对该学生宿舍管理系统进行操作就应当具有某些操作权限。没有权 限的用户将不能通过任何渠道来登录该系统,查看该系统的任何信息和数据, 以确保系统的严密性和安全性。 2.在上述要求基础上可以为该系统设定三种登录方式,程序开始运行所有 功能将是不可使用的,只有系统管理员登录、普通用户登录和只读用户三个窗 口可以使用,没有系统管理员或者普通用户的用户名和密码任何人都不能登录 该系统进行操作。 3.在具体实现时还应为系统管理员和普通用户设定不同的权限,系统管理员应 当可以使用系统的所有模块,普通用户对于大部分的很关键的模块是无权使用 的。只读用户只能观看数据对任何模块都无权修改。 2.3 数据
5、库的选择数据库的选择 数据库是数据管理的最新技术,是计算机科学的重要分支。十年来,数 据库管理系统已从专用的应用程序包发展成为通用系统软件。由于数据库具有 数据结构化、最低冗余度、较高的程序与数据独立性、易于扩充、易于编制应 用程序等优点,较大的信息系统都是建立在数据库设计之上的。我们选用的是S QL Server 2005。 2.4 环境环境 本系统网络端是以Windows系统为操作平台,用C+,Java编程语言和SQL Server 2005数据库来实现高校学生宿舍管理系统所需功能的。手机端是以android系统 为平台,用Java编程语言和SQLite数据库来实现高校学生宿舍管理系统所需
6、功 能的。 2.5 本系统总体框架本系统总体框架 宿舍管理系统 查 询 学生 卫 生 情 况 统 计 分 析 夜 不 归 宿 统 计 辅 导 员 信息查询 宿舍情况备注 本系学生信息设置 宿管科 学 生 信 息 录 入 用 户 管 理 信 息 系 统 维 护 学 生 会 宿舍基本信息查询 查寝及学生信息核对 2.5.1:用户分类及其功能需求 使用本系统的人员:普通学生、辅导员、宿管科、学生会(维权部)、系统管理员 1:宿管科需要通过此系统对宿舍的卫生情况进行统计,从而对学生宿舍卫生情况进行 分析,及夜不归宿统计。 2:辅导员通过查询本系学生信息,并进行备注。 3:学生通过此系统可以查询本宿舍住
7、宿人员信息及卫生情况。 4:系统管理员能对系统的帐户进行管理、设置学生信息,同时还可以进行信息修改。 5:学生会可以通过此系统记录查寝情况,并核对人员信息。 2.5.2:功能需求 宿管科: 账户设置:新建账户、删除账户、修改密码 学生信息管理:学生信息的增删改查。 宿舍管理:查询统计卫生情况及夜不归宿人员信息。能随时记录和修改学生卫生 情况,并发布最新卫生查询情况及夜不归宿人员名单。 辅导员: 信息查询:查询本系学生基本信息,寝室到位信息,宿舍卫生信息; 宿舍情况备注:针对优秀和整改的宿舍进行备注(仅本宿舍可以看到); 学生信息设置:可以对本系人员信息增加,修改。 学生会(维权部): 信息查询
8、:包括学生信息,寝室到位信息,卫生信息; 查寝:每天记录学生到位情况、登记未归人员,核对所查宿舍人员信息。 学生: 信息查询:查询卫生情况、晚归查询及本宿舍人员信息 2.6用例图用例图 宿管科 学生基本 信息查询 对卫生及晚归 信息修改 对住宿人员管理发布夜查结果 对学生信息进 行修改 对卫生进行检查对晚间人员进行检查 新建账户 本系晚间人员 检查结果统计 删除账户 卫生检查结果 发布 学生会 辅导员 修改账户的密 码 发布夜查结果 查询发布的 卫生结果 卫生批示 发布 查询发布的 夜查结果 夜查结果 批示发布 对本系人员 信息的修改 系统用户 登录系统 学生 查询本宿舍 人员信息 查询卫生
9、结果 查询夜归 结果 用例1 用例:学生信息修改 1描述:当学生基本信息发生变化时,宿管人员能对其进行修改 2参与者:宿管科 3事件流: (1)当学生信息发生错误或者变动时 (2)宿管科经核对后改正学生信息 4前提条件:宿管人员登录系统后的任意时刻执行此用例 5后置条件:系统发布学生修改后的信息 用例2 用例:住宿人员管理 1描述:当学生住宿情况发生变化时,宿管人员能对其进行修改 2参与者:宿管科 3事件流: (1)当学生住宿情况发生错误或者变动时 (2)宿管科经核对后改正学生住宿情况 4前提条件:宿管人员登录系统后的任意时刻执行此用例 5后置条件:系统发布学生修改后的学生住宿情况 用例3 用
10、例:晚间人员检查 1描述:自律会查询宿舍人员到位情况,并记录未归人员信息 2参与者:宿管科(自律会) 3事件流: (1)学生在规定时间内未到达宿舍或者夜不归宿 (2)宿管科自律会对其核查上报 4前提条件:当有晚归或未归情况发生时执行此用例 5后置条件:宿管科统计未归人员,并发布 用例4 用例:卫生检查 1描述:宿管科检查每个宿舍卫生情况,并评比每个宿舍卫生情况 2参与者:宿管科 3事件流: (1)宿管在一定时间内进入宿舍检查、评比 (2)统计评比结果 (3)评比结果发布 4前提条件:本用例建立在宿管科完成宿舍检查的基础之上,对本次评比结果储存 5后置条件:对本次评比结果发布 用例5 用例:新建
11、账户 1.描述:宿管科可以新建系统的账户。 2.参与者:宿管科 3.事件流 3.1常规流程 (1)输入新建账户的用户名 (2)输入新建账户的密码 (3)再输入账户密码作为核对 (4)输入用户类型等一系列用户信息 (5)系统显示成功新建。 3.2备用流程 (1)用户名已存在 在(1)步中,新建的用户名已经存在。系统将显示“用户已存在,请更换用户 名。” (2)密码不一致 在(3)步中,第二次输入的密码和第一次的不一样。系统将要求管理员重 新输入密码。 4.前提条件:宿管人员成功登陆 5.后置条件:如果该用例成功,系统中将产生一个新用户。 用例6 用例:删除账户 1.描述:宿管科可以删除系统的账户
12、。 2.参与者:宿管科 3.事件流 3.1常规流程 (1)输入账户的条件查询 (2)系统返回符合条件的用户列表 (3)删除列表上的用户 (4)系统返回此次删除的用户 3.2备用流程 (1)用户名已经登陆 在第三步中用户已经登陆在系统中,系统显示“删除XXX用户步成功,请稍后再 试。”。 4.前提条件:宿管人员成功登陆 5.后置条件:如果该用例成功,系统中将删除用户。 用例7 用例:修改账户信息 1.描述:宿管科可以修改系统的账户信息。 2.参与者:宿管科 3.事件流 3.1常规流程 (1)输入账户的条件查询 (2)系统返回符合条件的用户列表 (3)修改列表上的用户的信息(一项影响一批) (4)
13、系统显示“修改成功” 4.前提条件:宿管人员成功登陆 5.后置条件:如果该用例成功,系统中指定用户的信息将被修改。 用例8 用例:学生基本信息查询 1.描述:本用例允许用户输入查询条件获取满足条件的所有学生的详细信息 2.参与者:宿管科、学生会、辅导员、学生 3.事件流 3.1常规流程 (1)输入不同账户执行条件查询 (2)系统返回符合条件的用户需求列表 4.前提条件:宿管人员成功登陆 5.后置条件:如果该用例成功,系统给用户查询满足条件的信息。 用例9 用例:本系晚间人员检查结果统计 1.描述:本系学生会负责人员将对本系每个宿舍人员到寝情况进行检查及结果统 计 2.参与者:系部学生会 3.事
14、件流 3.1常规流程 (1)学生在规定时间内未到达宿舍或者夜不归宿 (2)系学生会相关人员对其核查上报系部 4前提条件:当有晚归或未归情况发生时执行此用例 5后置条件:系学生会统计未归人员,并发布系内系统 用例10 用例:查询发布的夜查结果 1.描述:本系学生及辅导员可以查询晚归和夜不归宿人员名单 2.参与者:辅导员、学生会、学生 3.事件流 3.1常规流程 (1)用户登陆,输入一个或多个查询条件。 (2)系统输出符合条件的人员列表。 (3)可对某一人员进行详细信息查看。 4.前提条件 用户必须在登陆进行身份确认之后才可进行此用例,同时,一旦确认成功,将随时支 持此用例。 5.后置条件 如果用
15、例执行成功,系统将所有的满足条件的人员名单展现在用户面前。 用例11 用例:夜查结果批示的发布 1.描述:辅导员可对本系宿舍夜查结果进行批示 2.参与者:辅导员 3.事件流 3.1常规流程 (1)辅导员登陆系统 (2)进行对夜查结果批示 (3)批示结果发布 4.前提条件 辅导员必须在登陆成功 5.后置条件 如果用例执行成功,辅导员将通过系统对批示结果进行发布 用例12 用例:查询发布的卫生结果 1.描述:本系学生及辅导员可以查询系卫生情况 2.参与者:辅导员、学生 3.事件流 3.1常规流程 (1)用户登陆,输入一个或多个查询条件。 (2)系统输出符合条件的人员列表。 (3)可对某一人员进行详
16、细信息查看。 4.前提条件 用户必须在登陆进行身份确认之后才可进行此用例,同时,一旦确认成功,将随时支 持此用例。 5.后置条件 如果用例执行成功,系统将所有的满足条件的宿舍相关信息展现在用户面前。 用例13 用例:卫生结果批示的发布 1.描述:辅导员可对本系宿舍卫生结果进行批示 2.参与者:辅导员 3.事件流 3.1常规流程 (1)辅导员登陆系统 (2)进行对卫生结果批示 (3)批示结果发布 4.前提条件 辅导员必须在登陆成功 5.后置条件 如果用例执行成功,辅导员将通过系统对批示结果进行发布 用例14 用例:本系学生信息修改 1描述:当本系学生基本信息发生变化时,辅导员能对其进行修改 2参与者:辅导员 3事件流: (1)当本系学生信息发生错误或者变动时 (2)辅导员经核对后改正学生信息 4前提条件:辅导员登录系统后的任意时刻执行此用例 5后置条件:系统发布学生修改后的信息 用例15 用例:查询本宿舍人员基本信息 1.描述:本用例允许学生查询本宿舍人员基本情况 2.参与者:学生 3.事件流 3.1常规流程 (1)输入个人账户进行查询 (2)系统返回查询结果 4.前提条件:学生成功