CN104899043A - 采用模块安全性分析获取软件安全性需求的方法 - Google Patents

Abstract

本发明涉及一种采用模块安全性分析获取软件安全性需求的方法，包括：针对每个子系统，根据子系统中需要进行安全性分析的需求开发模块，在计算机终端中建立对应的安全性分析模块；根据从数据库输入的功能性信息以及设计决策信息，对该子系统的系统软件或者特定软件进行安全性分析，生成危害分析模型；将软件安全性功能需求以及相应的设计决策输出给需求开发模块和设计开发模块，形成新的需求开发模块和设计开发模块。本发明建立一个适合多机构协同开发安全关键系统时，信息接口的设计；参照安全相关标准构建系统危害分析领域模型模板，以系统化和结构化方式支持安全分析人员分析系统危害和捕捉特定软件安全性需求。

Description

采用模块安全性分析获取软件安全性需求的方法

技术领域

本发明涉及计算机软件技术领域，尤其涉及一种采用模块安全性分析获取软件安全性需求的方法。

背景技术

软件需求从用户的角度描述了系统所需的行为、特性或属性，是用户和开发人员之间的桥梁。准确、完整的需求是指导系统后续分析、建模、开发和测试的根本依据。特别是在航空领域，机载软件安全性需求捕获的不完整可能会导致重大财产损失，破坏环境，甚至危及人身生命安全。因此对机载软件安全性需求获取的研究是十分必要和迫切的。

目前已有的研究及标准中定义的安全性需求识别过程都有一定的相似性，可概括为如图1所示的一个迭代过程：1)识别危害和失效模式；2)识别软件对危害的贡献；3)定义软件安全性需求来处理危害。4)对新识别到的需求做危害分析，识别危害和失效模式，回到步骤1)。

在众多标准中，ARP-4761是航空工业界广泛使用的一套安全评估标准，提供了一套较为完整的系统安全性评估过程。工程实践应用过程中，存在以下问题：

(1)缺乏准确、严谨的需求表达方式。危害分析的一个主要输入是系统开发初期的功能需求，功能需求描述的准确性、完整性对危害分析的有效性有很大影响。

(2)缺乏建立和维护软件安全性需求与系统功能性需求之间的追踪关系。标准提出了一套在系统开发各个阶段进行安全性评估分析的活动，目标并不在于建立这两类需求之间的追踪关系。可是软件安全性需求来自于系统危害分析，从软件开发过程中来说软件安全需求与系统需求的追踪关系至关重要。

(3)复杂系统开发过程中，由于契约等限制造成的信息不公开。复杂系统开发过程中，涉及多方机构。由于契约关系，相互之间信息接口没有规范的表达，从而使得安全性需求分析过程中，输入不完善，导致需求捕获不完整。

(4)缺乏对软件安全性需求合理的总结和分类整理。软件安全性需求的获取通常可从通用软件安全性需求的剪裁和特定软件安全性需求的获取两方面进行。通用软件安全性需求的剪裁是基于相关软件安全性标准，获取通用安全性需求清单，然后参照清单针对系统进行适用性剪裁。而现有的方法多是采用checklist来积累和表示故障清单，对于需求的总结则有所欠缺，特别是缺少对安全性需求的分类研究。吴雪提出的基于RUCM(restricted usecase modeling)的软件安全性需求描述方法i中，将软件安全性需求从故障角度分为三类。然而该分类忽略考虑安全完整性需求和设计约束。

发明内容

鉴于上述的分析，本发明旨在提供一种采用模块安全性分析获取软件安全性需求的方法，用以解决现有标准存在的问题。

本发明的目的主要是通过以下技术方案实现的：

本发明提供了一种采用模块安全性分析获取软件安全性需求的方法，包括：

针对每个子系统，根据子系统中需要进行安全性分析的需求开发模块，在计算机终端中建立对应的安全性分析模块；

