用户需求报告.docx
《用户需求报告.docx》由会员分享，可在线阅读，更多相关《用户需求报告.docx（18页珍藏版）》请在冰豆网上搜索。
用户需求报告
需求规格说明书
内蒙古大学计算机学院管理科学与工程
第三组
聂帅、陆娜冯阳邢宇博耿万秋高晋尧王熙王挺张飞
目录
1.概述1
1.1.用户简介1
1.2.项目的目的与目标1
1.3.术语定义1
1.4.参考资料1
1.5.相关文档1
1.6.版本更新信息1
2.目标系统描述1
2.1.组织机构与职责1
2.2.角色定义1
2.3.作业流程（业务模型）1
2.4.单据、账本、报表1
2.4.1.单据1
2.4.2.账本1
2.4.3.报表1
2.5.可能的变化1
3.目标系统功能需求1
3.1.功能需求分析1
3.2.功能需求点列表（功能模型）1
4.目标系统性能需求1
4.1.时间要求1
4.2.空间性能1
4.3.性能需求点列表1
5.目标系统界面与接口需求1
5.1.界面需求1
5.2.接口需求列表1
6.目标系统其他需求1
6.1.安全性1
6.2.可靠性1
6.3.灵活性1
6.4.特殊需求1
7.目标系统假设与约束条件1
1.概述
信息现代化是二十一世纪信息化时代的重要特征，当今社会各行各业都在积极提高自身的信息化水平，因为信息现代化是当今社会的必然趋势，信息化水平越来越成为衡量一个国家、一个企业、一个事业单位现代化水平的重要标志，对它们发展具有重要的作用。
学校作为一个事业单位也必须积极进行信息化，学校进行信息化建设具有得天独厚的优势，一来学校是教书育人、科学研究的场所，本身对信息化的需求非常旺盛；二来学校有一定的信息化基础，在进行信息化过程中无论在人员培训还是在基础设备建设上都会省去不少力气；三来学校有充足的人才技术资源和信息资源，这些资源对信息化具有重要作用。
要想实现学校的信息化第一步就应该进行学校信息的信息化，学校信息管理的主要部分就是对学生信息的管理，因而开发一个学生信息管理系统对学校信息化具有重要的意义。
1.1.用户简介
学生信息管理系统主要是针对学生信息管理的，因而它的主要用户有学生、老师、教务工作者。
学生主要用于查询自身信息，对数据的访问权限比较低，只有查询自身信息的权限，对系统的性能要求不高，主要是信息传输的快速、查询的方便、信息显示的友好美观；老师主要用于学生成绩的录入，对数据访问权限比较高，能够修改特定学生的成绩，对系统的要求主要是信息录入的方便准确；教务工作者主要用于信息的录入、维护、修改、统计等，具有很高的权限，对系统的要求比较高，系统必须安全、录入信息方便、界面友好、操作简单，稳定。
1.2.项目的目的与目标
1.2.1项目目的
开发一套学生管理信息系统，以便于学生信息的管理，提高学校的信息化水平。
为学校信息现代化打基础、做准备。
1.2.2项目目标
（1）学生信息的电子化。
将学生的信息全部采用电子化存储，以实现学校各部门对学生信息的方面共享统一，便于学校的管理；
（2）教学的信息化管理。
学生选课、学生成绩的录入查询、课程的安排，教师教室的分配都由计算机自动完成，提高学校管理的效率；
（3）提高教务、生活等管理的效率，学校各部门对学生信息的共享统一，能够避免很多重复工作，提高管理的效率。
1.3.术语定义
无
1.4.参考资料
[1]学校组织机构说明
[2]学校部门职责说明
[3]教师职责说明
[4]学生管理手册
[5]学生管理章程
1.5.相关文档
（1）功能模块的变更，可能在运行过程中，用户的会有新的需求，所以在开发过程中，一注意系统的可扩展性，以及模块的独立性。
（2）数据信息的变更，随着社会的发展以及系统的需要，可能对学生的信息进行相应的增加，以及有些字段的变更，必须提供一种数据扩展变更的机制。
（3）项目开发过程的变更，可能先前开发流程不能很好地推进项目的进行，要做一些相应的调整。
（4）开发时间人员的变更。
1.6.版本更新信息
表11版本更新记录
版本号
创建者
创建日期
维护者
维护日期
维护纪要
V1.0
第三组
2011-12
第三组
无
无
2.目标系统描述
2.1.组织机构与职责
2.2.角色定义
表21角色定义
编号
角色
所在部门
职责
相关的业务
学生
普通用户
各学院
查询信息、选课
查询信息、选课
老师
管理员
各学院
录入学生成绩
录入、修改成绩
学院教务工作人员
高级管理员
学院教务处
学生信息采集维护
学生信息的录入、维护、教学安排
学校教务工作人员
高级管理员
学校总教务处
全校学生信息维护，各部门学生信息维护
学生信息的修改、删除、转移等
2.3.作业流程（业务模型）
2.4.单据、账本、报表
本系统使用的单据主要有录取通知书复印件、学生身份证复印件、学生成绩。
这些单据对于系统需求分析具有重要的作用，能够帮助我们在开发系统时考虑清楚系统各板块的连接和组织。
从而更好的设计好系统。
2.4.1.单据
因为单据上的数据是原始数据，所以一种单据一般对应一个实体，一个实体一般对应一张基本表。
单据的格式可用表格描述，如表所示。
单据的描述格式
单据名称
录取通知书
用途
学生录取信息合适
使用单位
教务处
制作单位
学校招生办
频率
1
高峰时数据流量
1
各数据项的详细说明
属性中文名
属性英文名
属性类型、长度、精度
属性的值域
主键/外键
通知书号
AdmitNO
char型、8、无
无
主键
身份证号
IDCard
char型、18、无
无
外键
高考分数
EntranceGrade
samllint
单据的描述格式
单据名称
成绩单
用途
学生成绩证明
使用单位
教务处
制作单位
学院教务处
频率
1
高峰时数据流量
1
各数据项的详细说明
属性中文名
属性英文名
属性类型、长度、精度
属性的值域
主键/外键
学号
Sno
char型、8、无
无
主键
课程号
Cno
char型、3、无
无
主键
成绩
Grade
smallint、4、0
[0,100]
单据的描述格式
单据名称
身份证
用途
核实学生信息
使用单位
教务处
制作单位
公安机关
频率
1
高峰时数据流量
1
各数据项的详细说明
属性中文名
属性英文名
属性类型、长度、精度
属性的值域
主键/外键
身份证号
IDCard
char型、18、无
无
主键
姓名
Sname
varchar、50、无
无
性别
Ssex
char、1、无
｛0，1｝
民族
Snation
char、2、无
出生
Birthday
samlldate
2.5.可能的变化
（1）描述学生的信息可能改变，随着社会的发展，学生的有些属性可能变得比较重要，可能需要把这些属性添加到学生表中，比如学生的QQ号可能会添加到学生表中。
（2）学校组织机构的变化可能会系统相关内容的改变，如学校可能增设学院、系等，这时系统相关部分会发生变化。
（3）信息录入方式的变化，可能学生的信息会存放在卡片中，这时候学生信息的录入就可能发生变化。
3.目标系统功能需求
3.1.功能需求分析
（1）学生：
学生对系统的主要需求是查询信息，学生能够查询自身的基本信息、学院信息、课程信息、授课教师信息、教师使用信息和班级信息。
为方便学生查询，系统必须具有友好清晰的用户界面，信息组织分类应简明清楚，让用户一目了然。
同时查询应简单，尽量减少学生的输入的工作量，尽量用鼠标点击代替用户输入，这样一方面方便了用户，同时也简化了系统的实现。
（2）老师：
老师对系统的主要需求是学生信息录入以及信息查询。
老师需要录入、修改学生成绩，以及对学生基本信息、课程信息、教师信息、学院信息等进行查询。
在系统设计时应着重考虑老师录入信息的需求，应采取措施方便老师对学生信息的录入，而且还应着重考虑如何防止信息的错误录入，尽量减少由于人的原因导致信息录入的错误，同时还应对录入的信息进行检查，提供一种检错机制。
（3）教务处管理员：
教务处工作人员是整个系统的管理员，对系统有比较多的需求，在系统设计时应重点考虑他们对系统的功能需求。
管理员对系统的主要需求是，各种信息的录入、修改、删除，同时还要求对信息的自动化的统计整理。
比如在学生基本信息录入时，录入应方便，有些信息应该是自动化录入，还应该考虑信息录入的核对方便、有一定的检错能力，要有一定的机制防止由于误操作导致信息录入的错误，还比如，系统应该能够自动对学生信息进行整理，方便管理员调出相关信息，如统计学生成绩，按班级对学生进行分类等。
3.2.功能需求点列表（功能模型）
在功能需求分析完成后，要详细列出用户需求功能点列表，提供给后续设计、编程、测试中使用，更是为了用户测试验收中使用。
表31功能需求点列表
编号
功能名称
使用部门
使用岗位
功能描述
输入
系统响应
输出
1
查询
查询信息
查询条件
1s-2s
查询结果
2
修改
教务处
学生管理处
信息更改
修改位置、内容
1s-2s
修改数据库，反馈修改是否成功
3
信息录入
教务处
教务管理处
信息录入
学生、教师、课程等信息录入
比较长
录入信息的显示预览
4
成绩录入
办公室
老师
学生成绩录入
学生成绩
比较长
录入信息的显示预览
5
删除
教务处
教务管理处
删除学生信息
删除内容
1s-2s
反馈删除是否成功
6
统计
教务处
教务管理处
学生成绩统计
学号、班级号
1s-2s
输出成绩统计结果
7
排课
教务处
教务管理处
课程安排
课程、教室
1s-2s
课程表
8
信息导出
教务处
教务管理处
导出经整理过的信息
信息需求
1s-2s
信息汇总表
4.目标系统性能需求
4.1.时间要求
（1）响应时间，如查询的最长等待时间。
要求响应时间应该在大多数用户所能承受的范围内。
一般应小于30S分钟。
（2）更新处理时间，如记账的最长时间。
更新时间不超过60S。
（3）数据的转换和传送时间，如远程数据传输的时间要求。
远程数据传送要求不超过60S
（4）解题时间
解题时间要求不超过15S
4.2.空间性能
（1）支持的终端数。
30000（要求其大或等于全校师生人数，这里假设为30000人）。
（2）支持的并行操作的使用者数。
3000，要求不少于总数的1/10
（3）处理的文件和记录数。
峰值情况处理6000条记录。
（4）表和文件的大小规模（要按可预见的增长，对数据及其分量的存储要求做出估算）。
学校20个学院，一个学院1500名学生，每个学生需要2MB，每年增加20*1500*2=60000MB，约58GB。
（5）处理任务的数量。
要求能同时处理8000个任务。
（6）在正常情况下和峰值工作条件下，在一定时间周期中要处理的数据总数。
峰值情况：
约15000名学生在一天内同时使用系统（如选课时），每个人需要处理2MB的数据，需处理15000*2MB/天=30000M/天，约30GB/天；
正常情况：
1000名用户在一天内同时使用系统，每个人需要处理2MB的数据，需处理1000*2MB/天=2000M/天，约2GB/天；
（7）对输入和输出数据的精度要求
输入要求，用户名（学号）：
8位整数，口令（密码）：
6~14位数，成绩：
0至100整数。
（8）对处理和传输过程中的精度要求。
计算成绩平均值保留一位小数，学分绩点平均值保留两位小数，统计及格率、优秀率、挂科率等保留两位小数。
4.3.性能需求点列表
详细列出用户性能点列表，提供给后续分析、设计、编程、测试中使用，更是为了用户测试验收中使用。
表41性能需求点列表
编号
性能名称
使用部门
使用岗位
性能描述
输入
系统响应
输出
1
响应时间
学校
学生
查询响应时间
查询条件
时间
响应时间
2
负载量
学校
学生
系统同时处理查询能力
多人同时查询
时间
响应时间
3
事务处理
教务处
教务管理
事务处理能力
同时提交多事务
时间
响应时间
4
安全性
教务处
教务管理
系统安全能力
非法入侵
5
恢复能力
教务处
教务管理
系统恢复能力
提交恢复事物
时间
响应时间
6
查错能力
教务处
教务管理
系统查错能力
非法数据
7
稳定性
学校
学生
系统运行稳定性
访问
5.目标系统界面与接口需求
5.1.界面需求
用户界面：
又称人机界面，实现用户与计算机之间得通信，以控制计算机或进行用户和计算机之间得数据传送得系统部件。
5.1.1用户界面设计原则
本系统坚持图形用户界面（GUI）设计原则，界面直观、对用户透明：
用户接触软件后对界面上对应的功能一目了然、不需要多少培训就可以方便使用本应用系统。
在界面设计中应该保持界面的一致性。
一致性既包括使用标准的控件,也指使用相同的信息表现方法,如在字体、标签风格、颜色、术语、显示错误信息等方面确保一致。
应注意在一个窗口内部所有控件的布局和信息组织的艺术性,使得用户界面美观。
在一个窗口中按tab键,移动聚焦的顺序不能杂乱无章,tab的顺序是先从上至下，再从左至右。
一屏中首先应输入的和重要信息的控件在tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
布局力求简洁、有序、易于操作。
对于应用中某些部分的处理流程是固定的，用户必须按照指定的顺序输入操作信息，为了使用户*作得到必要的引用应该使用向导，使用户使用功能时比较轻松明了，但是向导必须用在固定处理流程中，并且处理流程应该不少于3个处理步骤。
5.1.2用户界面设计更改
更改本用户界面设计时应该征得所有开发者的同意，所有开发者应该按更正后的原则修改和设计用户界面。
总之，在开发系统时要时刻注意考虑客户的需求，充分重视客户所提的意见，界面设计要符合使用者的使用习惯，尽量使他们感到使用舒服方便。
5.1.3用户界面设计追加说明
追加本用户界面设计时应该发布给所有开发者，所有开发者应该按追加后的原则修改和设计用户界面。
5.2.接口需求列表
与其他系统的接口，如监控系统、控制系统、银行结算系统、税控系统、财务系统、政府网络系统及其他系统等。
（1）与其他系统的接口，如监控系统、控制系统、银行结算系统、税控系统、财务系统、政府网络系统及其他系统等。
（2）与系统特殊外设的接口，如CT机、磁共振、柜员机（ATM）、IC卡、盘点机等。
（3）与中间件的接口，要列出接口规范、入口参数、出口参数、传输频率等。
应在此列举出所有的外部接口名称、接口标准、规范。
外部接口列表。
表51接口需求点列表
编号
接口名称
接口规范
接口标准
入口参数
出口参数
传输频率
01
LTP
TN91.3
DDR2
32KB
256KB
93MB/SEC
02
SATA
TP9.6
PCIE
18KB
32KB
150MB/SEC
03
PATA
无
AF520C
32KB
128KB
24MB/SEC
04
IDE
TC9.8
AMD
8KB
64KB
48MB/SEC
05
COM
TP91.3
PCII
32KB
64KB
70MB/SEC
06
ATA
无
TP30D
64KB
256KB
133MB/SEC
6.目标系统其他需求
6.1.安全性
6.1.1数据库权限和用户分类
（1）对数据库管理系统正常运行而进行的维护权限
（2）对数据库中的对象和数据的操作权限
（3）用户按其操作权限的大小可分为
<1>数据库系统管理员
<2>数据库对象拥有者
<3>普通用户
6.1.2oracle的安全机制
（1）建立在认证和访问许可机制上的
身份验证
访问权验证
操作权验证
（2）SQLServer登录账户的来源有两种：
<1>Windows授权用户：
来自于Windows的用户或组；
<2>数据库授权用户：
来自于非Windows的用户，我们也将这种用户称为数据库用户。
6.1.3管理oracle登录账户
（1）一类是由oracle自身负责身份验证的登录账户；
（2）另一类是登录到oracle的WindowsNT/2000网络账户，可以是组账户或用户账户。
6.1.4管理数据库用户
数据库用户简介
数据库用户用来指出哪一个人可以访问哪一个数据库。
用户对数据的访问权限以及对数据库对象的所有关系都是通过用户账号来控制的，用户账号总是基于数据库的。
用户账号和登录账号
用户账号只表明该账号通过了NT认证或oracle认证，但不能表明其可以对数据库数据和数据对象进行某种或某些操作，所以一个登录账号总是与一个或多个数据库用户账号（这些账号必须分别存在相异的数据库中）相对应，这样才可以访问数据库。
6.1.5管理权限
（1）对象权限
对象权限是指用户对数据库中的表、视图、存储过程等对象的操作权，如：
对表和视图，可以使用SELECT、INSERT、UPDATE和DELETE权限。
对于表和视图的字段；可以使用SELECT和UPDATE权限。
对于存储过程；可以使用EXECUTE权限。
（2）语句权限
语句权限相当于数据定义语言（DDL）的语句权限，这种权限专指是否允许执行下列语句：
CREATETABLE、CREATEPROCEDURE、CREATEVIEW等与创建数据库对象有关的操作。
（3）隐含权限
隐含权限是指由SQLServer预定义的服务器角色、隐含权限相当于内置权限，而不再需要明确地授予这些权限。
例如，数据库拥有者自动地拥有对数据库进行一切操作的权限。
6.1.6管理角色
具有相同权限的用户就称为角色。
角色分为：
系统预定义的固定角色
用户根据自己的需要定义的用户角色
系统角色又根据其作用范围的不同而被分为：
固定的服务器角色，是为整个服务器设置的
固定的数据库角色，是为具体的数据库设置的。
6.1.7oracle安全性管理的途径
使用视图作为安全机制
使用存储过程作为安全机制
6.2.可靠性
1.概念
1）.可靠性
指数据库在一给定时间间隔内不产生任何失败的概率。
它强调数据库的正确性，要求数据库正确运行，既符合某种规格化要求。
通常用来描述不可修复的系统。
2）.可用性
强调的是当需要访问数据库时，它是可用的。
指在给定的时间点系统可以正常运行的概率。
通常用于描述那些可以修复的系统。
3）.两者关系
通常认为构建可用性的系统比可靠性的系统容易。
两者是统的，可靠性高的系统可用性自然是好的。
两者又是矛盾的，增加错误风险的情况下，可提高可用性;采用太谨慎的策略会降低可用性。
2.平均故障间隔时间
1）指在可以自我修复的系统中相继失败之间的期望时间
通过可靠性函数来计算MTBF=∫0∞R（t）dt
MTBF与系统失败的概率有直接的关系
2）平均修复时间
是指修复一个系统所需要的期望时间，MTTR
它与失败概率有关
指数型失败和修复的概率的系统可用性
A=MTBF/（MTBF+MTTR）
3）可用性系统
5个9（99.999%）常用来描述可用性系统
但是可用性系统要求的成本比较高，具体设计时要综合用户两方面的要求。
3.系统失败的原因
1）系统规范说明（Specification）系统提供的对所有可能的刺激将产生的响应行为必须遵循的说明。
2）故障：
任何偏离规范说明的行为
<1>软故障和硬故障
软故障包括间歇性（intermittent）和瞬变性（transient）故障，通过重启动来修复
硬故障指永久性故障,错误设计等
<2>软件和硬件故障
基本容错方法和技术
4.容错
<1>设计一种使系统识别出可能会发生的错误的方法。
在系统中建立一种机制，使错误在造成系统故障之前就会被检测出来，并能被清除或得到补偿。
<2>错误预防
保证所实现的系统不包含任何错误
错误回避：
保证系统不会带入错误的技术（详细的设计方法学和质量控制）
<3>错误清除：
清查那些在使用了错误回避技术路线后还残留在系统中的错误，并清除它们（需要大量的测试和证实过程）
5.故障检测
<1>潜伏的故障：
故障发生一段时间后才被检测出来
<2>错误潜伏期：
从故障发生到被检测出来的时间
平均检测时间（MTTD）：
平均错误潜伏时间
平均修复时间（MTTR）：
修复一个失败的系统所需要的期望时间
平均故障间隔时间（MTBF）：
在可以自我修复的系统中相继的失败之间的期望时间,由经验或从可靠性函数计算
6.冗余
所有容错系统设计中都采用的基本原则是在系统的组件中提供冗余
7.模块化
系统的每个组件都设计为具有定义很好的输入/输出接口的模块
模块化可以把故障隔离在单一的组件中
8.系统实现
a）故障-停止模块（fail-stopmodule）
b）进程对（Processpairs）
6.3.灵活性
1．需求分析采集
2.考察现有系统
3．分析各种可能的变化
4．数据库逻辑性设计
1）键设计原则为关联字段创建外键。
2）使用系统生成的主键。
5.关系模式规范化的度
6.要为尽量减轻前台的编码而工作
7.命名规范一定要统一
8.字段的设计原则
9．合理使用数据类型
10.慎用触发器
11.用视图隐藏细节
12.包含版本机制
6.4.特殊需求
1.进度需求
1）规划的主要任务就是作必要性及可行性分析。
2）需求分析需求分析大致可分成三步来完成。
<1>需求信息的收集,需求信息的收集一般以机构设置和业务活动为主干线，从高层中层到低层逐步展开
<2>需求信息的分析整理,对收集到的信息要做分析整理工作。
<3>需求信息的评审.开发过程中的每一个阶段都要经过评审，确认任务是否全部完成，避免或纠正工作中出现的错误和疏漏。
3）.概念模型设计概念模型不依赖于具体的计算机系统，他是纯粹反映信息需求的概念结构。
<1>设计局部概念模型①确定局部概念模型的范围②定义实体③定义联系④确定属性⑤逐一画出所有的局部ER图，并附以相应的说明文件
<2>设计全局概念模型建立全局ER图的步骤如下：
①确定公共实体类型②合并局部ER图③消除不一致因素④优化全局ER图⑤画出全局ER图，并附以相应的说明文件。
<3>概念模型的评审概念模型的评审分两部分进行,第一部分是用户评审。
第二部分是开发人员评审。
4）.逻辑设计逻辑设计阶段的主要目标是把概念模型转换为具体计算机上DBMS所支持的结构数据模型。
逻辑设计的输入要素包括：
概念模
升级会员 