装备安全性工作通用要求- 软件安全性需求与分析

10.2.1 目的

保证装备安全性要求分解到软件安全性需求的正确性,并对软件安全性需求是否维持系统处于安全状态,是否对潜在失效提供正确充分的响应进行复核。

10.2.2 工作项目要点

10.2.2.1 应从装备安全性要求、环境要求、标准、项目规范、系统、分系统或设备要求、接口要求、系统危险报告中获取软件安全性需求。

10.2.2.2 全部软件安全性需求,包括通用需求和特定需求,均应在《软件需求规格说明》(见 GJB 438B-2009 规定)中清晰地标识出来。

10.2.2.3 应采用结构化的方式描述软件安全性功能需求,以保证需求描述的清晰、准确、无歧义、可复核、可测试、可维护和可实现。

10.2.2.4 软件安全性需求应包括有效的运行模式或状态,以及禁止或不适用的运行模式或状态。

10.2.2.5 当软件与硬件合作共同实现一个安全关键功能时,他们各自的作用、时序和失效模式应在《软件需求规格说明》中明确描述,并获得相关分系统的认可。软件与硬件之间的安全性约束(如失效模式、故障处理、降级处理等)也应包含在《软件需求规格说明》中。

10.2.2.6 对软件安全性需求进行分析,分析至少应包括下述内容:

a) 验证软件安全性需求满足 10.2.2.1~10.2.2.5 的全部要求;

b) 对软件安全性需求描述中不明确的、不一致的、被忽略的需求或未定义的适用条件进行检查;

c) 审核软件安全性需求对装备安全性要求、环境要求、标准、项目规范、工程项目规格说明、系统与设备要求、接口要求和系统危险报告的可追溯性;

d) 验证软件安全性需求对潜在失效提供了正确的响应,需要考虑的方面包括:限制范围、相互依赖限制范围的逻辑关系、失序事件保护、表决逻辑、危险命令处理、定时问题、传感器或激励器失效、故障检测、隔离与恢复(FDIR)、容失效的切换逻辑、以及在需要时达到并维持某个安全状态的能力等;

e) 验证软件安全性需求包含为保证必须工作的功能而采取的措施;

f) 应提供文档化的验证结果,其中包括任何新标识的危险、危险原因和不适当分解的需求。

10.2.2.7 软件安全性需求分析的结果应在《软件需求规格说明》(见 GJB 438B-2009 规定)中以独立条款明确,并通过正式项目评审,纳入配置管理

10.2.3 注意事项

主要包括:

a) 应明确采用的分析技术;

b) 对未恰当分解的需求应上报,并在系统层次确定解决方案;

c) 必要时进行第三方独立分析。

如侵联删未允勿转:认证生态网 » 装备安全性工作通用要求- 软件安全性需求与分析

赞 (0) 打赏

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