安全性分析模块根据从数据库输入的功能性信息以及设计决策信息，对该子系统的系统软件或者特定软件进行安全性分析，即通过系统安全性需求映射、系统失效分析、软件失效分析来获取软件的安全性需求分析结果，生成危害分析模型；所述安全性需求分析结果包括：安全性功能需求以及相应的设计决策，

将软件安全性功能需求以及相应的设计决策输出给需求开发模块和设计开发模块，形成新的需求开发模块和设计开发模块，然后执行重复上一步骤，不断完善所述危害分析模型，直到分析结束。

进一步地，如果将某需求开发模块定义为复杂系统中的某子系统，相应的设计开发模块、安全性分析模块即针对该子系统分析；该子系统在需求开发和设计开发时，仅对其他子系统公开部分信息，并同时依赖于其他子系统的公开信息；相应的，针对该子系统的安全性分析模块也仅向其他子系统的安全性分析模块公开部分信息，并同时依赖于其他子系统的安全性分析模块的公开信息。

进一步地，实现子系统安全性需求映射的过程包括：

子系统安全性需求映射通过需求追踪特性和建立需求设计映射表实现：

需求追踪特性即在每个需求描述模块，增添“追踪性”属性，追踪该需求是从哪个需求分解而来，或者是由什么原因派生出来；

建立需求设计映射表，至少包括：“安全性需求”和“设计决策”两个表项。

进一步地，当需求开发模块的层次为系统层时，系统失效分析采取自上而下的过程，即

从数据库中调入需求开发模块的功能描述；

针对该需求开发模块，调入其运行上下文，至少包括功能运行阶段、环境配置和状况、交互功能；

根据调入的上下文，分析其可能发生的失效；

对每个失效，分析其造成的影响，并对失效影响按等级分类；

采用FTA方法，识别失效原因；

分析获得安全性需求来消除失效，或降低失效影响，将该安全性需求加入到需求/设计映射表中“安全性需求”一栏；

基于上述安全性需求，分析出设计决策，将设计决策加入到需求/设计映射表中“设计决策”一栏；

输出安全性分析结果。

进一步地，当所述软件功能模块的层次为系统层时，软件失效分析采取自下而上的过程，即

确定待分析的需求开发模块以及该需求开发模块的所有部件；

从数据库调入所有部件的运行上下文，至少包括功能模块、功能运行阶段、环境配置和状况、交互功能；

针对所有部件，分析其可能发生的故障，并针对每个故障，分析其可能产生的故障影响；

提出安全性需求来消除或减弱故障影响，将该安全性需求加入到需求/设计映射表中“安全性需求”一栏；

基于上述安全性需求，分析出设计决策，将设计决策加入到需求/设计映射表中“设计决策”一栏；

输出安全性分析结果。

进一步地，设置所述安全性分析模块与其他模块的信息接口，所述信息接口至少包括以下一种：

模块上下文接口是，输出或引入对需求开发模块和设计开发模块的引用的说明，对安全性分析模块的边界和限制的说明以及一些假设；

失效接口，输出或引用该子系统或该子系统某部分功能缺失或者功能故障；

安全性需求接口，输出安全性需求分析结果或者引用其他安全分析模块的安全性需求分析结果。

进一步地，所述模块上下文接口包括：

分析模块上下文：每个安全性分析模块针对某个需求开发模块和设计开发模块，需要对输入进行声明，并指明安全性分析模块的边界和限制，安全性分析模块的运行周期以及运行阶段，当前的分析层级；

其他模块上下文引用：对当前关注的需求开发模块和设计开发模块进行安全性分析时，其上下文配置要求与另一个安全性分析模块的某上下文配置相同，引用其他安全性分析模块上下文的方式填写本安全性分析模块上下文。

其中，所述失效接口包括：

已处理失效：安全性分析模块识别到的失效，依据具体情况选择是否公开，如果公开，则在安全性分析模块接口处要列出相应信息；

