1可靠性要求

1.1可靠性设计

严格按照软件工程化规范进行软件开发和设计：

严格进行软件需求、概要设计、详细设计和测试计划确认；

系统各单元的软件开发人员遵循规范的开发方法，确保所有的编码采用规定的工作语言，满足规范的编程风格。并采取各种方式进行阶段性检查，如程序走查等，及时发现软件质量问题并进行改进。确保开发进程中不降低可靠性；

对系统软件及其各单元软件进行严格的测试，测试工作按照计划进行。确保系统软件的可靠性。

1.2软件改错及容错设计

为了限制故障的蔓延,要求对过程和数据加以严格的定义和限制。针对操作系统的故障隔离方法:不允许一个用户的应用程序引用或修改其它用户的应用程序或数据;绝对不允许一个应用程序引用或修改操作系统的编码或操作系统内部的数据;保护应用程序及其数据,使其不致由于操作系统的错误而引起程序和数据的偶然变更;应用程序绝对不能终止系统工作、不能诱发操作系统去改变其它的应用程序或数据。

软件采用容错设计，在设计中赋予程序某种特殊的功能,使程序在错误已被触发的情况下,系统仍然具有正常运行能力的一种设计方法。

时间容错设计不惜以牺牲时间为代价来换取软件系统高可靠性,它包括指令的重复执行和程序重复执行，指令重复执行是当应用软件系统检查出正在执行的指令出错误后,让当前指令重复执行n次,在指令重复执行时间内,故障有可能不再复现,这时程序就可以继续往前执行下去。

程序(一个模块或一个子程序)重复执行是当应用软件系统检查出正在执行的程序出错误后,中断当前正在运行的软件,反复调用。在反复调用过程中若故障不再复现,这时程序继续从中断的地址执行。对于复执不成功的情况,通常的处理办法是发出中断,转入错误处理程序,或对程序进行复算,或重新组合系统,或放弃程序处理。

一般非关键信息可以使用奇偶校验码。关键、重要信息与其它信息之间应保持一定的距离,不会因一位或两位差错而引起系统故障。如安全关键信息有差错,应能检测出来,并返回到规定的状态,设计有安全状态或如循环码。安全关键信息的决策判断不得依赖于全“1”或全“0”的输入(尤其是从外部传感器传来的信息)。

硬件设备存在一定冗余，在少量设备故障时不影响系统运行。各类型业务软件相对独立，部分异常不会影响其它软件工作。

1.3可扩展性

扩展时主要采用多模块并行方式，各软件进程分别负责不同数据处理。

在代码风格上公司具有统一的命名规范，并在关键节点位置进行注释；排版上留出合理的空白空间来区分不同的代码块，同类的变量声明放在一组；代码层次性上开发人员对于一段业务逻辑分成几个子逻辑对应不同处理方法或数据管理；架构上根据系统的功能性能要求划分了多个模块，降低了系统的耦合性，提高了模块的复用性。

1.4可重用性

在多个业务软件中共同使用的通用功能模块，例如日志记录等，设计为可重用的模块重复利用。

在软件开发过程中预先分析出可重用部分，并继承软件类库中需要用到的基本功能，如菜单、对话框、列表框等很多模块会使用的界面元素且处理逻辑大致相同，并进行扩充其处理逻辑，增加合法性检查等，避免了重复相同的处理逻辑大大提高了效率。

而在类库中如排序、数据分发等框架可引用之前类似项目的相同框架纳入层次化管理。

2安全性要求

2.1安全性目的

系统生命周期内，采取有效的方法和控制措施将各级产品在研制、使用、维护中可能导致的危险消除，或其风险控制在可接受水平。

2.2病毒防护

系统通过采用防火墙等措施确保互联网连接安全，或通过安装网络防病毒软件，并定时升级病毒库，构筑对病毒的全面防御系统，有助于大大减少系统安全风险。

2.3信息检测

系统通过对录入信息库的数据进行合法性检测，对输入的数据进行数据清洗处理，在读取错误参数时进行报警，提供系统自动及人工判读模式，合理决策，正确生成相关数据文件，保证系统的有效运行。

系统具有数据检测、数据校验、数据清洗功能，并实时对外部数据文件做监控扫描管理，保证入库数据的安全。

2.4定期备份

系统通过定期备份机制进行数据库备份，当数据库或设备故障时，可以根据预先制定的故障处理预案，在其他备份机上做数据回迁，保障系统的不间断运作。

2.5报警提示

