2022年用户需求报告 .pdf

上传人:Q****o 文档编号:24923105 上传时间:2022-07-08 格式:PDF 页数:16 大小:75.12KB
返回 下载 相关 举报
2022年用户需求报告 .pdf_第1页
第1页 / 共16页
2022年用户需求报告 .pdf_第2页
第2页 / 共16页
点击查看更多>>
资源描述

《2022年用户需求报告 .pdf》由会员分享,可在线阅读,更多相关《2022年用户需求报告 .pdf(16页珍藏版)》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、需求规格说明书内蒙古大学电脑学院管理科学与工程第三组聂帅、陆娜冯阳邢宇博耿万秋高晋尧王熙王挺张飞精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 1 页,共 16 页需求规格说明书I 目录1. 概述 . 11.1. 用户简介 . 11.2. 项目的目的与目标. 11.3. 术语定义 . 11.4. 参考资料 . 21.5. 相关文档 . 21.6. 版本更新信息. 22. 目标系统描述. 32.1. 组织机构与职责. 32.2. 角色定义 . 32.3. 作业流程业务模型. 42.4. 单据、账本、报表. 42.4.1. 单据 . 42.4.2. 账

2、本 . 错误 !未定义书签。2.4.3. 报表 . 错误 !未定义书签。2.5. 可能的变化 . 63. 目标系统功能需求. 63.1. 功能需求分析. 63.2. 功能需求点列表功能模型. 64. 目标系统性能需求. 74.1. 时间要求 . 74.2. 空间性能 . 74.3. 性能需求点列表. 75. 目标系统界面与接口需求. 95.1. 界面需求 . 95.2. 接口需求列表. 96. 目标系统其他需求. 10 6.1. 安全性 . 10 6.2. 可靠性 . 11 6.3. 灵活性 . 12 6.4. 特殊需求 . 13 7. 目标系统假设与约束条件. 13 精选学习资料 - - -

3、 - - - - - - 名师归纳总结 - - - - - - -第 2 页,共 16 页需求规格说明书第1页共 16页1. 概述信息现代化是二十一世纪信息化时代的重要特征,当今社会各行各业都在积极提高自身的信息化水平, 因为信息现代化是当今社会的必然趋势,信息化水平越来越成为衡量一个国家、一个企业、一个事业单位现代化水平的重要标志,对它们发展具有重要的作用。学校作为一个事业单位也必须积极进行信息化,学校进行信息化建设具有得天独厚的优势,一来学校是教书育人、科学研究的场所,本身对信息化的需求非常旺盛;二来学校有一定的信息化基础,在进行信息化过程中无论在人员培训还是在基础设备建设上都会省去不少力

4、气;三来学校有充足的人才技术资源和信息资源,这些资源对信息化具有重要作用。要想实现学校的信息化第一步就应该进行学校信息的信息化,学校信息管理的主要部分就是对学生信息的管理,因而开发一个学生信息管理系统对学校信息化具有重要的意义。1.1. 用户简介学生信息管理系统主要是针对学生信息管理的,因而它的主要用户有学生、老师、 教务工作者。学生主要用于查询自身信息,对数据的访问权限比较低,只有查询自身信息的权限,对系统的性能要求不高,主要是信息传输的快速、查询的方便、信息显示的友好美观;老师主要用于学生成绩的录入,对数据访问权限比较高,能够修改特定学生的成绩,对系统的要求主要是信息录入的方便准确;教务工

5、作者主要用于信息的录入、维护、修改、统计等,具有很高的权限, 对系统的要求比较高,系统必须安全、 录入信息方便、 界面友好、 操作简单,稳定。1.2. 项目的目的与目标1.2.1 项目目的开发一套学生管理信息系统,以便于学生信息的管理,提高学校的信息化水平。为学校信息现代化打基础、做准备。1.2.2 项目目标(1)学生信息的电子化。将学生的信息全部采用电子化存储,以实现学校各部门对学生信息的方面共享统一,便于学校的管理;(2)教学的信息化管理。学生选课、学生成绩的录入查询、课程的安排,教师教室的分配都由电脑自动完成,提高学校管理的效率;(3)提高教务、 生活等管理的效率,学校各部门对学生信息的

