软件工程课件 09关键系统规格说明

关键系统规格说明CriticalSystemsSpecification关键系统规格说明CriticalSystemsSpeci1关键系统规格说明开发一个系统可获性，可靠性，安全性和保密性的规格说明的过程和技术（Processesandtechniquesfordevelopingaspecificationforsystemavailability,reliability,safetyandsecurity）关键系统规格说明开发一个系统可获性，可靠性，安全性和保密性的2Objectives说明如何通过分析关键系统所面临的风险来识别出系统的可信度需求。说明如何从系统的风险分析中获得安全需求。解释保密性需求的来历。描述用作可靠性规格说明的测量尺度。Objectives说明如何通过分析关键系统所面临的风险来识3Topicscovered基于风险驱动的规格说明安全性规格说明保密性规格说明软件可靠性规格说明Topicscovered基于风险驱动的规格说明4可信度需求用功能需求来定义差错检查、恢复工具和对系统失效的防范措施。用非功能需求来定义系统所需要的可获性和可靠性。用排它需求来定义千万不能发生的状态和条件。可信度需求用功能需求来定义差错检查、恢复工具和对系统失效的防5基于风险驱动的规格说明关键系统的规格说明应该是由风险驱动的（risk-driven）。该方法已经在安全和保密性至关重要的系统上广泛使用。规格说明过程的目标应该在于了解系统所面临的风险以及说明降低这些风险的需要做的事情。基于风险驱动的规格说明关键系统的规格说明应该是由风险驱动的（6风险分析的步骤风险识别（Riskidentification）识别出可能发生的潜在风险。风险分析和分类（Riskanalysisandclassification）评估每个风险的严重程度风险分解（Riskdecomposition）找出风险的潜在根源降低风险评估（Riskreductionassessment）说明在系统设计阶段如何消除和降低每一个风险。风险分析的步骤风险识别（Riskidentificatio7基于风险的规格说明基于风险的规格说明8风险识别识别出关键系统所面临的风险。在安全性关键的系统中，风险就是那些能够导致意外的危险。在保密性关键的系统中，风险就是那些对系统的潜在攻击。在风险识别中，需要识别出风险的类型及风险在这些分类中的地位服务失效；电气上的风险；…风险识别识别出关键系统所面临的风险。9胰岛素泵的风险胰岛素过量（服务失效）。胰岛素剂量不足（服务失效）。由于电池耗尽引起的电源故障（电气的）与其它医疗设备的电气接口（电气的）。传感器和致动器的接触很差（物理的）。在体内的机器部件脱落（物理的）。由于引入机器而导致感染（生物的）。对原料或胰岛素的过敏反应（生物的）。胰岛素泵的风险胰岛素过量（服务失效）。10风险分析和分类包含对发生一个风险的可能性以及对将要发生的一个意外或事故的潜在后果的理解把风险分类为：不可接受的（Intolerable）。必须不能让它发生或不能让它引起一个意外。在实际许可下尽可能低的（ALARP）。在给定成本和进度的限制下，必须使风险的可能性降到最小。可以接受的（Acceptable）。风险的后果是可以接受的，并且不需要付出额外的成本来降低危险的可能性。风险分析和分类包含对发生一个风险的可能性以及对将要发生的一个11风险级别风险级别12风险的社会接受度一个风险的接受度是被社会和政治的因素所左右的。在大多数社会而言，随着时间的推移，上面的三角形区域中的两条边界会逐渐向上靠，也就是说，社会越来越不愿意接收风险例如，虽说清除污染的成本可能会小于预防成本，但这可能不为社会所接受。风险评估是主观的风险被认定为类似于“大概的”，“可能的”等等。这取决于由谁来进行评估。风险的社会接受度一个风险的接受度是被社会和政治的因素所左右的13风险评估评估风险的可能性和严重程度。通常不可能很精确，因此用一些相对值表达，例如“不太可能的”、“很少的”、“很高的”等等。目标是排除那些最有可能发生的或者是后果严重的风险。风险评估评估风险的可能性和严重程度。14胰岛素泵的风险评估胰岛素泵的风险评估15风险分解（decomposition）在一个特定的系统里，找出风险的主要原因（rootcauses）技术大多来源于安全性关键的系统，并可以是：归纳法（Inductive），自下而上的技术。从提出的一个系统失效开始，评估由该失效可能导致的危险。演绎法（Deductive），自上而下的技术。以一个危险为起点，推断出可能引起它原因是什么。风险分解（decomposition）在一个特定的系统里，找16失误-树（Fault-tree）分析一种自上而下的演绎法技术。把风险或危险放在树的根上，再找出可以导致该危险的系统状态。在合适的地方加入‘and’或‘or’条件。目标应该是使引起系统失效的单一原因（singlecauses）的数量降至最低。失误-树（Fault-tree）分析一种自上而下的演绎法技术17胰岛素泵的失误-树胰岛素泵的失误-树18降低风险的评估这个过程的目标是识别出可信度需求，即说明应该如何管理风险以及确保不会发生意外和事故。降低风险的策略（strategies）风险规避（Riskavoidance）；风险检测与排除（Riskdetectionandremoval）；危害限制（Damagelimitation）。降低风险的评估这个过程的目标是识别出可信度需求，即说明应该如19策略应用（Strategyuse）通常在关键系统上要综合使用降低风险的策略。在一个化工厂的控制系统中，它含有检测和校正反应器过压的传感器。然而，它也含有一个单独的保护系统，以便在检测到危险高压后打开某个安全阀（reliefvalve）。策略应用（Strategyuse）通常在关键系统上要综合使20胰岛素泵的软件风险算术误差（Arithmeticerror）一个计算导致一个变量值上溢（overflow）和下溢（underflow）；可能包含一个对每类算术误差的例外句柄（exceptionhandler）。算法误差（Algorithmicerror）把将要分发的剂量与前次剂量或与安全最小剂量进行比较。如果剂量太高则要降低它。胰岛素泵的软件风险算术误差（Arithmeticerror21胰岛素泵的安全需求SR1：每次注射剂量不能超过系统用户的指定最大量。SR2：每天注射的累计剂量不能超过系统用户的指定最大量。SR3：系统应该含有一个硬件诊断设施，每小时至少执行4次。SR4：系统应该含有一个可以针对所有已经识别的例外的处理程序。SR5：当发现任何硬件和软件的异常以及收到诊断信息的时候，发出声音警报。SR6：在系统警报时，胰岛素注射应该中止，直到用户消除警报和进行系统复位为止。胰岛素泵的安全需求SR1：每次注射剂量不能超过系统用户的指定22安全性规格说明一个系统的安全性需求应该分别进行说明。这些需求应该建立在对风险和对可能发生的危险的分析基础上。安全性需求通常被应用于一个系统的整体而不是个别的子系统。在系统工程术语中，一个系统的安全性是一种自然特性（emergentproperty）。安全性规格说明一个系统的安全性需求应该分别进行说明。23国际电工委员会标准(IEC61508)是一项专门为保护系统而设计的安全管理国际标准，它并不适用于所有的安全性关键的系统。它结合了一个安全生命周期模型，涵盖了从范围定义到系统退役的所有安全管理的方面。国际电工委员会标准(IEC61508)是一项专门为保护系24控制系统的安全需求控制系统的安全需求25©IanSommerville2000 Dependablesystemsspecification Slide26安全生命周期©IanSommerville2000 Dependa26安全性需求功能安全性需求（Functionalsafetyrequirements）这些需求定义了保护系统的安全功能，即定义了系统应该提供什么样的保护。安全完整性需求（Safetyintegrityrequirements）这些需求定义了保护系统的可获性和可靠性。它们以预期的用法为基础并且采用从一至四个安全完整性级别进行分类。安全性需求功能安全性需求（Functionalsafety27保密性规格说明与安全性规格说明有些相似对保密性需求进行定量规格说明是不可能的；需求常常用“不应该”而不是用“应该”来描述。差别对一个保密性管理的生命周期还没有定义完备的观念。它没有标准；只有一般性的威胁而没有系统特定的危险；具有成熟的保密技术（加密，等等）。然而，当把这些技术转化到一般性的用途上的时候就会出现问题；单独的供应商（微软）的主导地位意味着大量的系统可能会受到保密性失效的影响。保密性规格说明与安全性规格说明有些相似28保密性规格说明过程保密性规格说明过程29保密性规格说明步骤财产识别和估值识别出财产（数据和程序）和它们所需要的保护程度。保护程度依赖于财产的价值，因此一个密码文件要比一组公共网页更有价值。威胁分析和风险评估要识别出可能发生的保密性威胁，并要估计到与每个这种威胁有关的风险。威胁分配把已经识别的威胁与财产联系起来，这样就可以就每个已经识别的财产列出一张与威胁关联的表格。保密性规格说明步骤财产识别和估值30Stagesinsecurityspecification技术分析对获得的保密技术及其是否可用在识别出的威胁上进行评估。保密性需求规格说明要对保密性需求进行规格说明。在规格说明中适当的地方，要明确解释保密技术用在保护系统免受各种不同威胁的作用。Stagesinsecurityspecificati31保密性需求的种类Identificationrequirements.识别需求。Authenticationrequirements.鉴定需求。Authorizationrequirements.授权需求。Immunityrequirements.免疫需求（抗病毒性）。Integrityrequirements.完整性需求。Intrusiondetectionrequirements.侵入检测需求。Non-repudiationrequirements.非否定需求。Privacyrequirements.隐匿需求。Securityauditingrequirements.保密审计需求。Systemmaintenancesecurityrequirements.系统维护保密性需求。保密性需求的种类Identificationrequire32LIBSYS保密性需求LIBSYS保密性需求33系统可靠性规格说明硬件可靠性（Hardwarereliability）硬件组件失败的可能性有多大以及修复该组件需要多长时间？软件可靠性（Softwarereliability

