资源描述
学生宿舍管理系统
需求规格说明书
文件状态:
[ ] 初稿
[ ] 正在修改
[√] 正式公布
文件标识:
学生宿舍管理系统
目前版本:
1.0
作 者:
刘默予(G)宋玥(G)
李欣()刘洋()
赵子续()刘美玲()
完成日期:
1月8日
版 本 历 史
版本/状态
作者
参与者
起止日期
备注
初稿
陈烜、
刘振奎
曾柯、高炜、李瑞娟、宋朝
1月6日-1月7日
按软件需求编写纲领,丰富纲领形成初稿。
正在修改
曾柯、
高炜
陈烜、刘振奎、李瑞娟、宋朝
1月7日-1月8日
以开发人员视角检验纲领,修改模糊内容。
正式公布
李瑞娟宋朝、
陈烜、刘振奎、曾柯、高炜
1月8日
审查修改版本,经过后公布。
目 录
1引言 4
1.1目标 4
1.2文档约定 4
1.3读者对象和阅读提议 4
1.4项目范围 5
1.5参考资料 5
2总体描述 6
2.1产品前景 6
2.2产品特征 6
2.3用户类及其特征 7
2.4运行环境 8
2.4.1软件环境 8
2.4.2硬件环境 8
2.4.3网络环境 9
2.5设计和实现上约束 9
2.6用户文档 9
3系统特征 10
3.1描述和优先级 10
3.2激励/响应序列 12
3.3功效性需求 12
3.3.1 系统关键用例 12
3.3.2 用例说明 15
4 外部接口需求 20
4.1用户界面 20
4.2硬件接口 20
4.3软件接口 20
4.4通信接口 21
5其它非功效性需求 21
5.1性能需求 21
5.2防护性需求 21
5.3安全性需求 22
5.4软件质量属性 22
附录A:术语表 22
附录B: 分析模型 23
附录C: 业务规则 30
附录D: 待定问题清单 31
附录E:需求确定 31
“学生宿舍管理系统”需求规格说明
1引言
1.1目标
该文档首先给出了“学生宿舍管理系统”概貌,试图从产品前景、特征、运行环境等上给出整个系统轮廓,然后又对功效需求、接口需求和其它非功效性需求进行了具体描述。其中对功效需求描述采取了UML用例模型方法,不仅描述了每一用例基础事件流和备选事件流,而且还给出了很直观用例图。这些文字和图形全部为了具体正确地描述用户需求,同时也为用户更轻易地了解这些需求描述发明了条件。
该文档详尽说明了这一软件产品需求和规格,这些规格说明是进行设计基础,也是编写测试用例和进行系统测试关键依据。同时,该文档也是用户确定软件功效需求关键依据。
1.2文档约定
本文档采取从IEEE830标准改写并扩充软件需求规格说明模板。
文档中提到需求标识以以2.2中需求标识为准。
2.5设计和实现中提到需求表示以用户分类对应2.2中需求标识,如:2.5设计和实现中提到老师需求1即为2.2中需求标识中tr1。
2.2中“功效需求”一词,不等同于4.3中功效需求,前者指用户所需功效需求,属于用户需求层次,后者定义了软件开发人员必需实现功效,是需求工程意义上功效需求
1.3读者对象和阅读提议
本文档关键内容共分4部分:总体描述、系统特征、外部接口需求和非功效性需求。总体描述部分关键对系统整体结构进行了大致介绍;系统特征部分对系统功效需求进行了具体描述;外部接口需求部分对用户界面、软件接口、硬件接口和通讯接口等进行了具体描述;非功效性需求部分对非功效需求进行了具体描述。
1.3.1本文档预期读者有项目用户代表、项目投资方代表、营销人员、项目审批者、项目经理、开发人员、测试及文档编写人员。
1.3.2阅读提议
以下是我们针对不一样读者阅读文档提议:
1). 项目投资方
提议关键阅读“总体描述”部分文档了解项目标功效和前景。
2). 项目用户代表
提议关键阅读“总体描述”、 “系统特征” 、“用户界面”来确定需求。
3). 项目审批者和项目经理
提议全方面仔细阅读文档
4). 项目开发、测试及文档编写人员
提议以上小组组员关键阅读“系统特征” 、“外部接口需求”和“非功效需求”来了解将要开发网站。其汉字档编写人员尤其需要有针正确阅读“用户文档”部分。
1.4项目范围
学生宿舍管理系统:下文有简称宿舍管理系统,即用于实现对学生及宿舍信息资料进行编辑,添加,删除,统计,打印显示等功效软件系统。经过该系统,用户能够查看学生基础信息、宿舍信息等各方面资料,能够方便了解学生和宿舍总体情况。该管理系统为用户提供了部分简单数据查询、输出多种信息等功效。
用户经过输入学生基础信息(比如学生证号),由系统自行生成对应数据以供宿舍管理员查询,另外宿舍管理中心管理用户还能够对这些基础信息进行更新和删除, 学校学生宿舍管理系统努力争取给用户方便快捷路径去管理这些繁琐数据。
1.5参考资料
[1]Karl E. Wiegers 著, 软件需求. 清华大学出版社,
[2]Dean Leffingwell等著,软件需求管理——统一方法. 机械工业出版社.
[3]Soren Lauesen 著, 软件需求. 电子工业出版社,
[4]Ian Sommerville 著,需求工程. 机械工业出版社,
[5]张海藩.软件工程导论.北京:清华大学出版社,
[6]刘利民.田保军.邢红梅.软件工程综合设计.内蒙古工业大学,
[7]需求规格说明书,
[8]吴杰.UML基础和Rose建模案例.北京:人民邮电出版社,
2总体描述
2.1产品前景
学生宿舍管理系统对于一个学校来说是必不可少组成部分。现在好多学校还停留在宿舍管理人员手工统计数据最初阶段,手工统计对于规模小学校来说还勉强能够接收,但对于学生信息量比较庞大,需要统计存档数据比较多高校来说,人工统计是相当麻烦。而且当查找某条统计时,因为数据量庞大,还只能靠人工去一条条查找,这么不仅麻烦还浪费了很多时间,效率也比较低。
当今社会是信息化高速发展社会,原始统计方法已经被社会所淘汰了,信息化管理正是适应时代产物。信息发展永远是一个快速、主动状态,当一个技术不能满足需求时,就会有新技术诞生并替换旧技术。在我们二十一世纪今天,信息化占着主流地位,计算机在各行各业中利用已经得到普及,自动化、信息化管理越来越广泛应用于各个领域。
我们将学校宿舍管理情况进行了解后,采取对应信息化技术,经过研究、分析,开发设计了一套学生宿舍管理系统。学生宿舍管理系统采取是计算机化管理,系统做比较人性化,使用者会感到操作很方便,管理人员需要做就是将数据输入到系统数据库中去。而且数据库存放容量相当大,系统比较稳定,适合较长时间数据保留,也不轻易丢失。这无疑是为信息存放量比较大学校提供了一个方便、快捷操作方法。
2.2产品特征
特征1:设置宿舍管理规则。
特征2:设置学生管理规则。
特征3:创建、修改、删除和查询宿舍资料。
特征4:创建、修改、删除和查询学生信息。
特征5:登记学生入住统计。
特征6:登记学生迁出统计。
特征7:办理学生调换房间。
特征8:学生网上报修。
特征9:统计学生、房间。
特征10:查询学生、房间。
2.3用户类及其特征
C-1:系统管理员(优先考虑):
整个系统优先级最高参与者,她是整个系统监督者,对全部其它用户行为
和使用情况享受知情权。她关键工作是:对系统用户优先级设置;对系统基
本资料管理;对系统数据备份;添加或删除用户;进行系统维护;最关键是对其它用户工作监督,管理,分配权限,以确保系统透明性和业务合理性。
C-2:宿舍管理员
学校宿舍每一栋楼最少有一个宿舍管理员,她们关键工作是:住宿情况查询,包含学生信息和房间信息查询,查看能够入住房间,住满房间,要入住床位,和入住人员信息;办理入住,经过输入学生相关信息经过系统将其添加到住宿学生信息表中;办理迁出,经过输入迁出学生相关信息经过系统将其从住宿学生信息表中删除;调换房间,输入要调换信息和目标房间信息进行房间调换;数据统计,包含人数统计喝房间统计,经过输入要统计目标信息来查看入住人数或空床位数;维修管理,经过系统取得学生维修管理信息,并通知维修人员;报表打印,打印出自己所需要信息报表。
C-3:住宿学生
这里住宿学生能够包含立即入住或已经入住学生,她们能够输入自己相关学生信息,进行住宿登记注册;能够查询宿舍住宿情况信息,比如说输入自己入住要求,查看是否有对应空床位;还能够经过系统提出报修申请,通知宿舍管理员需要维修信息。
2.4运行环境
本系统是以Windows系统为操作平台,用ASP.NET编程语言做网页界面,用C#语言做网页界面和底层数据库互联,用SQL Server数据库来实现高校学生宿舍管理系统所需功效。
2.4.1软件环境
操作系统:Microsoft Windows 7或xp;
支持环境:IIS 6.0以上;
数 据 库:Microsoft SQL Server ;
开发环境:Microsoft Visual Studio ;
作图工具:Microsoft Office Visio ,Rose。
2.4.2硬件环境
用户端运行环境
CPU
飞跃4处理器 主频1.8G以上
内存
512MB以上
操作系统
WindowsXP或以上版本
网络工具
IE浏览器6.0以上或Netscape浏览器
服务器端运行环境
CPU
飞跃4处理器 主频2.0G以上
内存
1G以上
硬盘空间
1G以上硬盘剩下空间
输入设备
键盘/鼠标
操作系统
Windows Server
数据库
Microsoft SQL Server
开发环境
Microsoft Visual Studio.NET
2.4.3网络环境
本系统网络运行图图A-2,不管是用户端还是管理端用户等全部能够经过网络登录到本系统中。
2.5设计和实现上约束
2.5.1软件:windows 7或windows XP,运行环境:c# ,开发环境:.net;
2.5.2数据库软件:SQL Server ;
2.5.3符合中国全部法律要求;
2.5.4运行在windows 7、XP上。
2.6用户文档
用户文档名称
描述及文档标准
用户手册
使用非专门术语语言,充足地描述该软件系统所含有功效及基础使用方法依据GB8567-88用户手册
操作手册
向操作人员提供该软件每一个运行具体过程和相关知识,包含操作方法细节依据GB8567-88操作手册
3系统特征
3.1描述和优先级
3.1.1设定优先级意义
一个软件项目标实施并不总是一帆风顺,伴随提交最终期限临近,我们有可能会碰到这么一个情况:我们可能会发觉我们只能在最终期限以前确保质量完成用户一部分功效,换句话来说我们必需舍弃一部分用户功效需求。这时,假如我们在之前对用户需求做过优先级分析,我们就能够轻松地剔除掉那些用户现阶段还不需要能够在后续版本中实现功效需求、那些华而不实功效需求、那些实现上有很大困难将会严重拖延工期功效需求等等。优先级设定意义就在于此,经过它,我们能够集中注意力于那些用户最需要而且对开发而言风险也相对较小需求,从而在最终期限以前提交一份令用户满意产品。
3.1.2优先级确定规则
本项目优先级确实定将采取QFD方法,经过相关计算,依据最终计算出性价比高低来划分优先级。
3.1.3权值设定说明
权值设定包含各个特征权值和各个用户群权值。
3.1.3.1特征权值设定说明
特征包含4个方面:相对利润、相对损失、相对费用、相对风险。具体权值设定采取了《Software Requirements》一书中相关QFD确定优先级中权值设定方法。
3.1.2.2 用户群权值设定说明
本项目标用户需求来自5类用户群,分别是用户、老师、注册学生、游客、管理员。因为本项目标主体用户是老师和注册学生,则她们含有最高权值2;其次作为项目标投资方和日常维护者,用户和管理员含有较高权值1;最终,游客权值为0.5。
3.1.4优先级计算公式说明
本项目优先级计算公式套用了《Software Requirements》一书中介绍计算公式:
优先级=(价值%) / (费用% * 费用权值 + 风险% * 风险权值)。
3.1.5 评定标准
全部特征评分全部以数字1-9评定。
3.1.5.1 相对利润
如实施某项需求,对用户而言,1代表可忽略利益,9代表最大价值,依次类推。
3.1.5.2 相对损失
如不实施某项需求,对用户而言,1代表基础无损失,9代表严重损失,依次类推。
3.1.5.3 相对费用
如实施某项需求,对我们而言,1代表仅需要极少费用,9代表需要很多费用,依次类推。
3.1.5.4 相对风险
如实施某项需求,对我们而言,1代表基础无风险,9代表巨大风险,依次类推。
3.1.6优先级
根据涉众评定关键性和紧迫性对系统功效性需求进行优先级划分。
功效
高优先级
中优先级
低优先级
置之不理
用户管理
√
数据备份
√
软件注册
√
系统维护
√
系统设置
√
住宿情况查询
√
办理入住
√
调换房间
√
办理迁出
√
删除学生信息
√
人员查询
√
房间查询
√
人数统计
√
房间统计
√
房间录入
√
维修管理
√
报表打印
√
学生报修
√
学生基础资料输入
√
住宿情况查询
√
远程查询
√
物品管理
√
消防监控系统
√
3.2激励/响应序列
激励:系统用户发出数据库操作要求
响应: 系统验证用户正当性并给予对应权限
3.3功效性需求
3.3.1 系统关键用例
关键参与者
用例
系统管理员
1. 用户管理
2. 数据备份
3. 软件注册
4. 系统维护
5. 系统设置
宿舍管理员
1. 住宿情况查询
2. 办理入住
3. 调换房间
4. 办理迁出
5. 删除学生信息
6. 人物查询
7. 房间查询
8. 人数统计
9. 房间统计
10. 房间录入
11. 维修管理
12. 报表打印
住宿学生
1. 学生报修
2. 学生基础资料输入
3. 住宿情况查询
3.3.2 用例说明
用例ID号
UC-1
用例名称
用户管理
参与者
系统管理员
简单描述
系统管理员依据不一样用户职责来设置不一样用户权限,从而限制不一样用户所使用系统功效
前置条件
系统管理员登入“学生宿舍信息管理信息系统”
系统管理员激活用户管理用例
系统管理员有权限进行用户权限设置
后置条件
新增用户权限被系统管理员设置
新增用户取得对应操作权限
主干过程
1.0 系统管理员设置新用户权限
1.系统管理员新增一个系统用户
2.系统显示用户权限界面
3.系统管理员输入新用户权限信息
4.系统统计新用户权限信息
5.系统管理员退出系统
分支过程
1.1 系统管理员修改用户权限(从第2步分支出来)
1.系统管理员修改选中用户权限
2.返回第4步
1.2 系统管理员删除用户(从第1步分支出来)
1.系统管理员删除用户
2.返回第1步
异常
权限设置错误
用户权限矛盾
备注
本用例完成对用户权限设置,它由系统管理员来实施。提议系统管理员仅仅由一个用户来担当,这么就会使责任人单一,不轻易出现责任纠纷,和权限重合现象。而且,权限设置要完全依据用户职责来设计,
不一样用户要负担不一样职责,任务,明确责任人。使分工明确而单一。
用例ID号
UC-2
用例名称
系统设置
参与者
系统管理员
简单描述
系统管理员对系统基础信息进行设置,系统统计基础信息
前置条件
系统管理员登入“学生宿舍信息管理系统”
系统管理员激活系统设置用例
后置条件
系统基础信息设置成功
主干过程
2.0 系统管理员设置系统信息
1.系统显示目前系统基础信息表
2.系统管理员输入系统基础信息
3.系统管理员请求保留目前设置
4.系统保留目前设置
5.系统管理员退出系统
分支过程
无
异常
无
备注
此用例完成对系统基础信息设置,它由系统管理员来操作。
用例ID号
UC-3
用例名称
数据备份
参与者
系统管理员
简单描述
系统管理员对系统目前状态进行备份,保留到指定文件中或数据库中
前置条件
系统管理员登入“学生宿舍信息管理系统”
系统管理员激活数据备份用例
系统其它步骤目前时刻处于停止状态
后置条件
系统数据被复制存放到数据库或其它存放体中
主干过程
3.0 系统管理员备份目前系统信息数据
1.系统显示数据备份界面
2.系统提醒目前系统其它工作步骤应该停止
3.用户确定开始备份
4.系统开始备份
5.系统管理员退出系统
分支过程
3.1 系统管理员结束系统其它步骤(从第3步分支出来)
1.系统管理员退出数据备份用例
2.系统管理员关闭其它步骤
3.返回第1步
异常
无
备注
本用例完成系统数据备份,统计目前系统状态。备份技术有很多,这里最好采取双机热备份,对系统数据进行数次备份,拷贝,这么使系统数据被安全保留,以防万一。
用例ID号
UC-4
用例名称
办理入住
参与者
宿舍管理员
简单描述
宿舍管理员办理人员入住事务,将学生信息录入宿舍学生信息表中
前置条件
宿舍管理员登入“学校学生宿舍管理系统”
宿舍管理员激活办理迁出用例
后置条件
入住人员信息被统计在宿舍学生信息表
主干过程
4.0 宿舍管理员生成一份人员信息表
1.宿舍管理员使用用户名和密码进入系统
2.系统验证宿舍管理员身份
3.宿舍管理员输入学生信息
4.系统验证学生信息是否正确和房间号是否存在
5.系统将学生信息加入宿舍学生信息表
6.宿舍管理员退出系统
分支过程
4.1 宿舍管理员修改学生入住信息(从第3步分支出来)
1.宿舍管理员修改学生入住信息
2.返回到第4步
4.2 宿舍管理员删除学生入住信息统计(从第3步分支出来)
1.宿舍管理员删除学生入住统计
2.返回到第3步
异常
输入学生证号不是四位数字
输入房间号不存在
系统审核信息错误
备注
此用例仅仅对宿舍管理员是可见
用例ID号
UC-5
用例名称
办理迁出
参与者
宿舍管理员
简单描述
宿舍管理员办理学生迁出业务,而且将学生信息从宿舍学生信息表中删除
前置条件
宿舍管理员登入“学生宿舍管理系统”
宿舍管理员激活办理迁出用例
后置条件
入住人员信息从宿舍学生信息表中删除
主干过程
5.0 宿舍管理员办理迁出
宿舍管理员使用用户名和密码进入系统
系统验证宿舍管理员身份
宿舍管理员输入学生学号,姓名
系统验证学生信息是否正确
系统将学生信息从宿舍学生信息表中删除
宿舍管理员退出系统
分支过程
无
异常
输入学生不存在
输入学生学号和姓名不匹配
系统审核信息错误
备注
此用例仅对宿舍管理员可见。当有学生迁出时此用例开始被激活
用例ID号
UC-6
用例名称
人物查询
参与者
宿舍管理员
简单描述
宿舍管理员经过输入学生学号和姓名来查询学生其它全部信息
前置条件
宿舍管理员登入“学生宿舍管理系统”
宿舍管理员激活人物查询用例
后置条件
要查询学生全部被显示出来
主干过程
6.0 宿舍管理员查询学生信息
1.宿舍管理员使用用户名和密码进入系统
2. 系统验证宿舍管理员身份
3. 宿舍管理员输入学生学号,姓名
4. 系统验证学生信息是否正确
5. 系统显示学生全部相关信息
6.宿舍管理员退出系统
分支过程
6.1 宿舍管理员清除已填信息(从第3步分支出来)
1.宿舍管理员清除已填学生信息
2.返回到第3步
异常
1.输入学生不存在
2.输入学生学号和姓名不匹配
3.系统审核信息错误
备注
此用例只对宿舍管理员可见
用例ID号
UC-7
用例名称
房间统计
参与者
宿舍管理员
简单描述
宿舍管理员经过输入栋号来统计这栋已住人数和空床位个数。
前置条件
宿舍管理员登入“学生宿舍管理系统”
宿舍管理员激活房间统计用例
后置条件
统计好数目被显示出来以供宿舍管理员使用
主干过程
7.0 宿舍管理员进行房间统计
1.宿舍管理员使用用户名和密码进入系统
2. 系统验证宿舍管理员身份
3. 宿舍管理员输入要统计楼栋号
4. 系统验证楼栋号是否存在
5. 系统调用数据库而且输出这栋楼已住人数和空床位个数
6. 宿舍管理员退出系统。
分支过程
无
异常
楼栋号不存在
系统审核信息错误
备注
这个用例仅由宿舍管理员操作。因为系统缺点只能统计出整栋楼人数和空床位数,不能具体说明每一个楼层数目。
用例ID号
UC-8
用例名称
房间查询
参与者
宿舍管理员
简单描述
宿舍管理员经过输入楼栋号和房间号来对录入房间信息进行查询
前置条件
宿舍管理员登入“学生宿舍管理系统”
宿舍管理员激活房间查询用例
后置条件
系统显示查询房间具体信息
主干过程
8.0 宿舍管理员查询房间住宿情况
1.宿舍管理员使用用户名和密码进入系统
2. 系统验证宿舍管理员身份
3. 宿舍管理员输入楼栋号和房间号
4. 系统验证所输入信息是否正确
5 系统显示房间具体信息
6. 宿舍管理员退出系统
分支过程
8.1 宿舍管理员清除已填信息(从第3步分支出来)
1.宿舍管理员清除已填学生信息
2.返回到第3步
异常
输入楼栋号或房间号错误
系统审核信息错误
用例ID号
UC-9
用例名称
学生报修
参与者
住宿学生
简单描述
学生经过系统向宿舍管理员提出报修申请
前置条件
学生登入“学生宿舍管理系统”
学生激活学生报修用例
后置条件
报修信息传给宿舍管理员
主干过程
9.0 学生报修宿舍坏旧物品
住宿学生使用用户名和密码进入系统
系统验证住宿学生身份
学生提出报修申请
系统显示报修明细表
学生填写报修具体信息
系统统计报修信息
学生退出系统
分支过程
9.1 学生修改报修表(从第5步分支出来)
1.学生修改报修表
2.返回到第6步
9.2 学生删除报修表(从第5步分支出来)
1.学生删除报修表
2.返回到第5步
异常
报修物品已出现在报修明细表中
报修物品不在许可报修范围之中
4 外部接口需求
4.1用户界面
学生宿舍管理系统应提供简单、层次关系明了、清楚操作界面,使用户一目了然。尽可能为用户录入、查询等功效操作提供方便。快捷按钮创建也是很需要,以方便用户操作。
系统应包含以下界面:
1 欢迎使用界面窗口
2 用户登陆界面
3 系统管理模块
4 房间管理模块
5 住宿管理模块
6 查询管理模块
7 编辑管理模块
8 数据统计管理模块
9 调房统计管理模块
10 分类打印显示模块
11 退出界面
4.2硬件接口
系统硬件接口还没有确定 。
4.3软件接口
“学生宿舍管理系统”经过用户界面向“学校管理系统”提交学生住宿相关信息。
“学生宿舍管理系统”经过用户界面向“学校收费系统”提交学生住宿相关信息,收费系统经过接收信息来确定学生缴费金额。
4.4通信接口
无
5其它非功效性需求
5.1性能需求
性能需求序列号
性能需求说明
cqa1
最少确保能够支持10人同时
cqa2
最多许可80人同时在线
cqa3
最少支持windows平台
tqa1
即时公布老师提供信息(尤其是课程相关通知),不超出1个工作日
sqa1
打开一个新页面响应速度不超出5秒
sqa2
确保10个下载链接,每个下载链接最少达成50k/s
sqa3
许可上传不超出2m大小文件
sqa4
信息要即时更新,不得超出1个工作日
5.2防护性需求
服务器应该在适宜温度、适度环境下工作,避免猛烈震动。
多种电源线和数据线铺设要合理而安全,避免出现意外脱接现象发生。
服务器所在地域应保持电压稳定及电源连续供给,尽可能避免高频率人为断电现象(比如:错拉电闸、保险丝熔断等),以保持服务器中数据一致性。
当提前获知断电时间时,应在网页上立即公布相关信息(比如:服务器将于几时几分关闭),避免站点忽然关闭。
意外断电时,应建立应急机制,确保服务器以最快速度恢复正常工作状态。
服务器管理员应确保服务器密码不泄漏。
服务器所在房间应做好安全防盗工作,避免偷窃现象发生。
5.3安全性需求
学生宿舍管理系统中管理权限上应该进行严格控制,具体思想以下:
1.要想对该学生宿舍管理系统进行操作就应该含有一些操作权限。没有权限用户将不能经过任何渠道来登录该系统,查看该系统任何信息和数据,以确保系统严密性和安全性。
2.在上述要求基础上能够为该系统设定多个登录方法,程序开始运行全部功效将是不可使用,只有系统管理员登录,宿舍管理员登陆,住宿学生登录三个窗口能够使用,没有输入正确用户名和密码任何人全部不能登录该系统。
3.在具体实现时还应为系统管理员和其它用户设定不一样权限,系统管理员应该能够使用系统全部模块,其它用户对于系统管理模块是无权使用。
4.服务器密码应足够复杂;服务器上所安装软件应即时更新、安装补丁;服务器上不得安装任何和业务无关软件。以预防非法入侵者攻击。
5.4软件质量属性
Availability(可用性)-1:“学校学生宿舍管理系统”将对学校内联网用户使用,用户在早晨6点到晚上12点99.9%时间可用,其它时间则90%时间可用。
Robustness(健壮性)-1:假如用户保留文件之前编辑器发生故障,那么下次同一用户开启程序时,编辑器能恢复在故障发生1分钟之前对所编辑文件所做全部修改。
附录A:术语表
E-R图:即实体-关系图,一个分析模型,它确定了一对实体之间逻辑关系。
外部接口需求:对软件系统和用户,另一个软件系统或硬件设备之间接口描述。
后置条件:描述用例成功完成后系统状态一个条件。
前置条件:用例开始之前必需满足条件或系统必需达成一个状态。
软件需求规格说明:软件产品功效性需求和非功效性需求集合。
数据字典:相关对问题域关键关键数据元素,结构和属性定义集合。
DFD图(数据流图):一个分析模型,它描绘了过程,数据集合,端点和它们之间流,这种流表现了业务过程或软件系统行为特点。
用例:描述了实施者和系统之间逻辑上相关可能交互集,系统输出为实施者提供了价值。用例能够包含多个场景。
用户类:直接或间接(比如,使用来自系统输出,但并不亲自产生这些输出)和系统交互用户。也称为最终用户。
附录B: 分析模型
1、处理步骤图:
2、系统步骤图
数据库文件夹
数据交换
用户输入
输入
学生宿舍
管理系统
输出
显示输出信息
3、系统业务步骤图:
用户登录
N
身份是否正当
Y
进行查询或修改
宿舍信息
宿舍状态统计
维修信息
调房信息
迁出信息
入住信息
学生信息
返回查询或修改结果
4、DFD图
4、数据描述
4.1 静态数据
以下表数据库文件:
4.1.1宿舍学生信息表
学生
证号
姓 名
学 院
班 级
学 号
电 话
手 机
家 庭
住 址
登 记
日 期
1
张 苇
计算机
学 院
0301
0101
50855490
136********
湖北武汉
.12.30
2
肖 瑾
材料学院
0302
0206
50855491
138********
四川成全部
.12.30
3
武 松
航海学院
0303
0307
50855492
139********
甘肃兰州
.12.30
4
林 冲
自动化
学 院
0304
0409
50855493
134********
上 海
.12.30
4.1.2 床位信息表
床位 编号
宿舍 编号
宿舍 电话
公寓 编号
空 否
A221
1-201
50855490
1
是
B223
3-409
50855891
3
否
F235
7-504
50859492
7
是
J355
9-365
50850493
9
否
4.1.3 已入住宿舍信息表
公寓 编号
所在 楼层
床位 编号
宿舍 编号
宿舍 电话
1
2楼
A221
1-201
50855490
3
4楼
B223
3-409
50855891
7
5楼
F235
7-504
50859492
9
3楼
J355
9-365
50850493
4.1.4用户表
字段名
描述
数据类型
数据长度
NULL
Primarykey
Username
用户名
char
10
N
Y
UserId
用户密码
char
10
N
Y
UserPower
用户权限
char
10
N
N
4.2 动态数据
包含输入数据和输出数据
4.2.1输入数听说明
经过键盘输入到计算机,这些数据保留在学生信息或宿舍信息数据库中。
4.2.2 输出数听说明
全部输出全部在显示器上。能够预览/打印“学生信息表”,“空床位信息表”,“已入住床位信息表”;依据查询要求,显示全部指定纪录;显示统计信息。
4.3 数据库描述
学生信息数据库:存放学生相关信息
已入住宿舍信息数据库:存放已占用宿舍相关信息
空床位信息数据库:存放空床位相关信息
4.4 ER模型
4.5 数据字典
数据字典是相关数据库中数据描述,而不是数据本身。数据本身将存放在物理数据库中,由数据库管理系统管理。数据字典有利于这些数据深入管理和控制,为设计人员和数据库管理员在数据库设计、实现和运行阶段控制相关数据提供依据。
4.5.1系统入住数据字典
数据处理名:入住
简 述:依据学生入住要求(公寓或宿舍),确定学生住哪间宿舍
输 入:学生证号
输 出:宿舍号
4.5.2入住信息数据字典
数据流名: 入住信息
组 成: {学生信息}+{宿舍信息}+{入住凭据}+时间
数 据 项: 学生信息
备 注: 个人
组 成: 学生证号+姓名+学院+班级+学号+电话+手机+照片+家庭住址
组 织: 学生证号
数 据 项: 学生证号
别 名:
描 述: 数据文件中区分于其它学生号码
定 义: 学号=1{数字}13
位 置: 学生宿舍管理系统
数 据 项: 姓名
别 名:
描 述: 数据文件中对某个学生称呼
定 义: 姓名=1{汉字}4||1{英文}26
位 置: 学生宿舍管理系统
数 据 项:学号
别 名:
描 述: 标识该学生在数据文件中代号
定 义: 学号=1{数字}13
位 置: 学生宿舍管理系统
数 据 项: 学院
定 义: 学院=1{汉字}10
数 据 项: 家庭住址
定 义: 家庭住址=1{汉字}n
数 据 项: 班级
定 义: 班级=1{数字}4
数 据 项: 电话
定 义: 电话=1{数字}8
数 据 项: 手机
定 义: 手机=1{数字}11
数 据 项: 宿舍信息
组 成: 房号+类型+状态
组 织: 房号
数 据 项: 状态
取 值: 空房可用
空房待修
已被占用
数 据 名: 入住凭据
备 注: 指学生要住宿所持学校开出证实
组 成: 学生证+学院所开证实
数 据 项: 时间
组 成: 入住时间+估计离校时间+住宿时间
4.5.3 系统空床位查询数据字典
数据处理名:空床位查询
简 述:依据学生入住要求(公寓或宿舍),查询宿舍信息表,确定是否有空床位
输 入:学生信息
输 出:[1] 无空床位
[2] 有空床位
4.5.4 系统按学号查询信息数据字典
数据处理名:按学号查询
简 述:依据学生三项统计表(学生信息,入住信息,空房信息),查询查对
输 入:学号
输 出:学生信息
数据流名称:三项统记表
简 述:用于记载学生和宿舍信息
组 成:学生信息+入住信息+空房信息
4.5.5 系统退房数据字典
数据处理名:退房
简 述:在学生离校时候,核实房间物件等,同时更改“宿舍信息表”
输 入:学生证号
输 出:学生信息和宿舍信息
附录C: 业务规则
规则定义
规则类型
静态或动态
起源
只有由系统管理员指定为宿舍管理员才有权删除或修改信息
约束
静态
学校学生宿舍策略
学生学号必需是四位数字
约束
静态
学校学生宿舍管理经理
在网络上传输信息假如包含个人身份信息,则要求加密
约束
静态
学校学生宿舍安全策略
用户只有输入正确用户名和密码才能够进入系统查询信息
约束
静态
学校学生宿舍管理经理
住宿学生只有早上8:00-晚上10:00这个时间才能够进入系统
约束
动态
学校学生宿舍管理经理
附录D: 待定问题清单
1.系统防护性问题。
系统防护性问题在本版本中需要在以后需求获取中逐步获取。因为它包含到系统权限和系统不一样用户职责分配问题。需要用户方和开发放配合,协作来共同处理系统职责权限分配问题。
2.系统数据库设计问题
本系统对数据库容量要求不大,不过对数据库更新要求较大。数据库需要常常进行更新,所以对数据库更新效率要求
展开阅读全文