6、共享统一,能够防止很多重复工作,提高管理的效率。1.3. 术语定义无精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 3 页,共 16 页需求规格说明书第2页共 16页1.4. 参考资料1学校组织机构说明2学校部门职责说明3教师职责说明4学生管理手册5学生管理章程1.5. 相关文档(1)功能模块的变更,可能在运行过程中,用户的会有新的需求,所以在开发过程中,一注意系统的可扩展性,以及模块的独立性。(2)数据信息的变更,随着社会的发展以及系统的需要,可能对学生的信息进行相应的增加,以及有些字段的变更,必须提供一种数据扩展变更的机制。(3)项目开发过程的

7、变更,可能先前开发流程不能很好地推进项目的进行,要做一些相应的调整。(4)开发时间人员的变更。1.6. 版本更新信息表 1-1 版本更新记录版本号创建者创建日期维护者维护日期维护纪要V 第三组2011-12 第三组无无精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 4 页,共 16 页需求规格说明书第3页共 16页2. 目标系统描述2.1. 组织机构与职责教务处老师学生学院财务处学校教务处后勤管理处学校学生信息的录入学生信息的维护教学安排学生成绩的录入学生成绩的修改学生信息的查询获取学生基本信息学生转系、休学等管理全校教学安排全校师生信息的维护获取

8、学生基本信息2.2. 角色定义表 2-1 角色定义编号角色所在部门职责相关的业务学生普通用户各学院查询信息、选课查询信息、选课老师管理员各学院录入学生成绩录入、修改成绩学院教务工作人员高级管理员学院教务处学生信息采集维护学 生 信 息 的 录入、维护、教学安排学校教务工作人员高级管理员学校总教务处全校学生信息维护,各部门学生信息维护学 生 信 息 的 修改、删除、转移等精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 5 页,共 16 页需求规格说明书第4页共 16页2.3. 作业流程1业务模型2信息录入数据学院信息教师信息学生基本信息班级信息宿舍信

9、息产生查询查询学生修改成绩录入成绩老师学生信息的录入学生信息的维护教学安排教务处工作人员数据共享其他学校部门2.4. 单据、账本、报表本系统使用的单据主要有录取通知书复印件、学生身份证复印件、学生成绩。 这些单据对于系统需求分析具有重要的作用,能够帮助我们在开发系统时考虑清楚系统各板块的连接和组织。从而更好的设计好系统。2.4.1. 单据因为单据上的数据是原始数据,所以一种单据一般对应一个实体,一个实体一般对应一张基本表。单据的格式可用表格描述,如表所示。单据的描述格式单据名称录取通知书用途学生录取信息合适使用单位教务处1Busywork Flow 2Operation Model 精选学习资

10、料 - - - - - - - - - 名师归纳总结 - - - - - - -第 6 页,共 16 页需求规格说明书第5页共 16页制作单位学校招生办频率1 高峰时数据流量1 各数据项的详细说明属性中文名属性英文名属性类型、长度、精度属性的值域主键 /外键通知书号Admit NO char 型、 8、无无主键身份证号IDCard char 型、 18、无无外键高考分数EntranceGrade samllint 单据的描述格式单据名称成绩单用途学生成绩证明使用单位教务处制作单位学院教务处频率1 高峰时数据流量1 各数据项的详细说明属性中文名属性英文名属性类型、长度、精度属性的值域主键 /外键

11、学号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 精选学习资料 - - - - - - - - - 名师归纳总结 - - -

12、- - - -第 7 页,共 16 页需求规格说明书第6页共 16页2.5. 可能的变化(1)描述学生的信息可能改变,随着社会的发展,学生的有些属性可能变得比较重要,可能需要把这些属性添加到学生表中,比方学生的QQ 号可能会添加到学生表中。(2)学校组织机构的变化可能会系统相关内容的改变,如学校可能增设学院、系等, 这时系统相关部分会发生变化。(3)信息录入方式的变化,可能学生的信息会存放在卡片中,这时候学生信息的录入就可能发生变化。3. 目标系统功能需求3.1. 功能需求分析(1)学生: 学生对系统的主要需求是查询信息,学生能够查询自身的基本信息、学院信息、课程信息、授课教师信息、教师使用信