失效引用：安全性分析模块识别到的某个失效，由于该失效的后续分析较为复杂，或者在其他安全性分析模块已对该失效分析，则该失效不在本安全性分析模块展开分析，而是在其他安全性分析模块中展开分析，此处只需引用其他安全性分析模块的相应失效说明即可。

所述安全性需求接口包括：

安全性需求：针对需要进行安全性分析的需求开发模块提出的安全性需求分析结果；

安全性引用：引用其他安全性分析模块提取的安全性需求分析结果。

本发明有益效果如下：

本发明采用分析模块信息封装，对外设计接口的方式，可以更好得管理信息数据，使得不同机构协同开发时，交流通讯更为便利，有利于更好的执行模块内安全性需求分析。

本发明的其他特征和优点将在随后的说明书中阐述，并且，部分的从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

附图仅用于示出具体实施例的目的，而并不认为是对本发明的限制，在整个附图中，相同的参考符号表示相同的部件。

图1为本发明实施例所述方法的流程示意图；

图2为本发明实施例中，安全性分析过程与系统需求开发和设计开发的示意图；

图3为本发明实施例中，安全性分析模块信息接口的示意图。

具体实施方式

下面结合附图来具体描述本发明的优选实施例，其中，附图构成本申请一部分，并与本发明的实施例一起用于阐释本发明的原理。

如图1所示，图1为本发明实施例所述方法的流程示意图，具体可以包括：

步骤101：针对每个子系统，根据子系统中需要进行安全性分析的需求开发模块，建立对应的安全性分析模块；

如图2所示，安全性分析过程与系统需求开发和设计开发过程并行进行，并与之有密切的对应关系。需求开发开展到一定程度后，依据需求进行设计(概要设计、详细设计)。设计开发应当满足需求开发，需要对此进行验证。需求开发和设计开发是安全性分析的输入，然后采用安全性分析方法对输入分析。而安全性分析过程中，会产生新的安全性需求，由安全性需求会确定新的设计决策。最后这个过程迭代进行。

安全性需求的获取通过安全性分析过程获得，而最终安全性需求和功能需求统一进行管理。这样的设计既能保证对安全性需求的充分考虑，特殊对待；同时统一管理可以方便得将安全性需求与相关的功能需求关联起来；此外，安全性需求，特别是安全性功能需求也可以像一般功能需求一样，作为输入，采用安全性分析的方法进行再次分析。因此，我们提出针对输入构建安全性分析模块，即需求开发模块、设计开发模块、安全性分析模块之间存在对应关系。如果将某需求开发模块定义为复杂系统中的某子系统，相应的设计开发模块、安全性分析模块即针对该子系统分析。该子系统在需求开发和设计开发时，仅对其他子系统公开部分信息，并同时依赖于其他子系统的公开信息。相应的，针对该子系统的安全性分析模块也仅向其他子系统的安全性分析模块公开部分信息，并同时依赖于其他子系统的安全性分析模块的公开信息。

步骤102：安全性分析模块根据输入的功能性信息以及设计决策信息，对该子系统的系统软件或者特定软件进行安全性分析，即通过子系统安全性需求映射、系统失效分析、软件失效分析来获取软件安全性功能需求以及相应的设计决策，形成该子系统的危害分析模型和并根据输出需要构建信息接口；

步骤102-1：对该子系统的系统软件或者特定软件进行安全性分析，即通过子系统安全性需求映射、系统失效分析、软件失效分析来获取软件安全性功能需求以及相应的设计决策，从而生成危害分析模型；

(1)安全性需求映射

子系统安全性需求映射通过需求追踪特性和需求设计映射表实现，具体包括：

需求追踪特性即在建立需求描述模块，在每个需求描述模块中增添“追踪性”属性，追踪该需求是从哪个需求分解而来，或者是由什么原因派生出来。这里需求描述模块采用RUCM的use case template的方法，对普通用例描述模板进行扩充，添加追踪性特性。扩充后的用例描述模板如表1所示。在需求分析层次深入时，需要建立需求与需求之间的追踪关系。特别的，系统规定了对软件的高层需求，在软件开发初期，需求分析人员需要将这些软件高层需求向下层映射，并建立下层需求与高层需求之间的追踪关系。而一部分软件安全性需求就是从软件高层安全性需求映射而来。

