新生报到系统需求分析报告

1、新生报到管理系统需求分析报告学院班级网络工程1001班成员丰云马红艳 赵树悦甄亚男 王刚1 引言 31.1 标识 31.2 系统概述 31.2 系统概述 31.2.1项目来源及背景 31.2.2系统结构计划 31.2.3用户特点 32 引用文件 33 需求 43.1 要求的状态和方式 43.2 需求概述 43.2.1 系统总体功能和业务结构 43.2.2 硬件系统的需求 193.2.3 软件系统的需求 203.2.4 接口需求 203.3 系统能力需求 2033x（系统能力）203.4系统外部接口需求 213.4.1 接口标识和接口图 213.4.2 用户接口 213.4.3（接口的项目唯一标

2、识符 ） 213.5系统内部接口需求 223.6系统内部数据需求 233.7性能需求 233.8 操作需求 错误!未定义书签。3.9可使用性、可维护性、可移植性、可靠性和安全性需求 243.10 故障处理需求 243.12.1 软件系统出错处理 253.12.2 硬件系统冗余措施的说明 253.11 计算机通信需求 错误!未定义书签。3.12 设计和构造的约束 253.13 其他需求 254 尚未解决的问题 26265 注解 261 引言1.1 标识符合、缩略语和定义如下：B/S: Brower/Server 浏览器 / 服务器SQL SERVER系统服务器所使用的数据库管理系统（DBM）UM

3、L： Unified Modeling Language（ 同一建模语言 ） 的缩写，是一个标准的建模语言1.2 系统概述新生报到管理系统是结合学校迎新活动管理的实际需要，对新生的入学情况进行管理的 信息系统，提供丰富的查询分析功能和管理、决策信息，是提高高校迎新工作效率的管理软 件。使用该系统可以实现新生信息的有序存储，使得检索迅速、查找方便、并且提高了可靠 性。本软件旨在使学校对新生信息的管理，以减轻工作人员的负担，可以加快迎新工作的有 条不紊的进行，实现直观化，合理化。通过这样的系统，可以做到信息的规范管理、科学统 计和快速的查询，从而减少管理方面的工作量。尤其对于复杂的信息管理，计算机

4、能够充分 发挥它的优越性。1.2.1 项目来源及背景新生报到系统采用 UML 结构，在设计初期即充分考虑系统的安全性、稳定性和所需提 供的必要功能，并在充分吸取前人经验的基础上着手设计和开发。因而功能齐全，性能稳定 可靠，介面亲和力强，是普通使用者容易上手操作的新生报到系统。该系统虽是今年刚开发 的软件产品，每个新生要经历近 8 个处理环节。在普通的服务器上、几百个用户同时在线处 理、系统均能应付自如，未出现任何差错，大大减轻各级经办人员的劳动强度，因而赢得学 院领导和各基层单位的一致好评。1.2.2 系统结构划分本系统共分为：报到、缴费、宿舍分配、户籍迁移、校医院体检等 5 个个功能模块。其

5、 数据更新权归各职能部门所有，从而保证了全院范围内的数据一致性，也为责任落实到人提 供了基础。1.2.3 用户特点：本系统的用户是网上用户，一类是新生，他们只需要打开新生报到界面，输入自己的学 号或者证件号等就可以进入根据自己系统的提示进入新生报到的程序；另一类用户是管理用 户，他们是高校内部的人，主要是系统管理人员和教务处，他们熟悉该流程以及办理，系统 人员对系统很熟悉，对系统进行维护。2 引用文件软件工程案例教程 机械工业出版社 韩万江 编著 数据库系统概论第四版 高等教育出版社 王珊 萨师煊 编著3 需求本章分条详述系统需求，是指功能、业务 （包括接口、资源、性能、可靠性、安全性、保 密

