采用模块安全性分析获取软件安全性需求的方法
【技术领域】
[0001] 本发明涉及计算机软件技术领域，尤其涉及一种采用模块安全性分析获取软件安 全性需求的方法。
【背景技术】
[0002] 软件需求从用户的角度描述了系统所需的行为、特性或属性，是用户和开发人员 之间的桥梁。准确、完整的需求是指导系统后续分析、建模、开发和测试的根本依据。特别 是在航空领域，机载软件安全性需求捕获的不完整可能会导致重大财产损失，破坏环境，甚 至危及人身生命安全。因此对机载软件安全性需求获取的研宄是十分必要和迫切的。
[0003] 目前已有的研宄及标准中定义的安全性需求识别过程都有一定的相似性，可概括 为如图1所示的一个迭代过程：1)识别危害和失效模式；2)识别软件对危害的贡献；3)定 义软件安全性需求来处理危害。4)对新识别到的需求做危害分析，识别危害和失效模式，回 到步骤1)。
[0004] 在众多标准中，ARP-4761是航空工业界广泛使用的一套安全评估标准，提供了一 套较为完整的系统安全性评估过程。工程实践应用过程中，存在以下问题：
[0005] (1)缺乏准确、严谨的需求表达方式。危害分析的一个主要输入是系统开发初期的 功能需求，功能需求描述的准确性、完整性对危害分析的有效性有很大影响。
[0006] (2)缺乏建立和维护软件安全性需求与系统功能性需求之间的追踪关系。标准提 出了一套在系统开发各个阶段进行安全性评估分析的活动，目标并不在于建立这两类需求 之间的追踪关系。可是软件安全性需求来自于系统危害分析，从软件开发过程中来说软件 安全需求与系统需求的追踪关系至关重要。
[0007] (3)复杂系统开发过程中，由于契约等限制造成的信息不公开。复杂系统开发过程 中，涉及多方机构。由于契约关系，相互之间信息接口没有规范的表达，从而使得安全性需 求分析过程中，输入不完善，导致需求捕获不完整。
[0008] (4)缺乏对软件安全性需求合理的总结和分类整理。软件安全性需求的获取通 常可从通用软件安全性需求的剪裁和特定软件安全性需求的获取两方面进行。通用软件 安全性需求的剪裁是基于相关软件安全性标准，获取通用安全性需求清单，然后参照清 单针对系统进行适用性剪裁。而现有的方法多是采用checklist来积累和表示故障清 单，对于需求的总结则有所欠缺，特别是缺少对安全性需求的分类研宄。吴雪提出的基于 RUCM(restrictedusecasemodeling)的软件安全性需求描述方法i中，将软件安全性需求 从故障角度分为三类。然而该分类忽略考虑安全完整性需求和设计约束。
【发明内容】
[0009] 鉴于上述的分析，本发明旨在提供一种采用模块安全性分析获取软件安全性需求 的方法，用以解决现有标准存在的问题。
[0010] 本发明的目的主要是通过以下技术方案实现的：
[0011] 本发明提供了一种采用模块安全性分析获取软件安全性需求的方法，包括：
[0012] 针对每个子系统，根据子系统中需要进行安全性分析的需求开发模块，在计算机 终端中建立对应的安全性分析模块；
[0013] 安全性分析模块根据从数据库输入的功能性信息以及设计决策信息，对该子系统 的系统软件或者特定软件进行安全性分析，即通过系统安全性需求映射、系统失效分析、软 件失效分析来获取软件的安全性需求分析结果，生成危害分析模型；所述安全性需求分析 结果包括：安全性功能需求以及相应的设计决策，
[0014] 将软件安全性功能需求以及相应的设计决策输出给需求开发模块和设计开发模 块，形成新的需求开发模块和设计开发模块，然后执行重复上一步骤，不断完善所述危害分 析模型，直到分析结束。
[0015] 进一步地，如果将某需求开发模块定义为复杂系统中的某子系统，相应的设计开 发模块、安全性分析模块即针对该子系统分析；该子系统在需求开发和设计开发时，仅对其 他子系统公开部分信息，并同时依赖于其他子系统的公开信息；相应的，针对该子系统的安 全性分析模块也仅向其他子系统的安全性分析模块公开部分信息，并同时依赖于其他子系 统的安全性分析模块的公开信息。
[0016] 进一步地，实现子系统安全性需求映射的过程包括：
[0017] 子系统安全性需求映射通过需求追踪特性和建立需求设计映射表实现：
[0018] 需求追踪特性即在每个需求描述模块，增添"追踪性"属性，追踪该需求是从哪个 需求分解而来，或者是由什么原因派生出来；
[0019] 建立需求设计映射表，至少包括："安全性需求"和"设计决策"两个表项。
[0020] 进一步地，当需求开发模块的层次为系统层时，系统失效分析采取自上而下的过 程，即
[0021] 从数据库中调入需求开发模块的功能描述；
[0022] 针对该需求开发模块，调入其运行上下文，至少包括功能运行阶段、环境配置和状 况、交互功能；
[0023] 根据调入的上下文，分析其可能发生的失效；
[0024] 对每个失效，分析其造成的影响，并对失效影响按等级分类；
[0025] 采用FTA方法，识别失效原因；
[0026] 分析获得安全性需求来消除失效，或降低失效影响，将该安全性需求加入到需求/ 设计映射表中"安全性需求" 一栏；
[0027] 基于上述安全性需求，分析出设计决策，将设计决策加入到需求/设计映射表中 "设计决策" 一栏；
[0028] 输出安全性分析结果。
[0029] 进一步地，当所述软件功能模块的层次为系统层时，软件失效分析采取自下而上 的过程，即
[0030] 确定待分析的需求开发模块以及该需求开发模块的所有部件；
[0031] 从数据库调入所有部件的运行上下文，至少包括功能模块、功能运行阶段、环境配 置和状况、交互功能；
[0032] 针对所有部件，分析其可能发生的故障，并针对每个故障，分析其可能产生的故障 影响；
[0033] 提出安全性需求来消除或减弱故障影响，将该安全性需求加入到需求/设计映射 表中"安全性需求" 一栏；
[0034] 基于上述安全性需求，分析出设计决策，将设计决策加入到需求/设计映射表中 "设计决策" 一栏；
[0035] 输出安全性分析结果。
[0036] 进一步地，设置所述安全性分析模块与其他模块的信息接口，所述信息接口至少 包括以下一种：
[0037] 模块上下文接口是，输出或引入对需求开发模块和设计开发模块的引用的说明， 对安全性分析模块的边界和限制的说明以及一些假设；
[0038] 失效接口，输出或引用该子系统或该子系统某部分功能缺失或者功能故障；
[0039] 安全性需求接口，输出安全性需求分析结果或者引用其他安全分析模块的安全性 需求分析结果。
[0040] 进一步地，所述模块上下文接口包括：
[0041] 分析模块上下文：每个安全性分析模块针对某个需求开发模块和设计开发模块， 需要对输入进行声明，并指明安全性分析模块的边界和限制，安全性分析模块的运行周期 以及运行阶段，当前的分析层级；
[0042] 其他模块上下文引用：对当前关注的需求开发模块和设计开发模块进行安全性分 析时，其上下文配置要求与另一个安全性分析模块的某上下文配置相同，引用其他安全性 分析模块上下文的方式填写本安全性分析模块上下文。
[0043] 其中，所述失效接口包括：
[0044] 已处理失效：安全性分析模块识别到的失效，依据具体