表1RUCM用例规约模板

此外，由图2的分析可知，需求确定设计，设计反过来需要满足需求，因此在设计过程中，建立需求和设计的追踪关系非常重要。需求设计映射表如表格1所示，每个设计决策基于特定安全性需求，并指明设计决策做出的理由。这样的设计一方面可以追踪需求和设计的关系，另一方面，由此便于后期验证设计满足了需求。需求/设计映射表是建议在设计过程中应当维护的表格，主要包括：安全性需求和设计决策两栏，还可以增加评注一栏。在此表述，以表明追踪的完整性。

表格1需求/设计映射表

安全性需求	设计决策	评注

(2)系统失效分析

系统失效分析是一个自上而下的过程，在设计还不清晰时，根据初期的功能模块设计，做功能失效分析，识别顶层失效，分析失效影响，确定失效状况分类，并提出相应的安全性需求。由此安全性需求，做出相应的设计决策，进而依据细化的需求和设计，进一步做失效分析，识别更多的失效及相应的安全性需求。此过程迭代进行，直至无法找到新的失效，系统安全性需求饱和。该过程采用FTA(fault tree analysis)方法来识别失效。

分析过程如下：

从数据库中调入需要进行安全分析的需求开发模块的功能描述；

针对该需求开发模块，调入其运行上下文，包括功能运行阶段、环境配置和状况、交互功能等；

根据调入的上下文，分析其可能发生的失效；

对每个失效，分析其造成的影响；

对失效影响按等级分类；

采用FTA方法，识别失效原因；

分析获得安全性需求来消除失效，或降低失效影响，将该安全性需求加入到需求/设计映射表中“安全性需求”一栏；

基于上述安全性需求，分析出设计决策，将设计决策加入到需求/设计映射表中“设计决策”一栏；

将安全性分析结果作为输出，输出给需求功开发模块，作为新的需求开发模块和设计开发模块，实现该分析过程的迭代进行。

其中，过程中识别到的所有失效都采用表格2方式进行描述：

表格2失效故障分析表

表格中各元素含义如下：

■失效：指该需求开发模块无法提供要求的功能，或者该需求开发模块的运行与要求不符，亦即任何该需求开发模块无法提供预期功能的状况。

■功能模块：当前失效分析针对的功能需求开发模块。

■运行上下文：对当前分析功能运行阶段、运行环境等说明。

■假设：分析过程中提出的任何没有证据的声明、原则、前提都属于假设。建议将假设专门管理，采用如表格3所述形式。该信息将作为该安全性分析模块的“假设”接口信息对外提供。功能模块、运行上下文及假设将一同作为该安全性分析模块的“分析模块上下文”接口信息对外提供。

表格3假设管理表

假设	提出上下文	提出者	验证	验证者

■失效原因：这是一个逻辑表达式，由故障和逻辑符号构成。故障是可能导致某功能单元无法提供预期功能的异常状况。当在更高层次分析时，前述失效可能就表现为故障。

■失效影响：失效对系统或某条目的功能、运行、状态产生的影响。

■失效影响分类等级：即失效影响的严重情况。这里参照DO-178C，将失效等级分为五类：Level-A(灾难性的)、Level-B(危害的/严重的)、Level-C(较重的)、Level-D(较轻的)、Level-E(无影响的)。对于不同级别，分析人员应给与不同程度的关注。

■故障处理措施：为消除或降低该失效发生概率及影响的措施。评注：对该分析过程的任何说明，包括确定失效分类等级的依据。

(3)软件失效分析

软件失效分析是自下而上的过程，随着安全性分析模块的内部设计越来越清晰，分析需求开发模块内所有可能出错的部件，并向上分析这种故障可能导致的失效，从而建立一种逆向的追踪链。这个过程采用FMEA(failure mode and effects analysis)方法识别故障。