13、息和班级信息。为方便学生查询,系统必须具有友好清晰的用户界面,信息组织分类应简明清楚,让用户一目了然。同时查询应简单, 尽量减少学生的输入的工作量,尽量用鼠标点击代替用户输入,这样一方面方便了用户,同时也简化了系统的实现。(2)老师: 老师对系统的主要需求是学生信息录入以及信息查询。老师需要录入、 修改学生成绩,以及对学生基本信息、课程信息、教师信息、学院信息等进行查询。在系统设计时应着重考虑老师录入信息的需求,应采取措施方便老师对学生信息的录入,而且还应着重考虑如何防止信息的错误录入,尽量减少由于人的原因导致信息录入的错误,同时还应对录入的信息进行检查,提供一种检错机制。(3)教务处管理员:

14、教务处工作人员是整个系统的管理员,对系统有比较多的需求,在系统设计时应重点考虑他们对系统的功能需求。管理员对系统的主要需求是,各种信息的录入、修改、删除,同时还要求对信息的自动化的统计整理。比方在学生基本信息录入时,录入应方便, 有些信息应该是自动化录入,还应该考虑信息录入的核对方便、 有一定的检错能力,要有一定的机制防止由于误操作导致信息录入的错误,还比方,系统应该能够自动对学生信息进行整理,方便管理员调出相关信息,如统计学生成绩,按班级对学生进行分类等。3.2. 功能需求点列表功能模型在功能需求分析完成后,要详细列出用户需求功能点列表,提供应后续设计、编程、测试中使用,更是为了用户测试验收

15、中使用。表 3-1 功能需求点列表编号功能名称使用部门使用岗位功能描述输入系统响应输出1 查询查询信息查询条件1s-2s 查询结果2 修改教务学生信息更改修改位置、内容1s-2s 修改数据库, 反馈精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 8 页,共 16 页需求规格说明书第7页共 16页处管理处修改是否成功3 信息录入教务处教务管理处信息录入学生、教师、课程等信息录入比较长录入信息的显示预览4 成绩录入办公室老师学生成绩录入学生成绩比较长录入信息的显示预览5 删除教务处教务管理处删除学生信息删除内容1s-2s 反馈删除是否成功6 统计教务处

16、教务管理处学生成绩统计学号、班级号1s-2s 输出成绩统计结果7 排课教务处教务管理处课程安排课程、教室1s-2s 课程表8 信息导出教务处教务管理处导出经整理过的信息信息需求1s-2s 信息汇总表4. 目标系统性能需求4.1. 时间要求(1)响应时间,如查询的最长等待时间。要求响应时间应该在大多数用户所能承受的范围内。一般应小于30S 分钟。(2)更新处理时间,如记账的最长时间。更新时间不超过60S。(3)数据的转换和传送时间,如远程数据传输的时间要求。远程数据传送要求不超过60S (4)解题时间解题时间要求不超过15S 4.2. 空间性能(1)支持的终端数。30000要求其大或等于全校师生

17、人数,这里假设为30000 人 。(2)支持的并行操作的使用者数。3000,要求不少于总数的1/10 (3)处理的文件和记录数。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 9 页,共 16 页需求规格说明书第8页共 16页峰值情况处理6000 条记录。(4)表和文件的大小规模 要按可预见的增长, 对数据及其分量的存储要求做出估算。学校20 个学院,一个学院1500 名学生,每个学生需要2MB ,每年增加20*1500*2=60000MB ,约 58GB。(5)处理任务的数量。要求能同时处理8000 个任务。(6)在正常情况下和峰值工作条件下,在

18、一定时间周期中要处理的数据总数。峰值情况:约15000 名学生在一天内同时使用系统如选课时,每个人需要处理2MB 的数据,需处理15000*2MB/ 天=30000M/ 天,约 30GB/天;正常情况: 1000 名用户在一天内同时使用系统,每个人需要处理2MB 的数据,需处理 1000*2MB/ 天=2000M/ 天,约 2GB/天;(7)对输入和输出数据的精度要求输入要求,用户名学号:8 位整数,口令密码 :614 位数,成绩: 0 至 100整数。(8)对处理和传输过程中的精度要求。计算成绩平均值保留一位小数,学分绩点平均值保留两位小数,统计及格率、 优秀率、挂科率等保留两位小数。4.3