系统工作流程处于运行状态时，未收到其它模块的反馈结果，系统工作流程将处于等待状态。为避免等待时间过长，造成系统处于宕机状态，系统提供报警提示功能，保障系统工作流程不间断。

计算机类设备应安装防病毒措施。

可操作使用的计算机应设有用户使用权限，采取口令、密码、访问控制等方式进行用户身份验证。

采用硬盘和光盘备份系统软件和应用软件，提供快捷方便的系统安装和恢复能力。

3维修性要求

3.1维修性目的

将维修性的定性要求转化为具体的设计准则，开展维修性设计，满足本项目维修性定性要求。

设备维修性设计需遵循GB/T 9414-2001《设备维修性导则》、GJB368-87《装备维修性通用规范》要求。

3.2软件维护要求

软件全部采用模块化结构，按功能划分形成总控模块、功能模块、通用模块等。使用标准的程序设计语言，用面向对象的软件开发方法，利用开源稳定性好的软件工具，生成易修改、易理解、易测试的软件代码；

建立运行信息库来实现故障诊断。设计报警函数时，该函数具有返回记录编号、传递参数、调用模块标识、输入参数等等用途。每一个模块运行故障时都会反馈一个运行记录编号助于排除故障；

软件开发均考虑软件的可修改性和可扩充性；

软件开发时有足够的和有意义的正确代码注释，包括序言性注释和功能性注释；

系统配备维修性文档，可帮助用户掌握软件功能、组成及原理等，当发生故障后，能应用文档定位故障部位和实施修改；

软件开发时同时开发测试和维护软件，以保证软件的可测试性和可维修性。在关键节点设置检查点如软件数据包检查、验收检查等。

3.3互换性

充分利用通用化、系列化、组合化，特别是模块化的工作成果；

所有备件的性能、接口保证现场更换后即可正常工作而无需调整；

保证设备的易损件、有互换性要求的和关键的元器件和零件能互换；

最大限度的采用标准零、部件，有限选用符合国家标准、国家军用标准的标准件，保证设备具有良好的互换性。

4测试性要求

4.1测试性保证工作目的

对于软件系统而言，测试性主要指被测实体具有如下特征：可控制性、可分解性、稳定性、易理解性、可观察性，以上特征的表现需要通过设立观察点、控制点和观察装置。同时必须保证不能对软件系统的任何功能有影响，不能产生附加的活动或者附加的测试。

测试性设计需遵循GJB 2547A-2012《装备测试性大纲》要求。

4.2可控制性设计

全局变量的可控制性设计：对于全局类型的变量进行分类并封装到一个个接口中操作，通过修改配置文的对应信息完成外界对全局变量值的直接或间接控制。

接口的可控制性设计：本系统控制流和数据流明确区分，业务类型接口采用XML文件格式和restful风格接口，方便测试人员通过手工修改的方式即可直接对接口进行操作。对于数据类型接口，软件设计人员均会提供相应的模拟数据和构造模拟测试环境所需条件及参数说明，方便测试人员实现模拟接口对接。

模块的可控制性设计：本系统软件模块的设计时进行明确的功能划分，具备清晰地输入和输出定义，对于每一个相对独立的功能模块均能单独设计测试用例进行对应功能的测试，同时软件模块设计完善的异常处理措施，确保在测试运行期间模块异常时能够隔离而不影响测试。

业务流程的可控制性设计：本系统包含多个业务流程，包括数据存储流程、任务监控流程和数据提取流程等。每个流程在设计实现上均可独立驱动并控制执行，同时兼顾了各流程之间的连通性，确保测试过程中方便控制，灵活组合。

4.3可分解性设计

本系统业务流程设计时，对于复杂的业务流程均采用组件化的方式开发，每个组件具备一个服务式的对外接口，保证每个组件都是独立的动态库，总结下来就是高内聚、低耦合。确保在测试过程中能够对复杂业务流程进行分解，迅速定位故障。

4.4稳定性设计

本系统软件模块设计合理，对后续的扩展需求应预留接口，确保后期追加的模块不会对前期已测模块引入新的不必要的测试活动。

4.5易理解性设计

系统研制完成后向用户提供完整的文档，包括软件需求规格说明、软件设计说明、软件用户手册、软件版本说明等。在设计文档的编写中明确设计参考的标准，内容描述主次分明，依赖关系描述明确，接口功能以及参数说明完整，业务流程描述清晰易懂。便于测试人员编写测试说明和设计测试用例。

4.6可观察性设计