分析过程步骤如下：

确定待分析的需求开发模块以及该需求开发模块的所有部件；

从数据库中调入所有部件的运行上下文，包括功能模块、功能运行阶段、环境配置和状况、交互功能等；

针对所有部件，分析其可能发生的故障；

针对每个故障，分析其可能产生的故障影响；

提出安全性需求来消除或减弱故障影响，将该安全性需求加入到需求/设计映射表中“安全性需求”一栏；

基于上述安全性需求，分析出设计决策，将设计决策加入到需求/设计映射表中“设计决策”一栏；

将安全性分析结果作为输出，输出给需求功开发模块和设计开发模块，作为新的需求开发模块和设计开发模块，实现该分析过程的迭代进行。

其中，过程中识别到的故障采用表格4所示格式描述，将故障影响作为新的失效，总结所有可能产生该故障影响的故障，作为失效原因。如果该故障影响(新的失效)在失效故障分析表中已存在，对原信息进行补充完善；如果不存在，则纳入失效故障分析表。

表格4故障失效分析表

这个表与系统危害分析过程中的统计表基本相似，但是有以下几个不同：

功能部件：是软件失效分析的分析对象。它针对的不是功能，而是功能模块内的部件。一个功能单元内的前置条件、后置条件、检测语句、执行语句等所有成分都可以作为模块部件进行分析。

运行上下文：是模块部件的上下文介绍，主要是指针对的需求开发模块。

故障：即该模块部件可能出现的异常条件。对每个功能部件的故障可以采用HAZOP方法，依照引导词，分析各部件可能存在的导致不利后果的偏差，即故障。采用的引导词和其含义如表格5所示。

表格5引导词及其含义

步骤102-2：安全性分析过程中，根据输出需要构建安全性分析模块的信息接口；

如图3所示，图3为安全性分析模块信息接口的示意图，该信息接口包括以下三类：

(1)上下文接口

上下文包括对安全分析对象的说明，即对需求开发模块和设计开发模块的引用的说明，对安全性分析模块的边界和限制的说明，以及一些假设。

本发明实施例中，上下文接口分为两种类型：

每个安全性分析模块针对某个需求开发模块和设计开发模块，需要对输入(需求和设计)进行声明，并指明安全性分析模块的边界和限制，这里边界和限制例如安全性分析模块运行环境配置(如果这个不确定，可能作为假设提出)，安全性分析模块的运行周期以及运行阶段，当前的分析层级等，图3中表现为“分析模块上下文”。

对当前关注的需求开发模块和设计开发模块进行安全性分析时，其上下文配置可能要求与另一个安全性分析模块的某上下文配置相同，此时采用引用其他安全性分析模块上下文的方式填写本安全性分析模块上下文，图3中表现为“其他模块上下文引用”。

注意这里，分析模块上下文既包括安全性分析模块的引用声明，也包括安全性分析模块的边界和限制说明，从而对某需求开发模块可能对应多个安全性分析模块，每个安全性分析模块要求的模块边界和限制不一致。此外，分析过程中提出的任何没有证据的声明、原则、前提都属于假设。例如对系统运行环境配置的假设。由于各模块开发过程的信息不公开，或者在当前的分析层次所能确定的信息不足，对当前分析模块做出假设非常重要。所有的假设都应当在后期尽可能被验证(不能被验证的假设应当作为系统声明或前提对外公布)，并追踪假设、假设的提出者、假设的验证者、验证方法、验证结果之间的关系。

(2)失效接口

指功能缺失，或者子系统或子系统某部分发生功能故障。失效强调需求开发模块的故障，是安全性分析中的重要概念。安全性分析中首先要提取子系统可能出现的各种失效，并针对每个失效做深度分析，提取相应的安全性需求。因此失效与安全性需求密切相关，是安全性信息的重要组成部分，应当在模型接口处表明。

本发明实施例中，失效接口分为两种类型：