19、. 性能需求点列表详细列出用户性能点列表,提供应后续分析、设计、编程、测试中使用,更是为了用户测试验收中使用。表 4-1 性能需求点列表编号性能名称使用部门使用岗位性能描述输入系统响应输出1 响应时间学校学生查询响应时间查询条件时间响应时间2 负载量学校学生系统同时处理查询能力多人同时查询时间响应时间3 事务处理教务处教务管理事务处理能力同时提交多事务时间响应时间4 安全性教务处教务管理系统安全能力非法入侵5 恢复能力教务处教务管理系统恢复能力提交恢复事物时间响应时间6 查错能力教务处教务管理系统查错能力非法数据7 稳定性学校学生系统运行稳定性访问精选学习资料 - - - - - - - -

20、- 名师归纳总结 - - - - - - -第 10 页,共 16 页需求规格说明书第9页共 16页5. 目标系统界面与接口需求5.1. 界面需求用户界面: 又称人机界面, 实现用户与电脑之间得通信,以控制电脑或进行用户和电脑之间得数据传送得系统部件。5.1.1用户界面设计原则本系统坚持图形用户界面GUI 设计原则,界面直观、对用户透明:用户接触软件后对界面上对应的功能一目了然、不需要多少培训就可以方便使用本应用系统。在界面设计中应该保持界面的一致性。一致性既包括使用标准的控件,也指使用相同的信息表现方法,如在字体、 标签风格、 颜色、 术语、 显示错误信息等方面确保一致。应注意在一个窗口内部

21、所有控件的布局和信息组织的艺术性,使得用户界面美观。在一个窗口中按tab 键,移动聚焦的顺序不能杂乱无章,tab 的顺序是先从上至下,再从左至右。 一屏中首先应输入的和重要信息的控件在tab 顺序中应当靠前,位置也应放在窗口上较醒目的位置。布局力求简洁、有序、易于操作。对于应用中某些部分的处理流程是固定的,用户必须按照指定的顺序输入操作信息,为了使用户*作得到必要的引用应该使用向导,使用户使用功能时比较轻松明了,但是向导必须用在固定处理流程中,并且处理流程应该不少于3 个处理步骤。5.1.2用户界面设计更改更改本用户界面设计时应该征得所有开发者的同意,所有开发者应该按更正后的原则修改和设计用户

22、界面。总之,在开发系统时要时刻注意考虑客户的需求,充分重视客户所提的意见,界面设计要符合使用者的使用习惯,尽量使他们感到使用舒服方便。5.1.3用户界面设计追加说明追加本用户界面设计时应该发布给所有开发者,所有开发者应该按追加后的原则修改和设计用户界面。5.2. 接口需求列表与其他系统的接口,如监控系统、控制系统、银行结算系统、税控系统、财务系统、政府网络系统及其他系统等。(1)与其他系统的接口,如监控系统、 控制系统、 银行结算系统、 税控系统、 财务系统、政府网络系统及其他系统等。(2)与系统特殊外设的接口,如CT 机、磁共振、柜员机ATM 、 IC 卡、盘点机等。(3)与中间件的接口,要

23、列出接口标准、入口参数、出口参数、传输频率等。应在此列举出所有的外部接口名称、接口标准、标准。外部接口列表。表 5-1 接口需求点列表编号接口名称接口标准接口标准入口参数出口参数传输频率01 LTP DDR2 32KB 256KB 93MB/SEC 02 SATA PCIE 18KB 32KB 150MB/SEC 03 PATA 无AF520C 32KB 128KB 24MB/SEC 精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 11 页,共 16 页需求规格说明书第10页共 16页04 IDE AMD 8KB 64KB 48MB/SEC 05

24、COM PCII 32KB 64KB 70MB/SEC 06 ATA 无TP30D 64KB 256KB 133MB/SEC 6. 目标系统其他需求6.1. 安全性6.1.1 数据库权限和用户分类(1)对数据库管理系统正常运行而进行的维护权限(2)对数据库中的对象和数据的操作权限(3)用户按其操作权限的大小可分为数据库系统管理员数据库对象拥有者普通用户6.1.2 oracle 的安全机制(1)建立在认证和访问许可机制上的身份验证访问权验证操作权验证(2)SQL Server 登录账户的来源有两种:Windows 授权用户:来自于Windows 的用户或组;数据库授权用户:来自于非Windows

