教务管理系统软件需求分析样本.doc

资料内容仅供您学习参考，如有不当之处，请联系改正或者删除。

软件需求分析报告
教务管理系统

学生姓名 __ __
学 号
专业班级
院 ( 系)
指导教师
完成时间
成 绩

前 言

项目小组分工:
需求分析、 文档的整理及后期的功能测试。
教务管理系统的建模实现。

伴随着高校信息化建设的日益完善, 高等学校的教务管理系统在高校管理中越来越受到老师和学生的青睐。高等学校的教学管理系统功能全面、 操作简单快捷, 能够为学生和老师建立电子档案, 而且便于实时修改、 保存和查看, 实现了无纸化存档, 为学校节省了大量的资金和空间。学生能够经过教务管理系统方便快捷地查询自己的个人信息, 进行网上查询课表、 成绩以及报考的事宜。因此结合现有教务系统的优点, 制作此教务管理系统。
目 录

一、 项当前景文档 3
1. 业务需求 3
1.1 业务背景 3
1.2 业务目标和成功条件 4
1.2.1 业务目标( Business Objective, BO) 4
1.2.2 业务成功条件( Success Crite, SC) 4
1.3 业务风险( Risk, RI) 4
2. 解决方案的背景 4
2.1 前景陈述 4
2.2 主要的系统特征( Feature) 5
2.3 假设( Assumption) 和依赖(Dependency)条件 5
3. 项目范围和限制 5
3.1 初始和后继版本的范围 5
3.2 限制和排除条件 6
4. 业务环境 6
4.1涉众档案 6
4.2项目的优先级 7
4.3运行环境( Operating Environment OE) 8
二、 软件需求规格说明书 8
1. 引言 8
1.1概述 8
1.2背景 9
1.3定义 9
1.4参考资料 9
2. 任务概述 9
2.1目标 9
2.2运行环境( Operating Environment, OE) 9
2.3假定( Assumption) 和约束( Constraint) 10
3. 需求规定 10
3.1. 对功能的规定 10
3.1.1.用户需求 10
3.1.2.系统需求 20
3.2. 非功能性需求 31
性能需求( Performance) 31
安全设施需求( SAfety) 32
安全性需求( Security) 32
软件质量属性 32
3.3. 外部接口需求 32
用户界面( User Interfaces, UI) 32
硬件接口( Hardware Interfaces, HI) 32
软件接口( Software Interfaces, SI) 32
通信接口( Communications Interfaces, CI) 32

一、 项当前景文档
1. 业务需求
1.1 业务背景
伴随着高校信息化建设的日益完善, 高等学校的教务管理系统在高校管理中越来越受到老师和学生的青睐。高等学校的教学管理系统功能全面、 操作简单快捷, 能够为学生和老师建立电子档案, 而且便于实时修改、 保存和查看, 实现了无纸化存档, 为学校节省了大量的资金和空间。经过高等学校的教务管理系统, 还能够实现学生选课、 报名考试、 查询成绩和学分。
1.2 业务目标和成功条件
1.2.1 业务目标( Business Objective, BO)
根据学校对教务管理系统的要求, 本系统需要实现以下目标:
BO-1 操作简单方便, 界面简洁大方
BO-2方便、 快捷的信息管理
BO-3简单、 实用的考试和成绩管理
BO-4简单、 实用的网上报名考试需求
BO-5系统运行稳定、 安全可靠
1.2.2 业务成功条件( Success Crite, SC)
SC-1 当前经过网上解决学生查课、 查询成绩和网上报名考试的需要, 据初步调查, 在郑州轻工业学院内需要教务管理系统的师生占到100%:
SC-2 在初始版本发布两个月内, 教师对系统满意度提升0.3, 而且逐渐增加。
SC-3 在初始版本发布后的六个月内, 学生对系统的满意度提升0.5, 而且逐渐增加。
1.3 业务风险( Risk, RI)
RI-1学校在校学生很少使用该系统, 减少了对系统开发的投资回报。 ( 可能性 0.1, 影响9)
RI-2因为使用该系统增大了老师工作量, 导致老师更多的不满, 并可能会减少她们对这个系统的使用。 ( 可能性0.3, 影响6)
2. 解决方案的背景
2.1 前景陈述
高等学校的教务管理系统能够使学生和老师更加便利地经过网络查看自己的课程信息、 考试成绩以及报名考试, 从而节省时间。
产品名称: 高等学校的教务管理系统
产品类别: 教务管理
目标客户: 高校人群
需求或机会的声明: 信息化发达, 对网络的依赖增加
新产品的优势: 针对在校学生的需求对进行设计, 提高学生教师的工作效率, 新系统相比现有产品稳定流畅, 有更好的抗压性。
2.2 主要的系统特征( Feature)
FE-1 教务处录入与生成新学期课程表
FE-2 学生能够查询自己的课表
FE-3 学生能够进行网上报名考试
FE-4 学生查询自己的考试成绩
FE-5 教师查询选课学生信息
FE-6 教师录入学生考试成绩
FE-7 教务处能够生成成绩统计表
2.3 假设( Assumption) 和依赖(Dependency)条件
AS-1:学生和教师只有经过学号和密码才可查询自己的成绩以及课程信息, 从而防止泄露学生的某些信息, 并及时获取自己需要的信息。
DE-1:该教学管理系统需要随着学生和教师以及课程调动进行相应的信息更新。
3. 项目范围和限制
3.1 初始和后继版本的范围
特性
版本1
版本2
版本3
FE-1
全部实现