6、性等 ）和数据需求。也就是，构成系统验收条件的系统特性。给每个需求指定项目唯一标识 符以支持测试和可追踪性。并以一种可以定义客观测试的方式来陈述需求。对每个需求都应 说明相关合格性方法，如果是子系统，则还要给出从该需求至系统需求的可追踪性。描述的 详细程度遵循以下规则：应包含构成系统验收条件的那些系统特性，需方愿意推迟到设计时 留给开发方说明的那些特性。如果在给定条中没有需求可说明的话，应如实陈述。如果某个 需求在多条中出现，可以只陈述一次而在其他条中引用之。3.1 要求的状态和方式3.2 需求概述3.2.1 系统总体功能和业务结构我们采用面向对象分析作为主要的系统建模方法，使用 UML（Un

7、ified Modeling Language） 作为建模语言。 UML 为建模活动提供了从不同角度观察和展示系统的各种特征的方法。在 UML 中，任何一个角度对系统所作的抽象可能需要几种模型来描述， 而这些来自不同角度的 模型图最终组成了系统的映象。用例描述角色（用户、外部系统以及系统处理）是如何与系统交互来完成工作的。用例 模型提供了一个非常重要的方式来界定系统边界以及定义系统功能，同时，该模型将来可以 派生出动态对象模型。设计用例时，我们遵循下列步骤：1）识别出系统的角色。角色可以是用户、外部系统，甚至是外部处理，通过某种途径与 系统交互。重要的是着重从系统外部执行者的角度来描述系统需要

8、提供哪些功能，并指出这 些功能的执行者 （角色）是谁。尽可能地确保所有角色都被完全识别出来。2）描述主要的用例。可以采取不断问体积“这个角色究竟想通过系统做什么？”来准确 地描述用例。3）重新审视每个用例，为它们下个详尽的定义。 新生报到管理系统流程图将各系统或子系统连在一起，着重说明这个系统各部分之间地 关系，表达了系统各部分之间信息流动情况。如下图所示：疋是是 1I-11F1F登记入住 宿舍一通办 理户口转移 办理校医院体 检学院报到11结束开始图1新生报到系统系统流程图3.2.1.1角色定义用户或者执行这指与系统产生交互的外部用户或者外部系统。3.2.1.1.1 新生该系统开发目的主要就

9、是针对新生报到做智能化的设计。 新生和系统的每个功能都密 不可分。3.2.1.1.2管理用户管理用户分各部门管理员和系统管理员，各部门管理员是指在新生报到管理系统中通 过管理端参与新生报到工作的人员，它又分为宿舍管理员、财医院管理员、学务处管理 员、学工处管理员、学院报到处管理员、一卡通管理员。系统管理员是指对新生报到管理系统进行相关的设置、进行系统维护的人员，通过管图2:管理用户角色的关系管理用户的具体说明如下：各部门管理员：宿管部管理员：安排新生入住，对已入住的新生进行登记，管理新生入住信息。学院报到处管理员：查验新生录取通知书相关信息是否正确，管理新生个人信息。财务处管理员：管理新生缴费

10、信息。校医院管理员：组织新生体检，并记录新生体检信息。 一卡通管理员：管理新生一卡通发放情况。学工处管理员：管理需要办理户口转移新生的户口转移信息。系统管理员：通过管理端对系统用户进行管理的人员，这个角色主要负责对管理端用户的增删，权 限的设置等功能。3.2.1.2系统主用例图新生报到管理系统可以分为两个最重要的组成部分，一个是新生端子系统，一个是管 理端子系统。新生端子系统功能主要就是新生通过登录系统，查询自己的个人基本信息以 及报到信息。管理端子系统功能是学校各部门的管理员依据新生报到的相关信息办理相关手续，记录新生报到信息等功能。系统的主用例图如下图所示新生新生端子系统管理用户图3:系统

11、的主用例图32121子系统新生通过提交录取通知书等入学信息、付费信息等与系统管理端交互。其主要功能是提 供新生报到、缴费管理、寝室分配、户籍迁移、一卡通办理等。其用例图和活动图如下图所 示。o预检信息缴纳学费O领取一通OO登记入住新生办理户口转移体检OA宿舍部管理员X O一卡通管理员学院报到处管理员财务处管理员主角1图4:子系统功能用例图主用例描述如下:(1)预检信息给前来报到的新生进行报到、核对并及时修改学生个人的基本信息；自动生成报到号，通过报到号为学生办理以下环节的手续；查看未报到和已报到的学生人数及基本信息。(2)缴费管理给前来缴费的学生进行缴费情况登记；查看未缴费和已缴费的学生人数及