安全性分析模块识别到的失效，依据具体情况选择是否公开，如果公开，则在安全性分析模块接口处要列出相应信息，对应图3中的“已处理失效”。

同时安全性分析模块识别到的某个失效，由于该失效的后续分析较为复杂，或者在其他安全性分析模块已对该失效分析，则该失效不在本安全性分析模块展开分析，而是在其他安全性分析模块中展开分析，此处只需引用其他安全性分析模块的相应失效说明即可，对应图3中的“失效引用”。

(3)安全性需求接口

本发明实施例中，安全性需求接口也分为两种类型：

安全性需求是安全性分析模块的主要目的和输出，即针对该安全分析对象提出的安全性需求，图3中表现为“安全性需求”。

某些安全性需求提出后，可用于解决多个失效，因此本安全性分析模块识别的失效可能引用其他分析模块提取的安全性需求来处理。此外，虽然功能需求和安全性需求统一进行管理，但安全性分析时，如果依赖于其他安全性需求，那么该安全性分析模块分析获得的安全性需求的安全等级会受其他安全性需求的安全等级影响，同时也影响其他安全性需求的安全等级。因此这里将对其他安全性分析模块安全性需求的引用特地指出，以引起足够重视，图3中表现为“安全性需求引用”。

图3中指向安全性分析模块内部的矩形接口表示对其他安全性分析模块此类信息的引用，指向安全性分析模块外部的矩形接口表示对本安全性分析模块此类公开信息的声明。注意，这三类信息可以在分析的任何时刻获得，但是仅依据情况确定是公开的信息，才在安全性分析模块边界处向其他安全性分析模块声明。

步骤103：将安全性需求分析结果通过对外信息接口进行输出，这里的输出主要就是安全性功能需求以及相应的设计决策，还包括其他一些可供其他安全性分析模块调用的信息。

综上所述，本发明实施例提供了一种采用模块安全性分析获取软件安全性需求的方法，解决如下问题：

采用分析模块信息封装，对外设计接口的方式，可以更好得管理信息数据，使得不同机构协同开发时，交流通讯更为便利，有利于更好的执行模块内安全性需求分析。

对安全性需求合理分类，使得在需求获取过程中，需求的追踪链更容易建立，并且有利于进一步抽取各类安全性需求的特性，从而有利于安全性需求的部分自动化获取。

对通用安全性需求进行总结，可以在安全性需求分析时借鉴参考，加快需求提取过程。

系统危害分析和软件失效分析相结合，建立双向安全性需求追踪链，可以进一步保证安全性需求获取的完整性。

建立安全性分析模型，可以为以后复用，并为安全性需求获取、描述、验证的自动化提供基本条件。

本领域技术人员可以理解，实现上述实施例方法的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于计算机可读存储介质中。其中，所述计算机可读存储介质为磁盘、光盘、只读存储记忆体或随机存储记忆体等。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。

Claims (9)

1.一种采用模块安全性分析获取软件安全性需求的方法，其特征在于，包括：

针对每个子系统，根据子系统中需要进行安全性分析的需求开发模块，在计算机终端中建立对应的安全性分析模块；

安全性分析模块根据从数据库输入的功能性信息以及设计决策信息，对该子系统的系统软件或者特定软件进行安全性分析，即通过系统安全性需求映射、系统失效分析、软件失效分析来获取软件的安全性需求分析结果，生成危害分析模型；所述安全性需求分析结果包括：安全性功能需求以及相应的设计决策，

将软件安全性功能需求以及相应的设计决策输出给需求开发模块和设计开发模块，形成新的需求开发模块和设计开发模块，然后执行重复上一步骤，不断完善所述危害分析模型，直到分析结束。

2.根据权利要求1所述的方法，其特征在于，如果将某需求开发模块定义为复杂系统中的某子系统，相应的设计开发模块、安全性分析模块即针对该子系统分析；该子系统在需求开发和设计开发时，仅对其他子系统公开部分信息，并同时依赖于其他子系统的公开信息；相应的，针对该子系统的安全性分析模块也仅向其他子系统的安全性分析模块公开部分信息，并同时依赖于其他子系统的安全性分析模块的公开信息。