FE-2
能够实现
能够实现
全部实现
FE-3
提交信息早的优先
全部实现

FE-4
能够实现
全部实现

FE-5
不实现
不实现
全部实现
FE-6
不实现
能够实现

FE-7
不实现
不实现
全部实现

3.2 限制和排除条件
学校不能满足少部分学生的需求, 它只能尽自己最大的能力去满足, 因此”教务管理系统”只能在整体上尽可能的方便学校教学管理, 满足用户的需求, 而不是绝正确满足。
该”教务管理系统”是结合本高校的具体情况提出的, 仅仅是对本高校的选课管理比较有效, 不具有通用性。
4. 业务环境
4.1涉众档案
涉众
主要价值
态度
主要兴趣
约束条件
学校管理员
无纸化办公, 减少工作量
强烈要求完成版本2, 尽量完成版本3
使该系统所节约的费用必须超过开发此系统所需的费用
无
在校学生

方便查询个人信息, 节约了大量时间
担心访问人数过多系统瘫痪
使用网络解决选课难的问题
学生需要有能够连接校园网络的计算机
教师
能够在家中就能够完成成绩录入等工作, 减少了工作量
积极支持新系统, 希望学校大力推广
能够提高自己的薪资
需要访问学校教务网站
4.2项目的优先级
因素
约束
自由度
特性
安排第1版本实现的特性必须完全可操作

质量
必须经过95%的用户验收测试; 必须经过全部的安全性测试; 所有的安全事务都必须遵守公司的安全标准

进度
12月31号前必须完成第1版本
计划 2月28号前完成的第2版本, 在不包括责任人评审的情况下, 最多可延期3个星期
人员
项目团队规模包括一名半日工作的项目经理, 三名开发人员, 一名半日工作的测试人员
如果有必要, 还能够另外增加或减少一名开发人员和一名半日工作的测试人员
成本

在不包括责任人评审的情况下, 财政预算最多可超支20%
4.3运行环境( Operating Environment OE)
OE-1:”教务管理系统”的操作将经过Web浏览器来完成: 基于IE内核的浏览器, 基于chrome内核的浏览器。
OE-2:”教务管理系统”将运行在一个服务器中, 该服务器运行当前公司批准的Red Hat Linux版本和Aachen HTTP Server。
OE-3:”教务管理系统”将允许用户经过学校内联网来访问, 如果用户被授权在学校的外部经过VPN来访问, 那么, 用户也能够在家经过Internet来访问该系统。