12、其个人基本信息;学工处管理员查看学生的缴费记录；财务处还有权设置学院内各专业的应缴金额和代收费用。（3）宿舍管理给学生分配宿舍；查看未分配宿舍的学生人数、基本信息和已分配宿舍的学生人数、基本信 息和宿舍号；可查寻学院宿舍的住宿情况。（4）户口转移新生可按需求自主选择是否要办理户口转移，需要者办理户口转移相关手续，并进行登记。（5）领取一通已完成缴费的新生可到现代技术教育中心领取一卡通，并登记领取情况。（6）体检新生需到校医院进行体检，并登记体检信息。a）预检信息用例详细信息如图:用例名称预检信息用例描述给前来报到的新生进行报到、核对并及时修改学生个人的基 本信息；自动生成报到号，并统计分类执仃

13、者新生、学院报到处管理员条件前置新生录取通知书编号后置预检完成之后，生成新生个人基本信息表基本流程1）给前来报到的新生进行报到、核对并及时修改学生个人的 基本信息2）自动生成录取编号，通过报到号为学生办理以下环节的手 续查看未报到和已报到的学生人数及基本信息备注无预检信息活动图，如图以下:确认新生的缴费情况，并登记和录入新生的基本信息；对于未缴费的新生可以提供几种缴 费的方式：银行缴费、现场缴费或申请贷款。用例名称缴费管理用例描述缴费登记；统计已缴费人数执仃者新生、财务处管理员条件前置新生已经登录系统，并且已经办理报到后置记录每个学生的缴费登记；统计缴费的人数基本流程1通过点击缴费按钮进行查询

14、是否已缴费情况登记2、对于已缴费的新生可以不用通过此过程； 未缴费的新生应该进行此项办理统计人数并录入备注无新生图6:缴费管理用例图新生财务处7缴纳学费缴费管理系统缴费信息数据表13信息已确认14更新数据库2查询缴费信息3调用缴费信息数据表6反馈缴费信息5反馈缴费信息L/4反馈缴费信息ftt1提交缴费申请及录取通知书编号弋U0返回缴费信息11信息已确认?9返回缴费信息|8登记缴费信息12信息已确认图7:缴费管理顺序图C）宿舍分配分配宿舍给学生，并统计人数和录入学生基本信息，便于学生查询是否已分配宿舍、宿舍号码和宿舍人员名单。用例名称宿舍分配用例描述分配宿舍给新生，查询学院宿舍的住宿情况执仃者宿

15、管部条件前置宿管部工作人员登入系统，新生已缴纳学费后置记录已分配和未分配学生人数、基本信息，并录入住宿人员 名单基本流程1、宿管部将新生宿舍分配情况反馈给新生2、新生根据分配情况办理入住手续，同时登记入住信息3、查询学院宿舍的住宿情况，生成已入住宿新生的名单备注无宿舍分配活动图:图&宿舍管理用例图d）户口迁移新生根据自己的需要办理户籍迁移，管理员查询并统计已办理和未办理新生人数和基本信 息。用例名称户籍迁移用例描述办理户籍迁移执仃者学工处管理员条件前置学生已经登录系统，并需要办理户口迁移后置记录已办理和未办理的学生人数以及基本信息基本流程1、给要办理迁移户口的学生办理户籍迁移登记手续2、查看已

16、办理户籍迁移和未办理的学生人数和基本信息备注无图10 :户口迁移用例图乳於ill til口辻略i期和料乩花吗申坟通il图11：户口迁移顺序图e) 一-通办理新生入校必须要的一卡通办理程序， 学院给每个新生办理一卡通，对于已经领用一卡通的学 生，要进行登记处理生并以生成表格的形式， 给予新生进行查询，学院还要进行统计和登记。用例名称一卡通办理用例描述一卡通领用登记，并统计人数和基本信息执仃者现代技术教育中心条件前置新生已缴纳学费后置发放一卡通，并登记、统计人数和新生的基本信息确认基本流程1、给新生办理学院通用的一卡通领用情况登记2、查看未办理一通和已办理的学生人数和基本信息备注无忖通办理的用例图