25、 的用户,我们也将这种用户称为数据库用户。6.1.3 管理 oracle 登录账户(1)一类是由oracle 自身负责身份验证的登录账户;(2) 另一类是登录到oracle 的 Windows NT/2000 网络账户,可以是组账户或用户账户。6.1.4 管理数据库用户数据库用户简介数据库用户用来指出哪一个人可以访问哪一个数据库。用户对数据的访问权限以及对数据库对象的所有关系都是通过用户账号来控制的,用户账号总是基于数据库的。用户账号和登录账号用户账号只说明该账号通过了NT 认证或 oracle 认证,但不能说明其可以对数据库数据和数据对象进行某种或某些操作,所以一个登录账号总是与一个或多个数

26、据库用户账号这些账号必须分别存在相异的数据库中相对应, 这样才可以访问数据库。6.1.5 管理权限(1)对象权限对象权限是指用户对数据库中的表、视图、存储过程等对象的操作权,如:对表和视图,可以使用SELECT 、INSERT、 UPDATE 和 DELETE 权限。对于表和视图的字段;可以使用SELECT 和 UPDATE 权限。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 12 页,共 16 页需求规格说明书第11页共 16页对于存储过程;可以使用EXECUTE 权限。(2)语句权限语句权限相当于数据定义语言DDL 的语句权限,这种权限专指是

27、否允许执行以下语句: CREATETABLE 、CREATEPROCEDURE 、CREATEVIEW等与创建数据库对象有关的操作。(3)隐含权限隐含权限是指由SQL Server 预定义的服务器角色、隐含权限相当于内置权限,而不再需要明确地授予这些权限。例如,数据库拥有者自动地拥有对数据库进行一切操作的权限。6.1.6 管理角色具有相同权限的用户就称为角色。角色分为:系统预定义的固定角色用户根据自己的需要定义的用户角色系统角色又根据其作用范围的不同而被分为:固定的服务器角色,是为整个服务器设置的固定的数据库角色,是为具体的数据库设置的。6.1.7 oracle 安全性管理的途径使用视图作为安

28、全机制使用存储过程作为安全机制6.2. 可靠性1. 概念1 .可靠性指数据库在一给定时间间隔内不产生任何失败的概率。它强调数据库的正确性,要求数据库正确运行,既符合某种规格化要求。通常用来描述不可修复的系统。2). 可用性强调的是当需要访问数据库时,它是可用的。 指在给定的时间点系统可以正常运行的概率。通常用于描述那些可以修复的系统。3). 两者关系通常认为构建可用性的系统比可靠性的系统容易。两者是统的, 可靠性高的系统可用性自然是好的。两者又是矛盾的,增加错误风险的情况下,可提高可用性;采用太谨慎的策略会降低可用性。2.平均故障间隔时间1指在可以自我修复的系统中相继失败之间的期望时间通过可靠

29、性函数来计算MTBF= 0 R(t)dt MTBF 与系统失败的概率有直接的关系2平均修复时间是指修复一个系统所需要的期望时间,MTTR 它与失败概率有关指数型失败和修复的概率的系统可用性A=MTBF/(MTBF+MTTR) 3可用性系统精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 13 页,共 16 页需求规格说明书第12页共 16页5 个 999.999%常用来描述可用性系统但是可用性系统要求的成本比较高,具体设计时要综合用户两方面的要求。3.系统失败的原因1系统标准说明Specification 系统提供的对所有可能的刺激将产生的响应行为必

30、须遵循的说明。2) 故障:任何偏离标准说明的行为软故障和硬故障软故障包括间歇性intermittent 和瞬变性transient故障,通过重启动来修复硬故障指永久性故障, 错误设计等软件和硬件故障基本容错方法和技术4.容错设计一种使系统识别出可能会发生的错误的方法。在系统中建立一种机制,使错误在造成系统故障之前就会被检测出来,并能被清除或得到补偿。错误预防保证所实现的系统不包含任何错误错误回避:保证系统不会带入错误的技术详细的设计方法学和质量控制错误清除:清查那些在使用了错误回避技术路线后还残留在系统中的错误,并清除它们需要大量的测试和证实过程5.故障检测潜伏的故障:故障发生一段时间后才被检

31、测出来错误潜伏期:从故障发生到被检测出来的时间平均检测时间(MTTD) : 平均错误潜伏时间平均修复时间(MTTR) : 修复一个失败的系统所需要的期望时间平均故障间隔时间(MTBF) : 在可以自我修复的系统中相继的失败之间的期望时间 , 由经验或从可靠性函数计算6.冗余所有容错系统设计中都采用的基本原则是在系统的组件中提供冗余7.模块化系统的每个组件都设计为具有定义很好的输入/输出接口的模块模块化可以把故障隔离在单一的组件中8.系统实现a)故障 -停止模块 fail-stop module) b)进程对 Process pairs) 6.3. 灵活性1需求分析采集2. 考察现有系统3分析各