二、 软件需求规格说明书
1. 引言
1.1概述
文档目的: 对制作的教务管理系统进行说明。
目标对象: 供高校教师和学生更方便快捷地进行教务日常管理。
文档内容: 该软件需求规格说明描述了”教务管理系统”1.0版本的软件功能性需求和非功能性需求。同时还描述了用户及管理员在系统的工作中所参与的角色以及拥有的权限, 从而使开发团队能够明确地了解所开发的”教务管理系统”的各个方面, 帮助她们在实际的开发过程中准确地完成所开发的模块, 以达到方便快捷地教学, 更好满足客户需求。
文档的组织结构: 该文档由文档介绍( 文档概述、 文档背景、 文档定义及所选用的参考资料) 、 系统介绍( 文档目标、 系统运行环境、 系统条件和约束) 、 需求规定( 对系统功能的规定、 非功能性需求、 外部接口需求) 等方面对文档及教务管理系统进行阐述, 经过此文档透彻而全面的对该系统进行说明和分析。
该文档计划由实现和验证正确功能的项目团队成员来使用, 除非在其它地方另有说明, 这里所指定的所有需求都具有高优先级, 而且都要在版本1.0中加以实现。
1.2背景
伴随着高校信息化建设的日益完善, 高等学校的教务管理系统在高校管理中越来越受到老师和学生的青睐。高等学校的教学管理系统功能全面、 操作简单快捷, 能够为学生和老师建立电子档案, 而且便于实时修改、 保存和查看, 实现了无纸化存档, 为学校节省了大量的资金和空间。经过高等学校的教务管理系统, 还能够实现学生查课表、 报名考试、 查询成绩和学分。
1.3定义
学号: 学生在学校教务管理系统中的编号, 每位学生有且只有一个学号, 学号用来登陆教务系统。
课程考试: 学生按照学校教务处规划所必修课程的结课考试, 每位学生必须参加课程考试。
等级考试: 学生在教务处规划课程以外自选报考的考试, 学生可自行选择报考项目来获取相应的等级证书, 也可不参加等级考试。
1.4参考资料
构造教务管理系统及写作此文档时的参考资料有: 软件需求工程教材、 老师讲课课件等资料。
2. 任务概述
2.1目标
根据学校对教务管理系统的要求, 本系统需要实现以下目标:
BO-1 操作简单方便, 界面简洁大方
BO-2方便、 快捷的信息管理
BO-3简单、 实用的考试和成绩管理
BO-4简单、 实用的网上报名考试需求
BO-5系统运行稳定、 安全可靠
2.2运行环境( Operating Environment, OE)
OE-1:”教务管理系统”的操作将经过Web浏览器来完成: 基于IE内核的浏览器, 基于chrome内核的浏览器。
OE-2:”教务管理系统”将运行在一个服务器中, 该服务器运行当前公司批准的Red Hat Linux版本和Aachen HTTP Server。
OE-3:”教务管理系统”将允许用户经过学校内联网来访问, 如果用户被授权在学校的外部经过VPN来访问, 那么, 用户也能够在家经过Internet来访问该系统。
2.3假定( Assumption) 和约束( Constraint)
AS-1: 学生和教师只有经过学号和密码才可查询自己的成绩以及课程信息, 从而防止泄露学生的某些信息, 并及时获取自己需要的信息。
AS-2: 该教务管理系统在UML系统中制作出来。
Co-1: 该教务管理系统需要随着学生和教师以及课程调动进行相应的信息更新。
Co-2: 该教务管理系统使用ASP.NET开发。
3. 需求规定
3.1. 对功能的规定
3.1.1. 用户需求
3.1.1.1组织机构和角色

角色视图:

角色说明:
角色名
说明
教务处
接收教师提交课程的信息, 分发学生报名考试的准考证, 进行全面的管理
教师
授课, 向教务处提交自己的课程信息, 将学生考试成绩输入系统
学生
能够在系统查询自己的课程表, 报名考试, 并查询考试成绩
(1) 教师参与业务

说明: 教师能够查看学生的基本信息, 而且在考试结束后将学生的考试成绩录入教务管理系统中, 如果录入出错能够修改学生的成绩。
(2) 教务处参与业务

说明: 教务处是学校进行正常教学活动的管理机构, 能够对学生学号管理, 制定新学期的课程表, 发放学生考试的准考证并公布学生的考试成绩。
(3) 学生参与业务

说明: 学生能够在教务管理系统中查询自己的新学期课程表, 并进行网上报名等级考试, 能够查询自己的考试成绩。
3.1.1.2业务概览
(1) 查询成绩业务

成绩查询业务说明: 考试结束后, 由教师将学生的考试成绩录入教务管理系统, 经教务处整理后, 学生能够在教务管理系统中查询自己的考试成绩。
(2) 等级考试报名业务

等级考试报名业务说明: 在等级考试报名时间内, 学生能够在教务管理系统中进行网上报名考试, 由教务处发放考试需要的准考证。
(3) 申请学号业务

申请学号业务说明: 第一次登陆教务管理系统需要申请学号, 申请后不可更改, 将是今后登陆教务管理系统的凭证。第一次登陆时学生发出申请学号请求, 由教务处审批后分配对应学生的学号。
(4) 教务管理业务

3.1.1.3业务场景
(1) 申请学号业务场景

业务场景说明: 学生向教务处发出申请学号请求, 教务处审批后为学生分配学号。
(2) 第一次查询课程表业务场景