17、、活动图:新生图12 :一卡通管理用例图图13: 一通办理活动图f）体检管理A新生修改体检信息系统管理是管理系统的安全而设计的，该系统采用b/s设计模式，故只有合法用户才可用例名称体检用例描述新生注册后需到校医院处进行体检，并记录体检信息执仃者校医院管理员条件前置新生已缴纳学费后置体检完成后，校医院管理员记录新生体检结果基本流程1、新生凭录取通知书到校医院参加体检2、新生体检完成后，校医院管理员对新生体检结果进行登记备注无体检管理用例图如下图所示:查询体检信息添加体检信息A校医院管理员删除体检信息图14 :体检管理用例图32122系统管理以使用系统，考虑到系统使用的人员很多，所以系统提供用户注

18、册与密码修改功能， 注册需 要在进入系统后由系统管理员分配， 而不像一般网页注册那样直接填数据， 修改密码则是在各种进入系统后提交新数据于系统，系统进行处理图15:系统管理用例图系统管理员用户信息新纪录用户信息图16:系统管理数据流图322硬件系统的需求服务器：操作系统：Microsoft Win dows 2000 ServerCPU： P4处理器内存：512M客户端:操作系统：全系列WINDOWSCPU: 1G处理器内存： 128M 浏览器： IE5.0 以上3.2.3 软件系统的需求说明对软件系统的需求。操作系统： Windows 2000 或以上版本数据库： MySQL 开发工具包：

19、JDK Version 1.6Web 服务器： Tomcat浏览器： IE5.0 及以上3.2.4 接口需求说明硬件系统和软件系统之间的接口。3.3 系统能力需求本条应分条详细描述与系统每一能力相关联的需求。 “能力 ”被定义为一组相关的需求。 可以用 “功能”、“性能”、“主题”、“目标”或其他适合用来表示需求的词来替代 “能力”。3.3.1 界面需求页面内容主题突出，美观简洁 导航结构明确，易于用户理解使用 页面大小适中，能用各种浏览器以不同分辨率浏览，页面风格统一3.3.2 响应时间需求 无论是客户端还是管理端，当用户登录，进行任何操作的时候，系统应该及时地进行反 应，反应的时间在 5

20、秒以内。系统应能检测出各种非正常情况，如与设备的通信中断，无法 连接数据库服务器等，以避免出现长时间等待甚至无响应。3.3.3 可靠性需求系统应保证在开学期间 7*24 小时不停顿运行，保证 50人可以同时在浏览器中访问并登录 系统，此时系统能正常运行，显示无误。3.3.4 可扩展性需求系统又能够能够体现扩展性需求，以适应将来功能的扩充。3.3.5 系统安全性需求系统有严格的权限管理功能，各种模块须有相应的权限方能进入。系统能防止各类误操 作造成的数据丢失，破坏。防止用户非法获取网页及内容。3.4 系统外部接口需求本条应分条描述关于系统外部接口的需求 （如有的话 ）。本条可引用一个或多个接口需

21、求规 格说明（IRS）或包含这些需求的其他文档。3.4.1接口标识和接口图本条应标识所需的系统外部接口。 （若适用 ）每个接口标识应包括项目唯一标识符， 并应用 名称、序号、版本和引用文件指明接口的实体 （系统、配置项和用户等 ）。该标识应说明哪些实 体具有固定的接口特性 （因而要对这些接口实体强加接口需求 ），哪些实体正被开发或修改 （从 而接口需求已被施加于它们 ）。可用一个或多个接口图表来描述这些接口。3.4.2 用户接口A、采用Windows的通用图形界面，用户友好。B、界面有一致性，界面规范遵循 Windows软件界面饿规范C 、提供错误处理。D 、提供信息提示，用多种信息提示当前用

