学校教室管理系统软件需求规格说明书.doc

学校教室管理系统软件需求规格说明书.doc

《学校教室管理系统软件需求规格说明书.doc》由会员分享，可在线阅读，更多相关《学校教室管理系统软件需求规格说明书.doc（16页珍藏版）》请在冰点文库上搜索。

xxxx大学《软件需求》课程设计说明书

学校教室管理系统

软件需求规格说明书

版本：

V1.0

作者：

xxx

<2008.1.23>

1.引言

目标

软件需求规格说明描述了“学校教室管理系统”1.0版本的软件功能性需求和非功能性需求。

这一文档计划由实现和验证系统正确功能的项目团队成员来使用。

除非在其他地方另有说明，这里制定的所有需求都具有高优先级，而且都要在版本1.0中加以实现。

方便教室管理人员进行教室安排、查询。

方便学生进行教室申请。

方便人员查阅教室使用情况以免造成不必要的麻烦。

项目范围

“学校教室管理系统”供学校的教室管理部门使用，是对教室进行调度管理的软件。

该系统与自动排课系统联动，可以对排课后的教室用计算机进行借用管理、查询、分析统计，可生成全校教室使用情况汇总表。

对教室的借用提供了技术先进的图形化操作界面，直观、便捷。

当前网络的流行为教室管理网络化的发展提供了广阔的空间。

教室管理网络化，从一定程度上讲，该系统就是教室管理部门的网上办公室即意味着其具有信息时代的快捷方便等特征。

“学校教室管理系统”构建了一个教室使用者和教室管理者交流的网上平台。

一方面教室使用者可以方便地查询和使用；另一方面，教室管理者可以通过计算机实现最有效率的管理。

参考资料

[1]KarlE.Wingers著,软件需求.清华大学出版社，2004

[2]DeanLeffingwell等著，软件需求管理——统一方法.机械工业出版社，2002

[3]SorenLauesen著,软件需求.电子工业出版社，2002

[4]IanSommerville著，需求工程.机械工业出版社，2003

[5]IanK.Bray著,需求工程导引.人民邮电出版社，2003

2.总体描述

2.1产品前景

现今教室不断的变动，教室信息越来越繁琐，对于教室使用情况管理不方便，所以如今开发这套软件以便管理者对教室使用情况快捷、准确的查询。

使用学校教室管理系统可以方便高效的管理学校的教室资源配置，可以更快速、更准确的了解到目前学校教室的使用情况，为学生和老师及其他使用教室的人员提供最便捷的信息服务，适用于高校、中小学及其他各类学校，期望系统演化若干个版本之后，最终可以用于任何需要进行工作室资源配备的场合，而不受限于学校内使用。

2.2用户类及其特征

2.3运行环境

系统采用客户机服务器（C/S）模式，有多台客户机供前台使用

系统的运行环境为微软的Windows2000/XP/2003操作系统

“学校教室管理系统”的操作将通过如下的Web浏览器来完成：

MicrosoftInternetExplorer6.0或7.0版本

Firefox2.0版本

服务器的运行环境为：

Windows2000/XP/2003操作系统

“学校教室管理系统”只允许在学校内网中使用，外网用户将无法使用该系统

对系统的操作只能在校内的客户机上操作

3.用例规格说明

系统主要的用例图如下：

系统的主要用例描述：

用例ID

UC-01

用例名称

验证身份

参与者

学生、教师、教室管理人员

描述

学校的老师或学生或教室管理员登陆系统，系统将进行用户的身份验证，用以判断用户的使用权限

前置条件

使用者的身份符合系统要求

学校教室管理系统的数据库在线

后置条件

系统自动将数据更新，并且记录用户的操作

主干过程

1用户登陆

2系统连接至数据库查询用户资料

3系统给出用户的身份验证信息

4系统给出用户允许的操作

分支过程

无

异常

1数据库不在线时，用户将无法登陆系统，

2数据库中并没有用户的信息，用户需要注册

备注

用户登陆后，系统将自动记录用户的操作

用例ID

UC-02

用例名称

查询教室信息

参与者

学生、教师、教室管理员

描述

学生、教师或者教室管理员在身份验证之后，可以查询目前的学校教室使用情况，系统将给出查询的详细内容

前置条件

用户已经登陆系统，并且用户需要查询的教室在系统的数据库

后置条件

系统自动更新数据，并及时在线显示出教室的使用情况

主干过程

1用户向系统提出查询教室的申请

2系统响应用户的查询申请

3系统访问在线的数据库，取得教室的使用信息

4系统显示要查询的教室的详细信息