32、种可能的变化4数据库逻辑性设计1键设计原则为关联字段创建外键。2使用系统生成的主键。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 14 页,共 16 页需求规格说明书第13页共 16页5. 关系模式标准化的度6. 要为尽量减轻前台的编码而工作7. 命名标准一定要统一8. 字段的设计原则9合理使用数据类型10. 慎用触发器11. 用视图隐藏细节12. 包含版本机制6.4. 特殊需求1.进度需求1规划的主要任务就是作必要性及可行性分析。2需求分析需求分析大致可分成三步来完成。需求信息的收集,需求信息的收集一般以机构设置和业务活动为主干线,从高层中层到

33、低层逐步展开需求信息的分析整理,对收集到的信息要做分析整理工作。需求信息的评审.开发过程中的每一个阶段都要经过评审,确认任务是否全部完成,防止或纠正工作中出现的错误和疏漏。3.概念模型设计概念模型不依赖于具体的电脑系统,他是纯粹反映信息需求的概念结构。设计局部概念模型确定局部概念模型的范围定义实体定义联系确定属性逐一画出所有的局部ER 图,并附以相应的说明文件设计全局概念模型建立全局ER 图的步骤如下:确定公共实体类型合并局部 ER 图消除不一致因素优化全局ER 图画出全局ER 图,并附以相应的说明文件。概念模型的评审概念模型的评审分两部分进行, 第一部分是用户评审。第二部分是开发人员评审。4

34、).逻辑设计逻辑设计阶段的主要目标是把概念模型转换为具体电脑上DBMS 所支持的结构数据模型。逻辑设计的输入要素包括:概念模式、用户需求、约束条件、选用的 DBMS 的特性。5).物理设计物理设计是对给定的逻辑数据模型配置一个最适合应用环境的物理结构。物理设计的输入要素包括:模式和子模式、 物理设计指南、 硬件特性、 OS 和 DBMS的约束、 运行要求等。 物理设计的输出信息主要是物理数据库结构说明书。其内容包括物理数据库结构、存储记录格式、存储记录位置分配及访问方法等。6).程序编制及调试在逻辑数据库结构确定以后,应用程序设计的编制就可以和物理设计并行地展开程序模块代码通常先在模拟的环境下

35、通过初步调试,然后再进行联合调试。7. 目标系统假设与约束条件(1)法律政策方面精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 15 页,共 16 页需求规格说明书第14页共 16页首先明确开发系统可能导致的问题。开发系统成员, 都要仔细阅读国家标准电脑软件产品开发文件编制指南。本系统纯为私人设计,在开发过程中不会设计合同,责任等语法律相抵触的东西。(2)在软硬件方面本系统管理的对象单一,都是在校学生,且每个数据关联性比较强,涉及的过程不是很复杂,比较适应于数据库管理。开发环境是ORACLE 10g,学校的微机在速度上和存储方面都能满足。在技术难度

36、方面,开发语言采用C+,有指导老师的指导合相关的参考文献,再加上方便的互联网功能,技术上也能实现。(3)系统完成的最晚日期在本学期的期末即可完成。(4)存在的风险由于专业的课程设置,开发系统的小组成员都没有上过系统的软件开发的课程,因此可能在技术和整个开发过程的把握还是存在一定的技术风险。在功能上, 首先应该充分分析该系统的目标以及所能提供的功能,可以简单的参考学校正在使用的教务系统,否则存在功能上得风险。小组成员基本能做到积极合作,在系统完成明的时间上风险很低,应该基本能保证完成任务。 由于系统规模较小,只是本科生的学期作业,因此也不会村存在历史太久而导致的系统某些功能失去时效性的风险。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 16 页,共 16 页

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 技术资料 > 技术总结

本站为文档C TO C交易模式,本站只提供存储空间、用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。本站仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知淘文阁网,我们立即给予删除!客服QQ:136780468 微信:18945177775 电话:18904686070

工信部备案号:黑ICP备15003705号© 2020-2023 www.taowenge.com 淘文阁