22、户的状态、界面。E 、提供方便的联机帮助。F 、遵循国家关于计算机方面词汇的标准，用词正确、准确、无歧义。G 、本产品的用户一般需要通过终端进行操作， 进入主界面后点击相应的窗口， 分别进入 相 对应的界面（如、输入界面、输出界面） 。用户对程序的维护，最好要有备份。3.4.3（接口的项目唯一标识符 ）本条 （ 从 3.4.2 开始 ） 应通过项目唯一标识符标识系统的外部接口，简单地标识接口实体，根据需要可 分条描述为实现该接口而强加于系统的需求。该接口所涉及的其他实体的接口特性应以假设、或“当（ 未提到实体）这样做时，系统将”的形式描述，而不描述为其他实体的需求。本条可引用其他文档（如：数据

23、字典、通信协议标准和用户接口标准 ）代替在此所描述的信息。 （若适用 ）需求应包括下列内容，它们以 任何适合于需求的顺序提供，并从接口实体的角度说明这些特性的区别（如对数据元素的大小、频率或其他特性的不同期望 ）：a. 系统必须分配给接口的优先级别；b. 要实现的接口的类型的需求 （ 如：实时数据传送、数据的存储和检索等 ） ；c. 系统必须提供、存储、发送、访问、接收的单个数据元素的特性，如：1）名称 / 标识符；a）项目唯一标识符；b）非技术 （自然语言 ） 名称；c）标准数据元素名称；d）技术名称 （ 如代码或数据库中的变量或字段名称 ） ；e）缩写名或同义名；2）数据类型 （ 字母数字

24、和整数等 ） ；3）大小和格式 （ 如：字符串的长度和标点符号 ） ；4）计量单位 （如：米、元、秒 ） ；5）范围或可能值的枚举 （如： 099） ；6) 准确度 ( 正确程度 ) 和精度 ( 有效数字位数 ) ；7) 优先级别、时序、频率、容量、序列和其他的约束条件，如：数据元素是否可被更新、业务规则 是否适用；8) 保密性和私密性的约束；9) 来源 ( 设置 / 发送实体 ) 和接收者 ( 使用 / 接收实体 ) ；d. 系统必须提供、存储、发送、访问和接收的数据元素集合体( 记录、消息、文件、数组、显示和报表等 ) 的特性，如：1) 名称 / 标识符；a) 项目唯一标识符；b) 非技术

25、 (自然语言 ) 名称；c) 技术名称 ( 如代码或数据库的记录或数据结构 ) ；d) 缩写名或同义名；2) 数据元素集合体中的数据元素及其结构 (编号、次序和分组 ) ；3) 媒体 (如盘 )和媒体中数据元素 / 数据元素集合体的结构；4) 显示和其他输出的视听特性 ( 如：颜色、布局、字体、图标和其他显示元素、蜂鸣声和亮度等) ；5) 数抿元素集合体之间的关系。如排序 / 访问特性；6) 优先级别、时序、频率、容量、序列和其他的约束条件，如：数据元素集合体是否可被修改、业 务规则是否适用；7) 保密性和私密性约束；8) 来源 ( 设置 / 发送实体 ) 和接收者 ( 使用 / 接收实体 )

26、 ；e. 系统必须规定接口使用的通信方法所要求的特性。如：1) 项目唯一标识符；2) 通信链接 / 带宽 / 频率 / 媒体及其特性；3) 消息格式化；4) 流控制 ( 如：序列编号和缓冲区分配 ) ；5) 数据传送速率，周期性 / 非周期性，传输间隔；6) 路由、寻址和命名约定；7) 传输服务，包括：优先级别和等级；8) 安全性 / 保密性 / 私密性方面的考虑，如：加密、用户鉴别、隔离和审核等；f. 系统必须规定接口使用的协议所要求的特性，如：1) 项目唯一标识符；2) 协议的优先级别 / 层次；3) 组，包括：分段和重组、路由和寻址；4) 合法性检查、错误控制和恢复过程；5) 同步，包括

27、：连接的建立、保持和终止；6) 状态、标识、任何其他的报告特征；g. 其他所需的特性，如：接口实体的物理兼容性 ( 尺寸、公差、负荷、电压和接插件兼容性等)。3.5 系统内部接口需求本条应指明系统内部接口的需求。如果所有内部接口留到设计时或在系统成分的需求规格说明中规 定，那么必须如实说明。如果实施这样的需求，则可考虑本文档的3.4 列出的主题。3.6 系统内部数据需求本条应指明分配给系统内部数据的需求 （若有 ） ，包括对系统中数据库和数据文件的需求。如果所有有 关内部数据的决策都留待设计时或留待系统部件的需求规格说明中给出，则需在此如实说明。如果要强加 这种需求，则可考虑在本文档的 3.4

