新生报到系统需求分析报告.docx
《新生报到系统需求分析报告.docx》由会员分享，可在线阅读，更多相关《新生报到系统需求分析报告.docx（21页珍藏版）》请在冰点文库上搜索。
新生报到系统需求分析报告
新生报到管理系统
需求分析报告
学院信息技术工程学院
班级网络工程1001班
成员丰云马红艳赵树悦甄亚男王刚
1引言
1.1标识
符合、缩略语和定义如下：
B/S:
Brower/Server浏览器/服务器
SQLSERVER:
系统服务器所使用的数据库管理系统（DBMS）。
UML：
UnifiedModelingLanguage（同一建模语言）的缩写，是一个标准的建模语言
1.2系统概述
新生报到管理系统是结合学校迎新活动管理的实际需要，对新生的入学情况进行管理的信息系统，提供丰富的查询分析功能和管理、决策信息，是提高高校迎新工作效率的管理软件。
使用该系统可以实现新生信息的有序存储，使得检索迅速、查找方便、并且提高了可靠性。
本软件旨在使学校对新生信息的管理，以减轻工作人员的负担，可以加快迎新工作的有条不紊的进行，实现直观化，合理化。
通过这样的系统，可以做到信息的规范管理、科学统计和快速的查询，从而减少管理方面的工作量。
尤其对于复杂的信息管理，计算机能够充分发挥它的优越性。
1.2.1项目来源及背景
新生报到系统采用UML结构，在设计初期即充分考虑系统的安全性、稳定性和所需提供的必要功能，并在充分吸取前人经验的基础上着手设计和开发。
因而功能齐全，性能稳定可靠，介面亲和力强，是普通使用者容易上手操作的新生报到系统。
该系统虽是今年刚开发的软件产品，每个新生要经历近8个处理环节。
在普通的服务器上、几百个用户同时在线处理、系统均能应付自如，未出现任何差错，大大减轻各级经办人员的劳动强度，因而赢得学院领导和各基层单位的一致好评。
1.2.2系统结构划分
本系统共分为：
报到、缴费、宿舍分配、户籍迁移、校医院体检等5个个功能模块。
其数据更新权归各职能部门所有，从而保证了全院范围内的数据一致性，也为责任落实到人提供了基础。
1.2.3用户特点：
本系统的用户是网上用户，一类是新生，他们只需要打开新生报到界面，输入自己的学号或者证件号等就可以进入根据自己系统的提示进入新生报到的程序；另一类用户是管理用户，他们是高校内部的人，主要是系统管理人员和教务处，他们熟悉该流程以及办理，系统人员对系统很熟悉，对系统进行维护。
2引用文件
《软件工程案例教程》机械工业出版社韩万江编着
《数据库系统概论》第四版高等教育出版社王珊萨师煊编着
3需求
本章分条详述系统需求，是指功能、业务（包括接口、资源、性能、可靠性、安全性、保密性等）和数据需求。
也就是，构成系统验收条件的系统特性。
给每个需求指定项目唯一标识符以支持测试和可追踪性。
并以一种可以定义客观测试的方式来陈述需求。
对每个需求都应说明相关合格性方法，如果是子系统，则还要给出从该需求至系统需求的可追踪性。
描述的详细程度遵循以下规则：
应包含构成系统验收条件的那些系统特性，需方愿意推迟到设计时留给开发方说明的那些特性。
如果在给定条中没有需求可说明的话，应如实陈述。
如果某个需求在多条中出现，可以只陈述一次而在其他条中引用之。
3.1要求的状态和方式
3.2需求概述
3.2.1系统总体功能和业务结构
我们采用面向对象分析作为主要的系统建模方法，使用UML（UnifiedModelingLanguage）作为建模语言。
UML为建模活动提供了从不同角度观察和展示系统的各种特征的方法。
在UML中，任何一个角度对系统所作的抽象可能需要几种模型来描述，而这些来自不同角度的模型图最终组成了系统的映象。
用例描述角色（用户、外部系统以及系统处理）是如何与系统交互来完成工作的。
用例模型提供了一个非常重要的方式来界定系统边界以及定义系统功能，同时，该模型将来可以派生出动态对象模型。
设计用例时，我们遵循下列步骤：
1）识别出系统的角色。
角色可以是用户、外部系统，甚至是外部处理，通过某种途径与系统交互。
重要的是着重从系统外部执行者的角度来描述系统需要提供哪些功能，并指出这些功能的执行者（角色）是谁。
尽可能地确保所有角色都被完全识别出来。
2）描述主要的用例。
可以采取不断问体积“这个角色究竟想通过系统做什么？
”来准确地描述用例。
3）重新审视每个用例，为它们下个详尽的定义。
新生报到管理系统流程图将各系统或子系统连在一起，着重说明这个系统各部分之间地关系，表达了系统各部分之间信息流动情况。
如下图所示：
图1：
新生报到系统系统流程图
3.2.1.1角色定义
用户或者执行这指与系统产生交互的外部用户或者外部系统。
3.2.1.1.1新生
该系统开发目的主要就是针对新生报到做智能化的设计。
新生和系统的每个功能都密不可分。
3.2.1.1.2管理用户
管理用户分各部门管理员和系统管理员，各部门管理员是指在新生报到管理系统中通过管理端参与新生报到工作的人员，它又分为宿舍管理员、财医院管理员、学务处管理员、学工处管理员、学院报到处管理员、一卡通管理员。
系统管理员是指对新生报到管理系统进行相关的设置、进行系统维护的人员，通过管理端登录对管理端的用户进行设置、分配权限等，它们的关系如下图所示。
图2：
管理用户角色的关系
管理用户的具体说明如下：
各部门管理员：
●宿管部管理员：
安排新生入住，对已入住的新生进行登记，管理新生入住信息。
●学院报到处管理员：
查验新生录取通知书相关信息是否正确，管理新生个人信息。
●财务处管理员：
管理新生缴费信息。
●校医院管理员：
组织新生体检，并记录新生体检信息。
●一卡通管理员：
管理新生一卡通发放情况。
●学工处管理员：
管理需要办理户口转移新生的户口转移信息。
系统管理员：
通过管理端对系统用户进行管理的人员，这个角色主要负责对管理端用户的增删，权限的设置等功能。
3.2.1.2系统主用例图
新生报到管理系统可以分为两个最重要的组成部分，一个是新生端子系统，一个是管理端子系统。
新生端子系统功能主要就是新生通过登录系统，查询自己的个人基本信息以及报到信息。
管理端子系统功能是学校各部门的管理员依据新生报到的相关信息办理相关手续，记录新生报到信息等功能。
系统的主用例图如下图所示。
图3：
系统的主用例图
3.2.1.2.1子系统
新生通过提交录取通知书等入学信息、付费信息等与系统管理端交互。
其主要功能是提供新生报到、缴费管理、寝室分配、户籍迁移、一卡通办理等。
其用例图和活动图如下图所示。
图4：
子系统功能用例图
主用例描述如下：
（1）?
?
预检信息
给前来报到的新生进行报到、核对并及时修改学生个人的基本信息；自动生成报到号，通过报到号为学生办理以下环节的手续；查看未报到和已报到的学生人数及基本信息。
（2）?
缴费管理
给前来缴费的学生进行缴费情况登记；查看未缴费和已缴费的学生人数及其个人基本信息；查看学生的缴费记录；财务处还有权设置学院内各专业的应缴金额和代收费用。
（3）?
宿舍管理
给学生分配宿舍；查看未分配宿舍的学生人数、基本信息和已分配宿舍的学生人数、基本信息和宿舍号；可查寻学院宿舍的住宿情况。
（4）户口转移
新生可按需求自主选择是否要办理户口转移，需要者办理户口转移相关手续，并进行登记。
（5）领取一卡通
已完成缴费的新生可到现代技术教育中心领取一卡通，并登记领取情况。
（6）体检
新生需到校医院进行体检，并登记体检信息。
a）预检信息
用例详细信息如图：
用例名称
预检信息
用例描述
给前来报到的新生进行报到、核对并及时修改学生个人的基本信息；自动生成报到号，并统计分类
执行者
新生、学院报到处管理员
条件
前置
新生录取通知书编号
后置
预检完成之后，生成新生个人基本信息表
基本流程
1）给前来报到的新生进行报到、核对并及时修改学生个人的基本信息
2）自动生成录取编号，通过报到号为学生办理以下环节的手续
查看未报到和已报到的学生人数及基本信息
备注
无
预检信息活动图，如图以下：
图5：
预检信息活动图
b）缴费管理
确认新生的缴费情况，并登记和录入新生的基本信息；对于未缴费的新生可以提供几种缴费的方式：
银行缴费、现场缴费或申请贷款。
用例名称
缴费管理
用例描述
缴费登记；统计已缴费人数
执行者
新生、财务处管理员
条件
前置
新生已经登录系统，并且已经办理报到
后置
记录每个学生的缴费登记；统计缴费的人数
基本流程
1、通过点击缴费按钮进行查询是否已缴费情况登记
2、对于已缴费的新生可以不用通过此过程；未缴费的新生应该进行此项办理
统计人数并录入
备注
无
缴费管理用例图、顺序图如下图所示：
图6：
缴费管理用例图
图7：
缴费管理顺序图
c）宿舍分配
分配宿舍给学生，并统计人数和录入学生基本信息，便于学生查询是否已分配宿舍、宿舍号码和宿舍人员名单。
用例名称
宿舍分配
用例描述
分配宿舍给新生，查询学院宿舍的住宿情况
执行者
宿管部
条件
前置
宿管部工作人员登入系统，新生已缴纳学费
后置
记录已分配和未分配学生人数、基本信息，并录入住宿人员名单
基本流程
1、宿管部将新生宿舍分配情况反馈给新生
2、新生根据分配情况办理入住手续，同时登记入住信息
3、查询学院宿舍的住宿情况，生成已入住宿新生的名单
备注
无
宿舍分配活动图：
图8：
宿舍管理用例图
图9：
宿舍管理活动图
d）户口迁移
新生根据自己的需要办理户籍迁移，管理员查询并统计已办理和未办理新生人数和基本信息。
用例名称
户籍迁移
用例描述
办理户籍迁移
执行者
学工处管理员
条件
前置
学生已经登录系统，并需要办理户口迁移
后置
记录已办理和未办理的学生人数以及基本信息
基本流程
1、给要办理迁移户口的学生办理户籍迁移登记手续
2、查看已办理户籍迁移和未办理的学生人数和基本信息
备注
无
户口迁移用例图、顺序图：
图10：
户口迁移用例图
图11：
户口迁移顺序图
e）一卡通办理
新生入校必须要的一卡通办理程序，学院给每个新生办理一卡通，对于已经领用一卡通的学生，要进行登记处理生并以生成表格的形式，给予新生进行查询，学院还要进行统计和登记。
用例名称
一卡通办理
用例描述
一卡通领用登记，并统计人数和基本信息
执行者
现代技术教育中心
条件
前置
新生已缴纳学费
后置
发放一卡通，并登记、统计人数和新生的基本信息确认
基本流程
1、给新生办理学院通用的一卡通领用情况登记
2、查看未办理一卡通和已办理的学生人数和基本信息
备注
无
一卡通办理的用例图、活动图：
图12：
一卡通管理用例图
图13：
一卡通办理活动图
f）体检管理
用例名称
体检
用例描述
新生注册后需到校医院处进行体检，并记录体检信息
执行者
校医院管理员
条件
前置
新生已缴纳学费
后置
体检完成后，校医院管理员记录新生体检结果
基本流程
1、新生凭录取通知书到校医院参加体检
2、新生体检完成后，校医院管理员对新生体检结果进行登记
备注
无
体检管理用例图如下图所示：
图14：
体检管理用例图
3.2.1.2.2系统管理
系统管理是管理系统的安全而设计的，该系统采用b/s设计模式，故只有合法用户才可以使用系统，考虑到系统使用的人员很多，所以系统提供用户注册与密码修改功能，注册需要在进入系统后由系统管理员分配，而不像一般网页注册那样直接填数据，修改密码则是在各种进入系统后提交新数据于系统，系统进行处理。
图15：
系统管理用例图
图16：
系统管理数据流图
3.2.2硬件系统的需求
服务器：
操作系统：
MicrosoftWindows2000Server
CPU：
P4处理器
内存：
512M
客户端：
操作系统：
全系列WINDOWS
CPU：
1G处理器
内存：
128M
浏览器：
IE5.0以上
3.2.3软件系统的需求
说明对软件系统的需求。
●操作系统：
Windows2000或以上版本
●数据库：
MySQL
●开发工具包：
JDKVersion1.6
●Web服务器：
Tomcat
●浏览器：
IE5.0及以上
3.2.4接口需求
说明硬件系统和软件系统之间的接口。
3.3系统能力需求
本条应分条详细描述与系统每一能力相关联的需求。
“能力”被定义为一组相关的需求。
可以用“功能”、“性能”、“主题”、“目标”或其他适合用来表示需求的词来替代“能力”。
3.3.1界面需求
页面内容主题突出，美观简洁
导航结构明确，易于用户理解使用
页面大小适中，能用各种浏览器以不同分辨率浏览，页面风格统一
3.3.2响应时间需求
无论是客户端还是管理端，当用户登录，进行任何操作的时候，系统应该及时地进行反应，反应的时间在5秒以内。
系统应能检测出各种非正常情况，如与设备的通信中断，无法连接数据库服务器等，以避免出现长时间等待甚至无响应。
3.3.3可靠性需求
系统应保证在开学期间7*24小时不停顿运行，保证50人可以同时在浏览器中访问并登录系统，此时系统能正常运行，显示无误。
3.3.4可扩展性需求
系统又能够能够体现扩展性需求，以适应将来功能的扩充。
3.3.5系统安全性需求
系统有严格的权限管理功能，各种模块须有相应的权限方能进入。
系统能防止各类误操作造成的数据丢失，破坏。
防止用户非法获取网页及内容。
3.4系统外部接口需求
本条应分条描述关于系统外部接口的需求（如有的话）。
本条可引用一个或多个接口需求规格说明（IRS）或包含这些需求的其他文档。
3.4.1接口标识和接口图
本条应标识所需的系统外部接口。
（若适用）每个接口标识应包括项目唯一标识符，并应用名称、序号、版本和引用文件指明接口的实体（系统、配置项和用户等）。
该标识应说明哪些实体具有固定的接口特性（因而要对这些接口实体强加接口需求），哪些实体正被开发或修改（从而接口需求已被施加于它们）。
可用一个或多个接口图表来描述这些接口。
3.4.2用户接口
A、采用Windows的通用图形界面，用户友好。
B、界面有一致性，界面规范遵循Windows软件界面饿规范
C、提供错误处理。
D、提供信息提示，用多种信息提示当前用户的状态、界面。
E、提供方便的联机帮助。
F、遵循国家关于计算机方面词汇的标准，用词正确、准确、无歧义。
G、本产品的用户一般需要通过终端进行操作，进入主界面后点击相应的窗口，分别进入相对应的界面（如、输入界面、输出界面）。
用户对程序的维护，最好要有备份。
3.4.3（接口的项目唯一标识符）
本条（从3.4.2开始）应通过项目唯一标识符标识系统的外部接口，简单地标识接口实体，根据需要可分条描述为实现该接口而强加于系统的需求。
该接口所涉及的其他实体的接口特性应以假设、或“当（未提到实体）这样做时，系统将……”的形式描述，而不描述为其他实体的需求。
本条可引用其他文档（如：
数据字典、通信协议标准和用户接口标准）代替在此所描述的信息。
（若适用）需求应包括下列内容，它们以任何适合于需求的顺序提供，并从接口实体的角度说明这些特性的区别（如对数据元素的大小、频率或其他特性的不同期望）：
a.系统必须分配给接口的优先级别；
b.要实现的接口的类型的需求（如：
实时数据传送、数据的存储和检索等）；
c.系统必须提供、存储、发送、访问、接收的单个数据元素的特性，如：
1）名称/标识符；
a）项目唯一标识符；
b）非技术（自然语言）名称；
c）标准数据元素名称；
d）技术名称（如代码或数据库中的变量或字段名称）；
e）缩写名或同义名；
2）数据类型（字母数字和整数等）；
3）大小和格式（如：
字符串的长度和标点符号）；
4）计量单位（如：
米、元、秒）；
5）范围或可能值的枚举（如：
0~99）；
6）准确度（正确程度）和精度（有效数字位数）；
7）优先级别、时序、频率、容量、序列和其他的约束条件，如：
数据元素是否可被更新、业务规则是否适用；
8）保密性和私密性的约束；
9）来源（设置/发送实体）和接收者（使用/接收实体）；
d.系统必须提供、存储、发送、访问和接收的数据元素集合体（记录、消息、文件、数组、显示和报表等）的特性，如：
1）名称/标识符；
a）项目唯一标识符；
b）非技术（自然语言）名称；
c）技术名称（如代码或数据库的记录或数据结构）；
d）缩写名或同义名；
2）数据元素集合体中的数据元素及其结构（编号、次序和分组）；
3）媒体（如盘）和媒体中数据元素/数据元素集合体的结构；
4）显示和其他输出的视听特性（如：
颜色、布局、字体、图标和其他显示元素、蜂鸣声和亮度等）；
5）数抿元素集合体之间的关系。
如排序/访问特性；
6）优先级别、时序、频率、容量、序列和其他的约束条件，如：
数据元素集合体是否可被修改、业务规则是否适用；
7）保密性和私密性约束；
8）来源（设置/发送实体）和接收者（使用/接收实体）；
e.系统必须规定接口使用的通信方法所要求的特性。
如：
1）项目唯一标识符；
2）通信链接/带宽/频率/媒体及其特性；
3）消息格式化；
4）流控制（如：
序列编号和缓冲区分配）；
5）数据传送速率，周期性/非周期性，传输间隔；
6）路由、寻址和命名约定；
7）传输服务，包括：
优先级别和等级；
8）安全性/保密性/私密性方面的考虑，如：
加密、用户鉴别、隔离和审核等；
f.系统必须规定接口使用的协议所要求的特性，如：
1）项目唯一标识符；
2）协议的优先级别/层次；
3）组，包括：
分段和重组、路由和寻址；
4）合法性检查、错误控制和恢复过程；
5）同步，包括：
连接的建立、保持和终止；
6）状态、标识、任何其他的报告特征；
g.其他所需的特性，如：
接口实体的物理兼容性（尺寸、公差、负荷、电压和接插件兼容性等）。
3.5系统内部接口需求
本条应指明系统内部接口的需求。
如果所有内部接口留到设计时或在系统成分的需求规格说明中规定，那么必须如实说明。
如果实施这样的需求，则可考虑本文档的3.4列出的主题。
3.6系统内部数据需求
本条应指明分配给系统内部数据的需求（若有），包括对系统中数据库和数据文件的需求。
如果所有有关内部数据的决策都留待设计时或留待系统部件的需求规格说明中给出，则需在此如实说明。
如果要强加这种需求，则可考虑在本文档的3.4.x.c和3.4.x.d列出的主题。
系统数据描述：
A）学生信息：
录取通知书号码+身份证号+姓名+性别+家庭地址+联系方式+班级编号
B）寝室信息：
房间号+档次+收费标准
C）档案信息：
录取通知书号+办理户口转移信息+寝室代码+学杂费缴纳情况
D）管理人员信息：
工作人员编号+工作人员姓名+身份证号+登陆密码。
E）辅导员信息：
辅导员编号+辅导员姓名+联系方式
D）班级信息：
班级编号+班级名称
（1）动态数据
学生信息表：
录取通知书号，姓名，性别，班级。
辅导员姓名，辅导员联系方式，寝室号
档案缴纳信息表：
学生姓名，录取通知书编号，组织关系缴纳情况，高中档案缴纳情况，学杂费缴纳情况。
（2）数据库描述
本软件采用SQLSERVER2005专用数据库接口。
3.7性能需求
（若有）本条应指明要求系统提供的、与安装有关的数据（如：
现场的经纬度）和要求系统使用的、根据运行需要可能变化的运行参数（如：
表示与运行有关的目标常量或数据记录的参数）。
为了保证系统能够长期、安全、稳定、可靠、高效地运行，新生报到管理系统应该满足以下性能需求：
（1）系统处理的准确性和及时性：
系统处理的准确性和及时性是系统的必要性能。
查询时应保证查全率，所有相应域包含查询关键字的记录都应能查到。
在系统实际和开发过程中，要充分考虑系统当前和将来可能承受的工作量，是系统的处理能力和相应时间能够满足信息处理的需求。
相应时间，更新处理时间都比较迅速，完全满足用户要求。
一般操作的相应时间应在3-5S内，对数据的导入、到处、软磁盘和打印机的操作也应在可接受的时间内完成。
（2）系统的开放性和系统的可扩充性：
系统在开发过程中，应该充分考虑以后的可扩充性。
可扩充系统可以通过简单地加入和减少系统的模块，配置系统硬件。
通过软件的修补、替换，完成系统的升级和更新换代。
（3）系统的易用性和易维护性：
系统是直接面对使用人员的，而使用人员往往在对计算机并不非常熟悉。
这就要求系统能够提供良好的用户接口，易用的人机交互见面。
要实现这一点，就要求系统应该尽量使用用户熟悉的过程。
系统中涉及到的数据是学校新生管理的相当重要的信息，系统要提供方便的手段供系统管理员进行数据的备份、日常安全管理、系统以外崩溃时数据的恢复等工作。
（4）系统的标准性
系统在设计、开发、使用过程中，要涉及很多计算机硬件、软件。
所有这些都要符合主流国际、国家和行业标准。
例如，在开发中使用的操作系统、网络系统、开发工具都必须符合通用标准。
3.8操作需求
说明本系统在常规操作、特殊操作以及初始化操作和恢复操作等方面的要求。
灵活性
说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：
a．操作方式上的变化；
b．运行环境的变化；
c．同其他软件的接口的变化；
d．精度和有效时限的变化；
e．计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
输人输出要求
解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。
对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
数据管理能力要求
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。
3.9可使用性、可维护性、可移植性、可靠性和安全性需求
（1）正确性
要求发布的软件达到用户的预期目标，运行时基本无错误。
（2）可靠性
在正常条件下，应该不出故障。
（3）效率
对于浏览、查询、增加、删除、更新和密码设置等一般操作，要求及时响应，在3-5S内。
（4）完整性
要求在发生意外时，保证数据不丢失。
（5）易用性
软件界面符合当前流行的习惯，尽量为用户的使用提供方便。
（6）可维护性
要求软件运行发现错误时，能够快速、准确地对其定位、诊断和修改、恢复。
（7）安全保密性
要求提供身份验证，只允许通过身份验证的用户使用本软件。
如果三次密码输入不正确，则强行关闭系统。
（8）可理解性
对于本软件提供的各种表单、按扭，其功能应该一目了然，易于理解。
（9）数据的可交互性
要求提供数据的导入/到处功能，尤其要提高与WORD/EXCEL等通用办公软件的数据交互接口。
3.10故障处理需求
说明本系统在发生可能的软硬件故障时，对故障处理的要求。
3.10.1软件系统出错处理
说明属于软件系统的问题；
给出发生错误时的错误信息；
说明发生错误时可能采取的补救措施。
3.10.2硬件系统冗余措施的说明
说明哪些问题可以由硬件设计解决，并提出可采取的冗余措施；
对硬件系统采取的冗余措施加以说明。
（爆炸、辐射）。
3.11计算机通信需求
本条应描述系统必须使用的或引人系统的计算机通信方面的需求
升级会员 