）一个软件组件产生不正确的输出的情况是怎样的。软件和硬件失效的区别在于软件是没有损耗的。即使是在产生不正确的结果之后它也能继续运行。操纵员可靠性（Operatorreliability）一个系统操作员出差错（makeanerror）的情况是怎样的？系统可靠性规格说明硬件可靠性（Hardwarereliab34功能可靠性需求举例需要定义出操作员全部输入值的预定范围，系统应该对所有落在该预定范围的操作员输入值进行检查。在系统初始化的时候，它应该对所有磁盘上的坏块进行检查。系统必须用N版本编程方法来实现减速控制系统。系统必须才用Ada安全子集来实现，并用静态分析方法进行检查。功能可靠性需求举例需要定义出操作员全部输入值的预定范围，系统35系统可靠性所需要达到的水平必须能够定量表达出来。可靠性是动态的系统特性，与源代码有关的可靠性规格说明是没有意义的。每1000行的失误数目不大于N个；它只对软件交付后的过程分析有用。那时你可以试着对你的开发技术有多好做出评价。需要选择合适的可靠性标尺来说明整个系统的可靠性。非功能可靠性规格说明系统可靠性所需要达到的水平必须能够定量表达出来。非功能可靠性36可靠性标尺是系统可靠性的测量单位。系统可靠性测量是通过计算操作失效次数来实现的。并且在适当的地方，还要把测量与加在系统上的要求和系统已经运行了多长的时间联系起来。评估关键系统的可靠性需要一个长期的测量计划。可靠性标尺(metrics)可靠性标尺是系统可靠性的测量单位。可靠性标尺(metrics37可靠性标尺(metrics)请求失效率——POFOD(Probabilityoffailureondemand)当发出一个服务请求时系统失效的可能性。例如，0.001的响应失效率意味着1000次服务请求中有一次可能会失效失效发生率——ROCOF(Rateoffailureoccurrence)出现未预期行为的发生概率。例如，2/100的失效发生率的意思是指在每100个操作时间单位里可能会失效2次。有时也把它称为失效强度。失效平均时间——MTTF(Meantimetofailure)观察到系统失效的平均时间。例如一个500MTTF的意思是在每500个时间单位里可能有一次失效。修复平均时间——MTTR(Meantimetorepair)从一个系统失效到它恢复服务的平均时间可获率——AVAIL(Availability)在一个给定时间内系统可以获得使用的概率。例如，一个0.998的可获率意味着在每1000个时间单位里系统可以获得998个。可靠性标尺(metrics)请求失效率——POFOD(Pro38请求失效率（POFOD)这是系统在接到服务请求时失效的几率。这对于服务请求不连续和比较稀少的情况来说是有用的。适合于保护系统，其中的服务请求偶尔发生并且如果不交付服务可能会产生严重后果。相应于许多具有例外管理组件的安全性关键系统一个化工厂里的紧急关闭系统。请求失效率（POFOD)这是系统在接到服务请求时失效的几率。39失效发生率（ROCOF）反映系统失效的发生比率。失效发生率等于0.002意味着在每1000个操作时间单位里可能有2次失效。例如1000小时的运行失效2次。相对于操作系统或事务处理系统而言，其中系统要频繁处理大量的类同的请求信用卡处理系统，航线预定系统。失效发生率（ROCOF）反映系统失效的发生比率。40失效平均时间(MTTF)是观察到系统失效的相隔时间度量。对稳定的系统来说，它是失效发生率的倒数。失效平均时间等于500意味着失效相隔的平均时间是500个时间单位。对应于长时交易系统，即系统处理要很长时间。失效平均时间应该大于交易时间计算机辅助设计系统，其一个设计者要用好几个小时进行设计工作，还有文字处理器系统。失效平均时间(MTTF)是观察到系统失效的相隔时间度量。对稳41可获率（AVAIL）系统可以获得使用所占的时间比率值。计入修复和重新启动系统的时间。可获率等于0.998意味着在1000个时间单位里有998个是可获得的。对应于不中断的、连续运行的系统

