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

上传人:无*** 文档编号:115996541 上传时间:2022-07-04 格式:DOC 页数:26 大小:1.13MB
返回 下载 相关 举报
新生报到系统需求分析报告_第1页
第1页 / 共26页
新生报到系统需求分析报告_第2页
第2页 / 共26页
新生报到系统需求分析报告_第3页
第3页 / 共26页
点击查看更多>>
资源描述
新生报到管理系统需求分析报告学院 信息技术工程学院 班级 网络工程1001班 成员 丰云 马红艳 赵树悦 甄亚男 王刚 1引言31.1标识31.2系统概述3 1.2系统概述3 1.2.1项目来源及背景3 1.2.2系统结构计划3 1.2.3用户特点32引用文件33需求43.1要求的状态和方式43.2需求概述43.2.1系统总体功能和业务结构43.2.2硬件系统的需求193.2.3软件系统的需求203.2.4接口需求203.3系统能力需求203.3.x(系统能力)203.4系统外部接口需求213.4.1接口标识和接口图213.4.2用户接口21 3.4.3(接口的项目唯一标识符)213.5系统内部接口需求223.6系统内部数据需求233.7性能需求233.8操作需求243.9可使用性、可维护性、可移植性、可靠性和安全性需求243.10故障处理需求253.12.1软件系统出错处理253.12.2硬件系统冗余措施的说明253.11计算机通信需求253.12设计和构造的约束253.13其他需求264尚未解决的问题265注解261引言1.1标识符合、缩略语和定义如下:B/S: Brower/Server 浏览器/服务器SQL SERVER: 系统服务器所使用的数据库管理系统(DBMS)。 UML: Unified Modeling Language(同一建模语言)的缩写,是一个标准的建模语言1.2系统概述新生报到管理系统是结合学校迎新活动管理的实际需要,对新生的入学情况进行管理的信息系统,提供丰富的查询分析功能和管理、决策信息,是提高高校迎新工作效率的管理软件。使用该系统可以实现新生信息的有序存储,使得检索迅速、查找方便、并且提高了可靠性。本软件旨在使学校对新生信息的管理,以减轻工作人员的负担,可以加快迎新工作的有条不紊的进行,实现直观化,合理化。通过这样的系统,可以做到信息的规范管理、科学统计和快速的查询,从而减少管理方面的工作量。尤其对于复杂的信息管理,计算机能够充分发挥它的优越性。1.2.1项目来源及背景新生报到系统采用UML结构,在设计初期即充分考虑系统的安全性、稳定性和所需提供的必要功能,并在充分吸取前人经验的基础上着手设计和开发。因而功能齐全,性能稳定可靠,介面亲和力强,是普通使用者容易上手操作的新生报到系统。该系统虽是今年刚开发的软件产品,每个新生要经历近8个处理环节。在普通的服务器上、几百个用户同时在线处理、系统均能应付自如,未出现任何差错,大大减轻各级经办人员的劳动强度,因而赢得学院领导和各基层单位的一致好评。 1.2.2系统结构划分本系统共分为:报到、缴费、宿舍分配、户籍迁移、校医院体检等5个个功能模块。其数据更新权归各职能部门所有,从而保证了全院范围内的数据一致性,也为责任落实到人提供了基础。1.2.3用户特点:本系统的用户是网上用户,一类是新生,他们只需要打开新生报到界面,输入自己的学号或者证件号等就可以进入根据自己系统的提示进入新生报到的程序;另一类用户是管理用户,他们是高校内部的人,主要是系统管理人员和教务处,他们熟悉该流程以及办理,系统人员对系统很熟悉,对系统进行维护。2引用文件软件工程案例教程 机械工业出版社 韩万江 编著数据库系统概论第四版 高等教育出版社 王珊 萨师煊 编著3需求本章分条详述系统需求,是指功能、业务(包括接口、资源、性能、可靠性、安全性、保密性等)和数据需求。也就是,构成系统验收条件的系统特性。给每个需求指定项目唯一标识符以支持测试和可追踪性。并以一种可以定义客观测试的方式来陈述需求。对每个需求都应说明相关合格性方法,如果是子系统,则还要给出从该需求至系统需求的可追踪性。描述的详细程度遵循以下规则:应包含构成系统验收条件的那些系统特性,需方愿意推迟到设计时留给开发方说明的那些特性。如果在给定条中没有需求可说明的话,应如实陈述。如果某个需求在多条中出现,可以只陈述一次而在其他条中引用之。3.1要求的状态和方式3.2需求概述3.2.1系统总体功能和业务结构我们采用面向对象分析作为主要的系统建模方法,使用UML(Unified Modeling Language)作为建模语言。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硬件系统的需求服务器: 操作系统:Microsoft Windows 2000 ServerCPU:P4处理器内存:512M客户端: 操作系统:全系列WINDOWS CPU:1G处理器 内存:128M 浏览器:IE5.0以上3.2.3软件系统的需求说明对软件系统的需求。操作系统: Windows 2000或以上版本数据库:MySQL开发工具包:JDK Version 1.6Web服务器:Tomcat浏览器:IE5.0及以上3.2.4接口需求说明硬件系统和软件系统之间的接口。3.3系统能力需求本条应分条详细描述和系统每一能力相关联的需求。“能力”被定义为一组相关的需求。可以用“功能”、“性能”、“主题”、“目标”或其他适合用来表示需求的词来替代“能力”。3.3.1 界面需求l 页面内容主题突出,美观简洁l 导航结构明确,易于用户理解使用l 页面大小适中,能用各种浏览器以不同分辨率浏览,页面风格统一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)范围或可能值的枚举(如:099); 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) 数据库描述 本软件采用SQL SERVER 2005专用数据库接口。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计算机通信需求本条应描述系统必须使用的或引人系统的计算机通信方面的需求,例如包括:连接的地理位置、配置和网络拓扑结构、传输技术、数据传输速率、网关、要求的系统使用时间、传送/接收数据的类型和容量、传送/接收/响应的时间限制、数据的峰值和诊断功能。3.12设计和构造的约束(若有)本条应描述约束系统设计和构造的那些需求。对硬软件系统而言,本条应包括强加于系统的物理需求,这些需求可通过引用适当的商用标准和规范来指定。需求包括:a.特殊系统体系结构的使用或对体系结构方面的需求,例如:需要的子系统;标准部件、现有部件的使用;政府/需方提供的资源(设备、信息、软件)的使用;b.特殊设计或构造标准的使用;特殊数据标准的使用;特殊编程语言的使用;工艺需求和生产技术;c.系统的物理特性(如:重量限制、尺寸限制、颜色、保护罩);部件的可交换性;从一地运输到另一地的能力;由单人或一组人携带或架设的能力;d.能够使用和不能使用的物品;处理有毒物品的需求以及系统产生电磁辐射的允许范围;e.铭牌、部件标记、系列号和批次号的标记、其他标识标记的使用;f.为支持在技术、威胁和任务等方面预期的增长和变化而必须提供的灵活性和可扩展性。3.13其他需求(若有)本条应描述在以上各条中没有涉及到的其他系统需求,包括在其他合同文件中没有涉及的系统文档的需求,如:规格说明、图表、技术手册、测试计划和测试过程以及安装指导材料。4尚未解决的问题如需要,可说明系统需求中的尚未解决的遗留问题。5注解本章应包含有助于理解本文档的一般信息(例如背景信息、词汇表、原理)。本章应包含为理解本文档所需要的术语和定义,所有缩略语和它们在文档中的含义的字母序列表。26 / 2626 / 26
展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 管理文书 > 施工组织


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


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