28、.x.c 和 3.4.x.d 列出的主题。系统数据描述：A）学生信息：录取通知书号码 +身份证号 +姓名+性别+家庭地址 +联系方式 +班级编号B）寝室信息：房间号 +档次 +收费标准C）档案信息：录取通知书号 +办理户口转移信息 +寝室代码 +学杂费缴纳情况D）管理人员信息：工作人员编号 +工作人员姓名 +身份证号 +登陆密码。E）辅导员信息：辅导员编号 +辅导员姓名 +联系方式D） 班级信息：班级编号 +班级名称（1）动态数据 学生信息表：录取通知书号，姓名，性别，班级。辅导员姓名，辅导员联系方式，寝室 号档案缴纳信息表：学生姓名，录取通知书编号，组织关系缴纳情况，高中档案缴纳情况， 学杂

29、费缴纳情况。（2）数据库描述本软件采用 SQL SERVER 200专5 用数据库接口。3.7 性能需求（ 若有 ）本条应指明要求系统提供的、与安装有关的数据（如：现场的经纬度 ） 和要求系统使用的、根据运行需要可能变化的运行参数 （如：表示与运行有关的目标常量或数据记录的参数） 。为了保证系统能够长期、安全、稳定、可靠、高效地运行，新生报到管理系统应该满足以下 性能需求：（1）系统处理的准确性和及时性： 系统处理的准确性和及时性是系统的必要性能。 查询时应保证查全率， 所有相应域包含 查询关键字的记录都应能查到。在系统实际和开发过程中，要充分考虑系统当前和将来可能 承受的工作量，是系统的处理

30、能力和相应时间能够满足信息处理的需求。相应时间，更新处 理时间都比较迅速，完全满足用户要求。一般操作的相应时间应在3-5S 内，对数据的导入、到处、软磁盘和打印机的操作也应在可接受的时间内完成。（2）系统的开放性和系统的可扩充性： 系统在开发过程中，应该充分考虑以后的可扩充性。可扩充系统可以通过简单地加入和 减少系统的模块，配置系统硬件。通过软件的修补、替换，完成系统的升级和更新换代。（3）系统的易用性和易维护性：系统是直接面对使用人员的， 而使用人员往往在对计算机并不非常熟悉。 这就要求系统 能够提供良好的用户接口，易用的人机交互见面。要实现这一点，就要求系统应该尽量使用 用户熟悉的过程。系

31、统中涉及到的数据是学校新生管理的相当重要的信息， 系统要提供方便的手段供系统 管理员进行数据的备份、日常安全管理、系统以外崩溃时数据的恢复等工作。（4）系统的标准性 系统在设计、开发、使用过程中，要涉及很多计算机硬件、软件。所有这些都要符合主 流国际、国家和行业标准。例如，在开发中使用的操作系统、网络系统、开发工具都必须符合通用标准3.8 操作需求说明本系统在常规操作、特殊操作以及初始化操作和恢复操作等方面的要求。灵活性说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：a 操作方式上的变化；b 运行环境的变化；c 同其他软件的接口的变化；d 精度和有效时限的变

32、化；e 计划的变化或改进。 对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。输人输出要求 解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须 标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形 或显示报告的描述。数据管理能力要求 说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储 要求作出估算。3.9 可使用性、可维护性、可移植性、可靠性和安全性需求（1） 正确性 要求发布的软件达到用户的预期目标，运行时基本无错误。（2） 可靠性 在正常条件下，应该不出故障。（3）效率对于浏览、查询、增加、删除、更新和密码设置等一般操作，要求及时响应，在 3-5S 内 （ 4） 完整性要求在发生意外时，保证数据不丢失。（ 5） 易用性 软件界面符合当前流行的习惯，尽量为用户的使用提供方便。（6）可维护性 要求软件运行发现错误时，能够快速、准确地对其定位、诊断和修改