系统设计任务执行情况监视和需求闭环管理，测试人员可通过相关软件界面观察系统业务的执行状态和过程，同时各个业务软件均对关键性业务设计了异常告警日志，测试人员可通过日志内容监测系统异常的发生原因和处理情况。

4.7测试性规划

要求系统具有自检功能。

系统各模块自检测试：系统各单元自检项目为天线单元、基带处理单元和数据存储单元的上电自检。自检结果主要是各单元的工作状态是否正常等。自检结果通过系统总线传递给主控单元。

系统测试：系统测试是指通过专用测试设备对该系统进行测试，测试项目包括：信道误码率测试、设备参数标定、系统指标测试等。

测试设备由测试软件和接口单元构成。测试软件运行在测试计算机上，实现人机交互控制功能；接口单元实现系统总线接口协议。

4.8测试性设计

根据任务需求和系统性要求确定测试性要求并与其他设计要求相综合；

在整个设计过程中对测试性进行跟踪，并明确各层次设备的测试要求。

5保障性要求

设备保障性设计需遵循GJB1371-92《装备保障性分析》、GJB3872-99《装备综合保障通用要求》。

5.1规划人员和人力

本系统所需的各类操作维护人员可分为系统操作员、待培训人员等。各类人员的职能和所应具备的基本技能叙述如下：

系统操作员：负责本系统各业务模块的操作；对系统运行情况进行监视、登记，提出对保障资源需求的修改意见及系统消耗品的购置意见。该类人员应系统地阅读过本系统的用户手册，接受过有关于本系统的培训；具备win7操作系统以及诸如MySQL的大型关系数据库的使用维护知识。

待培训人员：刚介入本系统工作，尚未接受对本系统相关知识的培训或不能完全掌握各软件之间的业务处理关系。本系统特提供独立的模拟训练环境，保障该类人员尽快熟悉了解系统使用，独立完成业务工作。

5.2规划技术资料

提供的技术资料如下：

系统技术说明书。

系统使用维护说明书。

其他技术说明。

5.3规划训练保障

训练保障内容如下：

策划训练保障说明，说明开展综合保障工作的目标、基本途径，制定内部训练保障的组织机构、人员及职责，明确参与后期保障管理组的人员及工作安排；

针对系统后期运行维护事项，提前计划相关设备的维护注意事项。

根据可靠性设计，分析系统可能存在的故障问题，预防性的确定项目每一环节所需资源和测试设备的使用及维护。

在方案阶段确认现有训练和训练保障条件，落实用户需求，工程研制阶段根据使用与维修人员必须具备的知识和技能，编制训练教材，制定训练计划，并开展相关训练培训活动。

5.4预防性维修或修复性维修方式

本系统的维修工作类型以非计划维修为主，即出现故障后及时进行修复性维修。修复性维修工作项目包括：提供新的软件版本或修补软件包替代原有软件。恢复被损坏的数据。

6环境适应性要求

软件应对各种操作系统具有较强的兼容性。

6.1适应性

使用CS模式作为软件系统架构，允许系统部署在不同操作系统上，避免客户端对操作系统的依赖，减少软件对操作系统的限制。

硬件设备采用通用设备便于扩展，软件采用平台化设计，采用配置方式适应不同类型要求。

6.2可移植性

采用C++/python之类的具有操作系统无关性的语言进行软件开发，使运行在服务端的软件不受操作系统的限制；限制系统调用于一个函数中，减少对操作系统的依赖性，当必须使用系统调用时，将所有调用限制在一个主函数中，若要将此程序移植到另一个系统时，只需修改此函数而其余函数可原封不动。

使用宏定义，处理依赖系统和处理器的“幻数”，如磁盘存取缓冲区的大小，特定显示器或键盘命令内存分配信息等所在程序移植时需要进行变动的东西，用一个符号量常来代替，在整个程序中修改一次即可，简化了编辑工作，具备良好的可移植性。

6.3易用性

按照一个中心总体技术设计软件功能要求，界面风格及显示模式适应HJ转型建设发展需求特点，配置项合理布局，操作流程流畅，可根据用户要求定制相应的界面风格采用网页的平铺式呈现或传统的窗口式等方式。

6.4开放性

采用通用的硬件设备，支持行业标准。软件设计遵循大系统接口协议要求，涉及到对第三方提供的接口采用开放式系统结构实现。通过定义抽象类或者接口，使得调用者在使用这些被规范的类的时候可以使用同一代码调用而不用修改原来的代码，满足综合大系统灵活配置和扩展要求。