业务场景说明: 学期开始时由教务处生成新学期课程表, 学生第一次登陆需要申请学号, 而且之后一直使用学号登陆教务系统查询课程表。
(3) 查询课程表业务场景

业务场景说明: 学期开始时由教务处生成新学期课程表, 学生使用学号登陆教务系统查询课程表。
(4) 查询成绩业务场景

业务场景说明:
查询成绩分为”查询课程成绩”和 ”查询等级考试成绩”:
1) 查询课程成绩: 考试结束后由教师在教务管理系统录入学生考试成绩, 学生登陆教务系统即可查询自己对应的课程成绩。
2) 查询等级考试成绩: 在等级考试结束后, 由教务处在教务系统公布等级考试成绩, 学生能够登录教务管理系统查询相应的等级考试成绩。

3.1.2. 系统需求
3.1.2.1 概览

3.1.2.2系统需求规定
(1) 等级考试报名
Ø 用例规约
用例名称
等级考试报名
实现名称
Baokao
用例描述
学生经过此用例报名等级考试
参与者
学生 教务处
前置条件
1. 等级考试报名开始
2. 等级考试报名未结束
后置条件
1. 记录报考信息
2. 教务处确认报考信息并发准考证
主事件流
1.学生用学号登录系统, 浏览器显示我的基本信息界面
2.学生选择等级考试报名, 浏览器显示报考选择界面
3.学生选择报考项目
4.学生可单选或多选报考项目, 并确认报考。
5.浏览器显示确认报考项目清单。
6.选择选择确认报考, 浏览器显示报考项目及考试时间。
7.教务处打印报考信息并分发准考证。用例结束。
备选事件流

1.a学号错误
1.拒绝登录, 用例结束
2.a当前没有可报考项目
1.浏览器显示”当前非报考时间”
4.a学生选择查看已报考项目
1.计算机执行5;
4.b用户选择放弃
1.计算机执行4
业务规则
所报考项目的考试时间不能发生冲突
涉及的业务实体
Be_学号, Be_报考项目, Be_准考证
非功能性需求
支持多种语言显示( 有留学生)
Ø 用例场景分析
（1） 报考业务场景

业务场景说明: 学生报考时登录系统需要验证学号, 验证成功才可报考, 提交报考信息后由教务处记录并分发准考证。
Ø 业务实体分析

业务实体说明: 一个学生有一个学号, 一个学号能够报考多个项目, 而且每个考试项目有一个对应的准考证。
(2) 查询成绩
Ø 用例规约
用例名称
查询成绩
实现名称
Chachengji
用例描述
学生经过此用例查询课程考试成绩和等级考试成绩
参与者
学生 教务处 教师
前置条件
1.课程考试结束
2.等级考试结束
后置条件
查询结束, 注销登陆
主事件流
1.学生用学号登录系统, 浏览器显示我的基本信息界面
2.学生选择成绩查询, 浏览器显示查询项目选择界面
3.学生选择查询课程考试成绩或者等级考试成绩
4.浏览器显示查询项目成绩数据。
5.查询完毕, 学生注销登陆。用例结束。
备选事件流

1.a学号错误
1.拒绝登录, 用例结束
2.a当前没有可查询成绩的项目
1.浏览器显示”未到查询成绩的时间”
4.a学生选择继续查询成绩
1.浏览器执行2;
4.b用户选择放弃
1.计算机执行5
业务规则
教师或教务处必须将成绩公布后才可查询
涉及的业务实体
Be_学号, Be_课程考试成绩, Be_等级考试成绩
非功能性需求
支持多种语言显示( 有留学生)

Ø 用例场景分析

业务场景说明: 学生经过学号登陆系统, 才能够查询成绩。
Ø 业务实体分析

业务实体说明 : 一位学生对应一个学号, 一个学号能够对应多个课程考试成绩或等级考试成绩。
(3) 查课表
Ø 用例规约
用例名称
查课表
实现名称
Chakebiao
用例描述
学生经过此用例查询自己的课程表
参与者
学生 教务处
前置条件
新学期开始
后置条件
查询结束, 注销登陆
主事件流
1.学生用学号登录系统, 浏览器显示我的基本信息界面
2.学生选择查询课程表, 浏览器显示查询学期列表
3.学生选择查询哪一学期的课程表
4.浏览器显示查询学期的课程表
5.查询完毕, 学生注销登陆。用例结束。
备选事件流