3.根据权利要求1或2所述的方法，其特征在于，实现子系统安全性需求映射的过程包括：

子系统安全性需求映射通过需求追踪特性和建立需求设计映射表实现：

需求追踪特性即在每个需求描述模块，增添“追踪性”属性，追踪该需求是从哪个需求分解而来，或者是由什么原因派生出来；

建立需求设计映射表，至少包括：“安全性需求”和“设计决策”两个表项。

4.根据权利要求1或2或3所述的方法，其特征在于，当需求开发模块的层次为系统层时，系统失效分析采取自上而下的过程，即

从数据库中调入需求开发模块的功能描述；

针对该需求开发模块，调入其运行上下文，至少包括功能运行阶段、环境配置和状况、交互功能；

根据调入的上下文，分析其可能发生的失效；

对每个失效，分析其造成的影响，并对失效影响按等级分类；

采用FTA方法，识别失效原因；

分析获得安全性需求来消除失效，或降低失效影响，将该安全性需求加入到需求/设计映射表中“安全性需求”一栏；

基于上述安全性需求，分析出设计决策，将设计决策加入到需求/设计映射表中“设计决策”一栏；

输出安全性分析结果。

5.根据权利要求1或2或3或4所述的方法，其特征在于，当所述软件功能模块的层次为系统层时，软件失效分析采取自下而上的过程，即

确定待分析的需求开发模块以及该需求开发模块的所有部件；

从数据库调入所有部件的运行上下文，至少包括功能模块、功能运行阶段、环境配置和状况、交互功能；

针对所有部件，分析其可能发生的故障，并针对每个故障，分析其可能产生的故障影响；

提出安全性需求来消除或减弱故障影响，将该安全性需求加入到需求/设计映射表中“安全性需求”一栏；

基于上述安全性需求，分析出设计决策，将设计决策加入到需求/设计映射表中“设计决策”一栏；

输出安全性分析结果。

6.根据权利要求1所述的方法，其特征在于，设置所述安全性分析模块与其他模块的信息接口，所述信息接口至少包括以下一种：

模块上下文接口是，输出或引入对需求开发模块和设计开发模块的引用的说明，对安全性分析模块的边界和限制的说明以及一些假设；

失效接口，输出或引用该子系统或该子系统某部分功能缺失或者功能故障；

安全性需求接口，输出安全性需求分析结果或者引用其他安全分析模块的安全性需求分析结果。

7.根据权利要求6所述的方法，其特征在于，所述模块上下文接口包括：

分析模块上下文：每个安全性分析模块针对某个需求开发模块和设计开发模块，需要对输入进行声明，并指明安全性分析模块的边界和限制，安全性分析模块的运行周期以及运行阶段，当前的分析层级；

其他模块上下文引用：对当前关注的需求开发模块和设计开发模块进行安全性分析时，其上下文配置要求与另一个安全性分析模块的某上下文配置相同，引用其他安全性分析模块上下文的方式填写本安全性分析模块上下文。

8.根据权利要求6或7所述的方法，其特征在于，所述失效接口包括：

已处理失效：安全性分析模块识别到的失效，依据具体情况选择是否公开，如果公开，则在安全性分析模块接口处要列出相应信息；

失效引用：安全性分析模块识别到的某个失效，由于该失效的后续分析较为复杂，或者在其他安全性分析模块已对该失效分析，则该失效不在本安全性分析模块展开分析，而是在其他安全性分析模块中展开分析，此处只需引用其他安全性分析模块的相应失效说明即可。

9.根据权利要求6或7或8所述的方法，其特征在于，所述安全性需求接口包括：

安全性需求：针对需要进行安全性分析的需求开发模块提出的安全性需求分析结果；

安全性引用：引用其他安全性分析模块提取的安全性需求分析结果。