5系统提示用户的下一步操作

分支过程

无

异常

要查询的教室不在数据库中

数据库不能访问

备注

查询教室信息可以为用户的下一步操作提供信息，并且查询的数据库必须在线，否则系统应该给出具体的查询出错信息

用例ID

UC-03

用例名称

申请教室

参与者

学生、教师

描述

学生或者教师再查询教室的基本信息后，在系统的提示下进行申请教室的过程，符合学校的教室使用规定，并且给出申请的目的

前置条件

用户已经登陆到系统，并且系统给出的提示操作信息，允许用户进行申请

后置条件

系统的数据库及时更新，教室的基本信息被修改

主干过程

1用户向系统提出教室申请要求

2系统检验用户提出的申请要求

3系统给出申请结果

4系统访问数据库及时更新相关教室的使用信息数据

5系统提示用户的下一步可进行的操作

分支过程

异常

系统超出响应时间，询问用户是否重试操作

备注

用户提出的申请须按照系统的规定格式

系统的响应在4秒钟内

用例ID

UC-04

用例名称

反馈申请表信息

参与者

教室管理员

描述

教室管理员在系统中查询教室的申请信息

前置条件

教室管理员的身份得到系统验证，系统的数据库可以在线访问

后置条件

系统为教室管理员分配相应的权限

主干过程

1教室管理员登录系统

2教室管理员向系统提出教室申请情况的查询要求

3系统响应管理员的查询要求

4系统访问在线数据库，取得管理员管理权限内的全部教室所有相关信息

5系统提示管理员可以进行的下一步操作

分支过程

管理员查询教室的使用记录的单独某项

异常

数据库无法访问

系统响应时间超时，系统将自行中断管理员请求

备注

由于此用例需要取得的数据量很大，所以系统可以提示管理员访问的进度，并且系统的响应时间不能超过20秒

用例ID

UC-05

用例名称

配置教室

参与者

教室管理员

描述

除系统能够自动配置教室外，教室管理员也可以在系统允许的权限内来手动分配教室

前置条件

教室管理员必须先登录到系统

后置条件

系统自动将数据更新，保存教室的配置信息

主干过程

1教室管理员向系统提出配置教室请求

2系统向数据库发出配置申请

3数据库向系统返回可以配置的教室信息

4系统显示将需要手动配置的教室

5管理员根据实际情况，更改教室配置信息

6管理员向系统发出数据更新请求

7系统响应管理员操作，并向数据库发出更新请求

8数据库系统响应更新请求，及时更新

分支过程

管理员给出配置的原因

系统在向用户（学生、教师）给出管理员的修改配置信息

异常

系统响应时间超时，系统提示管理员是否重试操作

备注

由于Ｍicrosoft　ＳＱＬ　Ｓerver２０００／２００５的数据库系统在实现数据备份上的优势，所以备份比较轻松，

当学生或者老师

用例ID

UC-06

用例名称

更改教室信息

参与者

教室管理员

描述

教室管理员负责及时更新教室的使用信息，系统也可自动按照管理计划进行教室信息的更新

前置条件

教室管理员的身份得到系统的确认

数据库可以在线访问

后置条件

系统更新数据库

主干过程

1教室管理员查询教室信息

2教室管理员向系统提出更改教室信息的申请

3系统响应请求，并连接至在线的数据库

4系统给出可以操作的提示

5管理员对数据库进行更新

6系统给出更新完成的提示信息

分支过程

无

异常

教室管理员在操作错误时，系统应给出返回上一步的信息

备注

当要进行删除操作时，系统应及时给出提示

并可以恢复所删数据（在所删数据保存期内）

用例ID

UC-07

用例名称

打印教室信息

参与者

学生、教师、教室管理员

描述

所有用户都可以打印教室的相关信息，方便大家的使用

前置条件

用户已经登录到系统

后置条件

系统数据库自动更新

主干过程

1用户向系统提出打印请求

2系统向Windows办公软件如：

Microsoft

word提出打印申请

3办公软件响应打印请求

4数据库向打印机传送要打印的文件信息

分支过程

无

异常

数据库无法在线访问

无法打印

备注

待打印请求发出后，系统应在3秒内给出响应

4.外部接口需求

4.1用户界面

系统运行时的主界面要求为windows的经典运行界面，主界面可以是用ASP开发独立的页面，有一个主页，可以链接其他页面。

用户可通过各自的权限对各个页面进行操作。

4.2其他接口

硬件接口

系统的使用除硬盘外，基本没有与外界硬件的联系，不过考虑到数据库大量数据的备份等要求可以保持与磁带机和光盘刻录机的接口。