电话交换系统、铁路信号灯系统。可获率（AVAIL）系统可以获得使用所占的时间比率值。42非功能需求规格说明可靠性测量没有考虑到失效的后果。瞬时失误可能没有什么实际后果，但除此之外的其它失误却可能导致数据损失或毁坏，甚至使系统不服务。有必要区别不同的失效类型并对每种类型采取不同的测量标准。一定要构建好可靠性规格说明。非功能需求规格说明可靠性测量没有考虑到失效的后果。43失效后果在对可靠性进行规格说明的时候，不仅要考虑系统失效的数目，而且要考虑这些失效的后果。很显然，失效的后果远比能够修正和恢复的那部分损害要大得多。因此，在某些情况下要针对不同的失效类型定义不同的可靠性规格说明。失效后果在对可靠性进行规格说明的时候，不仅要考虑系统失效的数44失效分类（Failureclassification）失效分类（Failureclassification）45对每个子系统，分析可能发生的系统失效结果。通过系统失效分析，把失效划分成适当的类型。对分出的每种失效类型，采用合适的测量标准来测定可靠性。可以用不同的标准针对不同的可靠性需求。识别功能可靠性需求以降低严重失效的发生机会。可靠性规格说明步骤对每个子系统，分析可能发生的系统失效结果。可靠性规格说明步骤46银行自动出纳系统每台在网络上的机器每天使用300次。银行有1000台机器。软件发行版本的生命期是2年。每台机器处理约200,000交易。每天总数约有300,000个数据库交易。银行自动出纳系统每台在网络上的机器每天使用300次。47一个ATM的可靠性规格说明例子一个ATM的可靠性规格说明例子48规格说明确认凭经验来验证高可靠性的规格说明是很难做到的。数据库无损伤（Nodatabasecorruptions）意味着请求失效率要小于两百万分之一。如果一个交易时间是一秒钟，那么模拟一天的交易需要三天半的时间。测试可靠性花费的时间将要比系统生命期还要长。规格说明确认凭经验来验证高可靠性的规格说明是很难做到的。49要点（Keypoints）风险分析是建立在识别系统可靠性需求的基础之上的。风险分析包括对一个风险发生的机会进行评估和对风险按照它们的严重程度进行分类。保密性需求就是要识别财产和说明应该如何保护这些财产。可靠性需求是可以定量描述的。可靠性测量标准包括请求失效率（POFOD）、失效发生率（ROCOF）、失效平均时间（MTTF）和可获率（AVAIL）。非功能可靠性规格说明能够引出功能系统需求，该需求旨在减少失效或者是对失效后果进行处理。要点（Keypoints）风险分析是建立在识别系统可靠性需50习题：简述基于风险的规格说明过程的主要活动及其产物。风险分解有哪几种技术？失误-数分析属于哪一种？对下面几种软件系统选用适当的可靠性标尺，并说明你的理由。在医院的一间深切护理室里的监视系统；文字处理系统；自动贩卖机控制系统；刹车控制系统；一个制冷单元的控制系统；一个管理报表生成器。简述保密性规格说明过程及其步骤。在定义一个系统的可靠性规格说明时，如何考虑失效后果的影响。习题：简述基于风险的规格说明过程的主要活动及其产物。51关键系统规格说明CriticalSystemsSpecification关键系统规格说明CriticalSystemsSpeci52关键系统规格说明开发一个系统可获性，可靠性，安全性和保密性的规格说明的过程和技术（Processesandtechniquesfordevelopingaspecificationforsystemavailability,reliability,safetyandsecurity）关键系统规格说明开发一个系统可获性，可靠性，安全性和保密性的53Objectives说明如何通过分析关键系统所面临的风险来识别出系统的可信度需求。说明如何从系统的风险分析中获得安全需求。解释保密性需求的来历。描述用作可靠性规格说明的测量尺度。Objectives说明如何通过分析关键系统所面临的风险来识54Topicscovered基于风险驱动的规格说明安全性规格说明保密性规格说明软件可靠性规格说明Topicscovered基于风险驱动的规格说明55可信度需求用功能需求来定义差错检查、恢复工具和对系统失效的防范措施。用非功能需求来定义系统所需要的可获性和可靠性。用排它需求来定义千万不能发生的状态和条件。可信度需求用功能需求来定义差错检查、恢复工具和对系统失效的防56基于风险驱动的规格说明关键系统的规格说明应该是由风险驱动的（risk-driven）。该方法已经在安全和保密性至关重要的系统上广泛使用。规格说明过程的目标应该在于了解系统所面临的风险以及说明降低这些风险的需要做的事情。基于风险驱动的规格说明关键系统的规格说明应该是由风险驱动的（57风险分析的步骤风险识别（Riskidentification）识别出可能发生的潜在风险。风险分析和分类（Riskanalysisandclassification）评估每个风险的严重程度风险分解（Riskdecomposition）找出风险的潜在根源降低风险评估（Riskreductionassessment）说明在系统设计阶段如何消除和降低每一个风险。风险分析的步骤风险识别（Riskidentificatio58基于风险的规格说明基于风险的规格说明59风险识别识别出关键系统所面临的风险。在安全性关键的系统中，风险就是那些能够导致意外的危险。在保密性关键的系统中，风险就是那些对系统的潜在攻击。在风险识别中，需要识别出风险的类型及风险在这些分类中的地位服务失效；电气上的风险；…风险识别识别出关键系统所面临的风险。60胰岛素泵的风险胰岛素过量（服务失效）。胰岛素剂量不足（服务失效）。由于电池耗尽引起的电源故障（电气的）与其它医疗设备的电气接口（电气的）。传感器和致动器的接触很差（物理的）。在体内的机器部件脱落（物理的）。由于引入机器而导致感染（生物的）。对原料或胰岛素的过敏反应（生物的）。胰岛素泵的风险胰岛素过量（服务失效）。61风险分析和分类包含对发生一个风险的可能性以及对将要发生的一个意外或事故的潜在后果的理解把风险分类为：不可接受的（Intolerable）。必须不能让它发生或不能让它引起一个意外。在实际许可下尽可能低的（ALARP）。在给定成本和进度的限制下，必须使风险的可能性降到最小。可以接受的（Acceptable）。风险的后果是可以接受的，并且不需要付出额外的成本来降低危险的可能性。风险分析和分类包含对发生一个风险的可能性以及对将要发生的一个62风险级别风险级别63风险的社会接受度一个风险的接受度是被社会和政治的因素所左右的。在大多数社会而言，随着时间的推移，上面的三角形区域中的两条边界会逐渐向上靠，也就是说，社会越来越不愿意接收风险例如，虽说清除污染的成本可能会小于预防成本，但这可能不为社会所接受。风险评估是主观的风险被认定为类似于“大概的”，“可能的”等等。这取决于由谁来进行评估。风险的社会接受度一个风险的接受度是被社会和政治的因素所左右的64风险评估评估风险的可能性和严重程度。通常不可能很精确，因此用一些相对值表达，例如“不太可能的”、“很少的”、“很高的”等等。目标是排除那些最有可能发生的或者是后果严重的风险。风险评估评估风险的可能性和严重程度。65胰岛素泵的风险评估胰岛素泵的风险评估66风险分解（decomposition）在一个特定的系统里，找出风险的主要原因（rootcauses）技术大多来源于安全性关键的系统，并可以是：归纳法（Inductive），自下而上的技术。从提出的一个系统失效开始，评估由该失效可能导致的危险。演绎法（Deductive），自上而下的技术。以一个危险为起点，推断出可能引起它原因是什么。风险分解（decomposition）在一个特定的系统里，找67失误-树（Fault-tree）分析一种自上而下的演绎法技术。把风险或危险放在树的根上，再找出可以导致该危险的系统状态。在合适的地方加入‘and’或‘or’条件。目标应该是使引起系统失效的单一原因（singlecauses）的数量降至最低。失误-树（Fault-tree）分析一种自上而下的演绎法技术68胰岛素泵的失误-树胰岛素泵的失误-树69降低风险的评估这个过程的目标是识别出可信度需求，即说明应该如何管理风险以及确保不会发生意外和事故。降低风险的策略（strategies）风险规避（Riskavoidance）；风险检测与排除（Riskdetectionandremoval）；危害限制（Damagelimitation）。降低风险的评估这个过程的目标是识别出可信度需求，即说明应该如70策略应用（Strategyuse）通常在关键系统上要综合使用降低风险的策略。在一个化工厂的控制系统中，它含有检测和校正反应器过压的传感器。然而，它也含有一个单独的保护系统，以便在检测到危险高压后打开某个安全阀（reliefvalve）。策略应用（Strategyuse）通常在关键系统上要综合使71胰岛素泵的软件风险算术误差（Arithmeticerror）一个计算导致一个变量值上溢（overflow）和下溢（underflow）；可能包含一个对每类算术误差的例外句柄（exceptionhandler）。算法误差（Algorithmicerror）把将要分发的剂量与前次剂量或与安全最小剂量进行比较。如果剂量太高则要降低它。胰岛素泵的软件风险算术误差（Arithmeticerror72胰岛素泵的安全需求SR1：每次注射剂量不能超过系统用户的指定最大量。SR2：每天注射的累计剂量不能超过系统用户的指定最大量。SR3：系统应该含有一个硬件诊断设施，每小时至少执行4次。SR4：系统应该含有一个可以针对所有已经识别的例外的处理程序。SR5：当发现任何硬件和软件的异常以及收到诊断信息的时候，发出声音警报。SR6：在系统警报时，胰岛素注射应该中止，直到用户消除警报和进行系统复位为止。胰岛素泵的安全需求SR1：每次注射剂量不能超过系统用户的指定73安全性规格说明一个系统的安全性需求应该分别进行说明。这些需求应该建立在对风险和对可能发生的危险的分析基础上。安全性需求通常被应用于一个系统的整体而不是个别的子系统。在系统工程术语中，一个系统的安全性是一种自然特性（emergentproperty）。安全性规格说明一个系统的安全性需求应该分别进行说明。74国际电工委员会标准(IEC61508)是一项专门为保护系统而设计的安全管理国际标准，它并不适用于所有的安全性关键的系统。它结合了一个安全生命周期模型，涵盖了从范围定义到系统退役的所有安全管理的方面。国际电工委员会标准(IEC61508)是一项专门为保护系75控制系统的安全需求控制系统的安全需求76©IanSommerville2000 Dependablesystemsspecification Slide77安全生命周期©IanSommerville2000 Dependa77安全性需求功能安全性需求（Functionalsafetyrequirements）这些需求定义了保护系统的安全功能，即定义了系统应该提供什么样的保护。安全完整性需求（Safetyintegrityrequirements）这些需求定义了保护系统的可获性和可靠性。它们以预期的用法为基础并且采用从一至四个安全完整性级别进行分类。安全性需求功能安全性需求（Functionalsafety78保密性规格说明与安全性规格说明有些相似对保密性需求进行定量规格说明是不可能的；需求常常用“不应该”而不是用“应该”来描述。差别对一个保密性管理的生命周期还没有定义完备的观念。它没有标准；只有一般性的威胁而没有系统特定的危险；具有成熟的保密技术（加密，等等）。然而，当把这些技术转化到一般性的用途上的时候就会出现问题；单独的供应商（微软）的主导地位意味着大量的系统可能会受到保密性失效的影响。保密性规格说明与安全性规格说明有些相似79保密性规格说明过程保密性规格说明过程80保密性规格说明步骤财产识别和估值识别出财产（数据和程序）和它们所需要的保护程度。保护程度依赖于财产的价值，因此一个密码文件要比一组公共网页更有价值。威胁分析和风险评估要识别出可能发生的保密性威胁，并要估计到与每个这种威胁有关的风险。威胁分配把已经识别的威胁与财产联系起来，这样就可以就每个已经识别的财产列出一张与威胁关联的表格。保密性规格说明步骤财产识别和估值81Stagesinsecurityspecification技术分析对获得的保密技术及其是否可用在识别出的威胁上进行评估。保密性需求规格说明要对保密性需求进行规格说明。在规格说明中适当的地方，要明确解释保密技术用在保护系统免受各种不同威胁的作用。Stagesinsecurityspecificati82保密性需求的种类Identificationrequirements.识别需求。Authenticationrequirements.鉴定需求。Authorizationrequirements.授权需求。Immunityrequirements.免疫需求（抗病毒性）。Integrityrequirements.完整性需求。Intrusiondetectionrequirements.侵入检测需求。Non-repudiationrequirements.非否定需求。Privacyrequirements.隐匿需求。Securityauditingrequirements.保密审计需求。Systemmaintenancesecurityrequirements.系统维护保密性需求。保密性需求的种类Identificationrequire83LIBSYS保密性需求LIBSYS保密性需求84系统可靠性规格说明硬件可靠性（Hardwarereliability）硬件组件失败的可能性有多大以及修复该组件需要多长时间？软件可靠性（Softwarereliability

