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) 必要时进行第三方独立分析。