1.a学号错误
1.拒绝登录, 用例结束
3.a当前学期教务处没有公布课程表
1.浏览器显示”还未公布课程表”
4.a学生选择查询其它学期的课表
1.浏览器执行2;
4.b用户选择放弃
1.计算机执行5
业务规则
教务处必须将课程表发布后才可查询
涉及的业务实体
Be_学号, Be_课程表, Be_教务处
非功能性需求
支持多种语言显示( 有留学生)

Ø 用例场景分析

业务场景说明: 新学期开始, 教务处公布新学期课程表, 学生必须经过学号登陆教务系统才可查询自己的课程表。
Ø 业务实体分析
业务实体说明 : 一位学生对应一个学号, 每个学号对应一个课程表, 教务处公布每个班级的课程表。
3.1.2.3数据分析
概览

Ø 学号
实体名称
Be_学号
实体描述
每个学生必须有且只有一个一个学号, 是学生的身份凭证
属性名称
类型
精度
说明(属性的业务含义及业务规则)
姓名
字符
50
学号对应的学生姓名
学号
字符
12
学校标识符( 3位) +院系标识符( 3位) +班级标识符(3位)+学生序号( 3位)
Ø 课程表
实体名称
Be_课程表
实体描述
学生所上课程的表格
属性名称
类型
精度
说明(属性的业务含义及业务规则)
课程名称
字符
100
学生所学课程的名称
日期
日期
12
周一到周日

Ø 课程考试成绩
实体名称
Be_课程考试成绩
实体描述
学生课程考试对应的成绩
属性名称
类型
精度
说明(属性的业务含义及业务规则)
课程名称
字符
100
学生所学课程的名称
成绩
字符
12
最小值为0, 最大值为100

Ø 准考证
实体名称
Be_准考证
实体描述
学生参加等级考试所需要的凭证
属性名称
类型
精度
说明(属性的业务含义及业务规则)
考试名称
字符
100
学生所报考的考试的名称
日期
日期
12
学生所报考考试的考试时间
姓名
字符
50
学生姓名
准考证号
字符
15
学生参加等级考试的编号

Ø 等级考试成绩
实体名称
Be_等级考试成绩
实体描述
学生等级考试对应的成绩
属性名称
类型
精度
说明(属性的业务含义及业务规则)
考试名称
字符
100
学生所报考考试的名称
成绩
字符
12
成绩根据考试规则而不同

Ø 报考项目
实体名称
Be_报考项目
实体描述
学生报考等级考试的名称
属性名称
类型
精度
说明(属性的业务含义及业务规则)
等级考试名称
字符
100
学生所报考考试的名称
日期
日期
12
学生所报考考试的考试时间

3.2. 非功能性需求
性能需求( Performance)
PE-1: 系统生成的所有Web页面, 经过速率为40KBps的调制解调器在不超过5秒时间内能够全部显示出来。
PE-2: 学生向系统提交信息后, 系统将在3秒内做出相应回应。
安全设施需求( SAfety)
SA-1: 系统必须每天对数据库进行自动备份, 命名格式为”日期+时间”。
安全性需求( Security)
SE-1: 所有涉及功能信息或个人身份信息的项目, 都要采用128位的加密。
SE-2: 除了申请学号之外, 用户必须经过学号登录到”教务管理系统”才能完成所有操作 。
软件质量属性
AVailablity( 可用性) -1: ”教务管理系统”将对全校的学生及教职工可用, 学生在当地时间早晨5点到晚上12点99.9%的时间可用, 当地时间晚上12点到早晨5点则95%的时间可用。
Reliability( 可靠性) -1: 如果在学生进行等级考试报名得到确认或取消之前, 用户和系统的连接中断, 那么学生应该能经过”教务管理系统”恢复不完整的项目清单。
3.3. 外部接口需求
用户界面( User Interfaces, UI)
UI-1: ”教务管理系统”的屏幕画面将遵照公司的Internet应用程序界面标准V2.0版本。
UI-2: 系统对所显示的每个HTML网页都提供链接帮助, 解释如何使用这些网页。
UI-3: Web页面设置简单明了, 布局符合常见习惯。
硬件接口( Hardware Interfaces, HI)
本系统的制作仅用到软件。
软件接口( Software Interfaces, SI)
系统与Mysql数据库软件进行对接存储数据。
通信接口( Communications Interfaces, CI)
CI-1: ”教务管理系统”将向学生发送电子邮件消息, 以提醒近期的考试及课程安排。