）一个软件组件产生不正确的输出的情况是怎样的。软件和硬件失效的区别在于软件是没有损耗的。即使是在产生不正确的结果之后它也能继续运行。操纵员可靠性（Operatorreliability）一个系统操作员出差错（makeanerror）的情况是怎样的？系统可靠性规格说明硬件可靠性（Hardwarereliab85功能可靠性需求举例需要定义出操作员全部输入值的预定范围，系统应该对所有落在该预定范围的操作员输入值进行检查。在系统初始化的时候，它应该对所有磁盘上的坏块进行检查。系统必须用N版本编程方法来实现减速控制系统。系统必须才用Ada安全子集来实现，并用静态分析方法进行检查。功能可靠性需求举例需要定义出操作员全部输入值的预定范围，系统86系统可靠性所需要达到的水平必须能够定量表达出来。可靠性是动态的系统特性，与源代码有关的可靠性规格说明是没有意义的。每1000行的失误数目不大于N个；它只对软件交付后的过程分析有用。那时你可以试着对你的开发技术有多好做出评价。需要选择合适的可靠性标尺来说明整个系统的可靠性。非功能可靠性规格说明系统可靠性所需要达到的水平必须能够定量表达出来。非功能可靠性87可靠性标尺是系统可靠性的测量单位。系统可靠性测量是通过计算操作失效次数来实现的。并且在适当的地方，还要把测量与加在系统上的要求和系统已经运行了多长的时间联系起来。评估关键系统的可靠性需要一个长期的测量计划。可靠性标尺(metrics)可靠性标尺是系统可靠性的测量单位。可靠性标尺(metrics88可靠性标尺(metrics)请求失效率——POFOD(Probabilityoffailureondemand)当发出一个服务请求时系统失效的可能性。例如，0.001的响应失效率意味着1000次服务请求中有一次可能会失效失效发生率——ROCOF(Rateoffailureoccurrence)出现未预期行为的发生概率。例如，2/100的失效发生率的意思是指在每100个操作时间单位里可能会失效2次。有时也把它称为失效强度。失效平均时间——MTTF(Meantimetofailure)观察到系统失效的平均时间。例如一个500MTTF的意思是在每500个时间单位里可能有一次失效。修复平均时间——MTTR(Meantimetorepair)从一个系统失效到它恢复服务的平均时间可获率——AVAIL(Availability)在一个给定时间内系统可以获得使用的概率。例如，一个0.998的可获率意味着在每1000个时间单位里系统可以获得998个。可靠性标尺(metrics)请求失效率——POFOD(Pro89请求失效率（POFOD)这是系统在接到服务请求时失效的几率。这对于服务请求不连续和比较稀少的情况来说是有用的。适合于保护系统，其中的服务请求偶尔发生并且如果不交付服务可能会产生严重后果。相应于许多具有例外管理组件的安全性关键系统一个化工厂里的紧急关闭系统。请求失效率（POFOD)这是系统在接到服务请求时失效的几率。90失效发生率（ROCOF）反映系统失效的发生比率。失效发生率等于0.002意味着在每1000个操作时间单位里可能有2次失效。例如1000小时的运行失效2次。相对于操作系统或事务处理系统而言，其中系统要频繁处理大量的类同的请求信用卡处理系统，航线预定系统。失效发生率（ROCOF）反映系统失效的发生比率。91失效平均时间(MTTF)是观察到系统失效的相隔时间度量。对稳定的系统来说，它是失效发生率的倒数。失效平均时间等于500意味着失效相隔的平均时间是500个时