软件接口

在这里主要有软件与操作系统的接口，考虑到文档处理的需要可以包括与较常用的办公软件的接口如：

MicrosoftOffice

系统要有与SQLServer2000/2005数据库的软件接口

故障处理

考虑到软件的使用范围不大，所以故障处理一般由操作系统完成，系统只要保持与操作系统的接口即可，只要操作系统没有大的故障程序一般是比较稳定的。

考虑到用户对数据的安全性要求，程序可以有独立于操作系统之外的数据备份功能与过程，以及系统崩溃后的数据恢复功能，这些功能在SQLServer2000/2005中已经自带了，只要稍微在其上再增加用户所需要的附加功能即可。

5.非功能性需求

5.1软件质量属性

可用性：

在主要工作时间（星期一到星期五）对用户可用率达到90％以上，其他非主要时间中可用率达到80％以上。

在每天的上午7：

00到晚上6：

00系统的可用率应达到90％以上，其他时间内系统的可用率应该在80％以上。

健壮性：

系统可以流畅运行于Windows2000/XP/2003操作系统平台下

系统采用C/S模式，系统将容易安装到装有Windows2000/XP/2003操作系统的客户机上

数据库采用微软的SQLServer2005编写，具有较强的纠错和数据备份和保护能力。

系统具有容错能力，在误操作时，系统不会崩溃。

5.2其他非功能性需求

系统保证了较好的数据安全保密性

系统不允许外网用户的非法访问

6.数据需求（ER模型，数据字典等）

数据字典：

该系统中的数据流条目有：

教师信息＝教师号+教师姓名+学院名称+教师联系电话

班级信息＝班级号＋班级名称＋班主任＋学院代码+专业（学院代码表）

课程信息＝课程编号＋课程名称＋课程学分＋课程描述

教室信息＝教室号+教室类型+教室容量+教室管理员姓名+教室管理员联系电话

教室使用时间（上课时间）=星期+上课第几节数（如：

星期一第一,二节课）

班级名称＝年级+专业+班级序号（如：

2005级软件工程3班）

教室使用信息（上课信息）＝教室基本信息+教师基本信息+班级基本信息+课程基本信息+教室使用时间

系统用户基本信息＝用户名称+用户密码+用户性别+用户真实姓名+用户联系电话+用户所属部门

教室使用信息＝｛教师基本信息｝＋｛班级基本信息｝＋｛课程基本信息｝＋｛教室基本信息｝

教师信息基本信息={教师号}（数据值类型为数值类型，有效值范围0000到9999）

E-R模型：

附录A：

术语表

静态数据－－系统固化在内的描述系统实现功能的一部分数据，静态数据是系统内部有关的数据结构与操作规程，具体可包括：

系统用户表、教室基本信息表、班级信息表、课程基本信息表、

教室使用信息表、教师信息表等。

动态数据－－在软件运行过程中用户输入的后系统输出给用户的一部分数据，也就是系统要处理的数据，动态数据包括程序运行时输入和输出的数据,具体是数据库教室状态

教室类型

使用时间

的各个表的各个不同元组与属性值如：

教室使用信息表.

数据字典－－数据字典中的名字都是一些属性与内容的抽象和概括，它们的特点是数据的“严密性”和“精确性”。

附录B：

分析模型

系统的数据流图：

第一层数据流图

第二层数据流图

第三层数据流图

系统的关联图：

附录C：

业务规则

教室的使用应遵守学校的教室管理规定

附录D：

待定问题清单

系统的其他非主要用例，可以用卡片也可以已附录形式写在SRS之后

研制报告（研制过程，本设计的评价、特点，收获、不足与体会等）

通过这次课程设计，我了解到了做好软件需求分析的重要性，它可以说是软件开发过程中最重要的一环，而且其所耗费的脑力活动一点也不亚于编码实现的工作量，解决软件危机的一个主要途径就是要做好需求分析工作，虽然这次的系统和现实中比较接近但是做完需求分析之后我才发现这真是和自己意志力的一次较量，因为作需求分析真的很难，什么都要考虑周全，而且刚开始让人感觉无从下手。

不过做完了之后，我感觉自己的能力得到了很大程度的提高，这对我来说真是大有裨益，不仅巩固了课本上的知识而且体会到了前人在开发软件过程中总结出来的至理名言的深刻性。

不过这次课程设计还是有些缺憾的，比如用例部分的描述部分没有将能想到的所有的用例包含进来，而且感觉第一次做需求分析课程设计有些问题还没考虑全面。

16