航空电子领域中基于形式化方法的安全需求描述
1. 基于形式化方法的安全需求描述意义和准则
在许多领域软件系统的安全性与可靠性显得日益重要，尤其在对安全性和可靠性要求极高的综合航空电子领域中软件系统的安全性和可靠性更显重要。因为综合航空电子系统对于整个飞机的安全性起着至关重要的作用。然而，伴随着航电系统日益增长的复杂性和系统集成的问题依然会增加潜在的错误并可能直接影响到飞机的安全性和可靠性。传统的软件工程方法已经很难满足这样复杂和安全性要求极高的需求，这迫切需要新的方法来设计开发安全性更高，资金时间投入更少的系统,为了解决这些实际问题，基于模型的开发方法（MBD）被引入，通过对需求描述严格的形式定义，可执行的原型设计，定理证明，模型检测，和高质量代码的自动生成等形式化技术大大提升了系统的安全性和可靠性，同时也大大节省了时间和成本。
大多软件开发的错误源于需求分析阶段的逻辑错误。这些逻辑错误会传递到软件开发的后续阶段，大量的重复工作花费在修补由于需求阶段的逻辑错误而导致的系统错误。而且，需求错误往往是相当严重的错误。需求阶段的错误比设计或实现阶段所引入的错误更加影响系统的安全性。
发现错误的一个有效途径就是创建一个系统外部可见行为的精确且可执行的系统模型。为了建立可读的且数学形式上的精确的系统功能行为模型，已经有多种符号语言被开发出来。比较出名的有SCR,RSML,SpecTRM,和Statecharts。基于这些符号语言来创建模型能够发现大量系统描述中的错误。而且能够作为与用户交互的实模型，并能够类仿真的形式向客户执行。最好的情形就是经过精心设计的符号语言能够支持系统模型的自动形式化安全分析（如图1.1）。它使得通过一致性和完备性检查来发现错误成为可能，同时有能力来检查应用程序建模的一些性能描述。总之，创建系统行为的精确模型不仅仅使得能够在系统生命期尽早地发现错误，并及时地解决，还能够提升后续的系统设计，编码，验证，测试的质量。
图1.1 基于形式化方法的安全性分析
系统需求描述作为系统开发的蓝图，它应该是对系统期望行为的完备的，一致性的，精确的描述。否则将会把不安全因素带进后续的设计、编码、测试等环节，将严重影响系统的安全性能同时也增加更多的开发代价。所以提供方法和技术使尽可能早地排除与需求相关的错误显得非常重要。
为了分析和发现需求描述的错误，描述语言所应具有的一些标准对于我们达到我们的目标至关重要。准则一是需求描述语言只详细描述系统的黑盒行为而不包括内部的设计信息；准则二是描述语言要让在保证形式化的准确性的同时能够方便专业技术人员和非专业人员易读易理解建立起他们对系统统一的认识；准则三，就是要具有描述复杂系统的能力，在这里主要借鉴了Harel 所提出的“clustering“的概念，另一方面也用到了Harel“abstraction”思想；其他两个标准是最小性和简洁性。最小性就是需求描述仅包含对开发和分析有用的信息。这样能够节省更多的时间，同时让读者聚焦于对象的重点上。简洁性就是尽量避免描述语言让描述和分析过程复杂化。语言应该简单易于使用而且能让描述更可读和更易查错。
2.RSML
为了更好地描述需求，满足上面所提到的符号语言的要求，在这里我们引入了RSML语言，RSML（需求状态机语言）是源于David Harel的Statecharts，是加州大学的Nancy Leveson研究组开发的一种基于状态的描述语言用于对过程控制系统的行为建模。RSML的主要设计目标就是让非计算机专业人员比如最终用户，应用工程师，管理者，以及来自监管机构的代表都能易读易理解用RSML 语言写的需求描述。
一个RSML描述由变量，状态，转移，功能函数，宏，常量，和接口组成。
需求描述中的变量用于存储外部传感器的输入值，也用于暂存系统的输出值。
Statecharts以分层的形式组织状态。RSML包括三种不同类型的状态：复合状态，平行状态，和原子状态。原子状态等同于传统有限状态机中的状态。平行状态用于模型固有的平行性或建模对象的局部。复合状态（superState）一方面用于隐藏状态机的局部细节来使得所得模型更易理解，另一方面封装状态机的确切行为。图2.1是ASW需求描述中状态的分层建模的例子，它包含以上所说的三种不同状态类型。
图2.1 High-level ASW Model
RSML中的状态转移控制着一个状态到其他状态的转移。状态转移由一个原状态，一个目的状态，一个触发事件，一个监督条件和一组动作事件组成。为了执行一次RSML状态转移，必须有下列情况为真：(1)原状态当前处于激活状态，(2)触发事件出现在原状态处于激活态，(3)当触发事件发生时监督条件必须为真。当所有这些情况都满足时，目的状态将成为激活状态，而原状态将变为非激活状态，同时产生行为事件。
监督条件简单地以说就是在不同的状态和变量之间的一种谓词逻辑表达式，用命题逻辑符号语言传统地去定义这些条件通常会陷入复杂的表达式并且变得不可读。为了克服这一问题，在RSML中使用了析取范式(DNF)的一种表格表示，这种表格被称为AND/OR表。AND/OR表格的最左一列列出了逻辑短语。其它的列是这些逻辑短语的连接，并且列出了表达式的逻辑真值。并规定只要有某一列的值为真则整个表的值就为真。而每列的真值为真当且仅当此列的真值与它们所关联的逻辑短语的真值都一致。AND/OR表2.1是谓词短语
（(Expression-1∧┐Expression-2)∨(Expression-1∧Expression-3)）的逻辑等价描述。
AND/OR表2.1
为了进一步增加需求描述的可读性，Irvine研究组在RSML中引进了许多其它的语法结构，例如，允许谓词中的表达式定义为形如case语句的函数，允许宏定义经常使用的且相同的条件。图2.2，“BelowThreshold”和“AltitudeQualityOK”都是宏。宏BelowThreshold的定义在图2.3中给出。
图2.2 A Transition and Macro from the ASW requirements RSML支持系统级组件间通信的严格的描述和分析，系统组件间的的联系通过通道的形式。每个组件可能有多个输入/输出通道。通信的发生通过消息机制来驱动。
3.RSML用于需求形式化描述的好处
一．RSML语言易读易理解，能够使设计人员和各户之间对于需求描述的理解更一致。能够让各户更多地参与到系统开发中来，从而使开发的产品更加地符和期望。
二．RSML形式化地描述系统的行为模型，能够方便地翻译为定理自动证明和模型检测的输入形式使模型可执行，通过模型检测和定理自动证明来保证系统行为的完备性和一致性，从而提升系统的安全性。
三．精确的行为描述，可以减少系统的冗余，节省时间。
四．提供了一系列针对复杂系统的语法机制，适用于描述复杂性的系统。
五．基于这种需求描述的需求形式化分析方法，可以使得大量错误在需求阶
段被找出，避免了错误的向后传递，大大减少后续排错，返工的时间消耗。
计算机软件需求说明编制指南 1 引言 1.1 目的和作用 本指南为软件需求实践提供了一个规范化的方法。本指南不提倡把软件需求说明（Software Requirements Specifications，以下简称SRS）划分成等级，避免把它定义成更小的需求子集。 本指南适用对象： 软件客户（Customers），以便精确地描述他们想获得什么样的产品。 软件开发者（Suppliers），以便准确地理解客户需要什么样的产品。 对于任一要实现下列目标的单位和（或）个人： a. 要提出开发规范化的SRS提纲； b. 定义自己需要的具体的格式和内容； c. 产生附加的局部使用条款，如SRS质量检查清单或者SRS作者手册等。 SRS将完成下列目标： a. 在软件产品完成目标方面为客户和开发者之间建立共同协议创立一个基础。对要实现的软件功能做全面描述，帮助客户判断所规定的软件是否符合他们的要求，或者怎样修改这种软件才能适合他们的要求； b. 提高开发效率。编制SRS的过程将使客户在设计开始之前周密地思考全部需求，从而减少事后重新设计、重新编码和重新测试的返工活动。在SRS中对各种需求仔细地进行复查，还可以在开发早期发现若干遗漏、错误的理解和不一致性，以便及时加以纠正； c. 为成本计价和编制计划进度提供基础。SRS提供的对被开发软件产品的描述，是计算机软件产品成本核算的基础，并且可以为各方的要价和付费提供依据。SRS对软件的清晰描述，有助于估计所必须的资源，并用作编制进度的依据； d. 为确认和验证提供一个基准。任何组织将更有效地编制他们的确认和验证计划。作为开发合同的一部分，SRS还可以提供一个可以度量和遵循的基准（然而，反之则不成立，即任一有关软件的合同都不能作为SRS。因为这种文件几乎不包括详尽的需求说明，并且通常不完全的）； e. 便于移植。有了SRS就便于移值软件产品，以适应新的用户或新的机种。客户也易于移植其软件到其他部门，而开发者同样也易于把软件移植到新的客户； f.作为不断提高的基础。由于SRS所讨论的是软件产品，而不是开发这个产品的设计。因此SRS是软件产品继续提高的基础。虽然SRS也可能要改变，但是原来的SRS还是软件产品改进的可靠基础。 1.2 范围 本指南适用于编写软件需求规格说明，它描述了一个SRS所必须的内容和质量，并且在第6章中提供了SRS大纲。 2 引用标准 GB 8566 计算机软件开发规范 GB 8567 计算机软件产品开发文件编制指南 GB/T 11457 软件工程术语 3 定义 GB/T 11457所列术语和下列定义适用于本指南。
企业管理软件的需求描述方法精编W O R D版 IBM system office room 【A0816H-A0912AAAHH-GX8Q8-GNTHHJ8】
企业管理软件的需求描述方法 摘要 本文介绍了企业管理软件需求的5元素描述法：<组织，流程，功能，数据，业务逻辑>，详细介绍了对每个元素的描述方法、5个元素之间的关系描述方法，提出了针对不同的读者编写不同的需求文档的观点，并给出了一些提高需求可读性的建议。 关键词 组织，流程，功能，数据，业务逻辑 需求是整个软件项目最关键的一个输入，据统计，不成功的项目中有37%的问题是由需求造成的。和传统的硬件生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，在硬件生产企业中，产品的需求是明确的、有形的、客观的、可描述的、可检测的，而软件需求不具备此特征。需求文档作为客户和开发人员、开发人员之间进行交互的文档，它将系统的需求进行了“固化”，是需求的载体，其作用是至关重要的。笔者结合多年的企业管理信息系统的开发经验，总结了如下的需求描述的方法与经验，供各位同行参考。 1 构成企业管理信息系统的5个基本要素 对企业需求的描述可以从2个方面来进行描述，一个方面是对客户现行系统的描述，一个方面是对系统未来的设想。总的而言，无论是从那个方面来描述，构成企业信息系统主要包括5个基本要素：企业的组织结构、流程、数据、商务规则与功能（性能）。其中从用户的角度主要关注流程，是以流程为核心的，通过流程将其他几个要素贯穿起来，需求分析人员也应该从这个角度来和用户沟通；从开发者的角度主要关注企业的数据、商务规则与功能，以便于系统的实现；从实施者的角度主要关注企业的组织结构与功能，以便于系统的发布与实施。
项目需求描述 一、项目概况 (一)项目名称 XX区交通基础数据采集、信号控制设备排查与配时服务（三期）项目。 (二)服务模式 采用服务外包模式。 (三)服务范围 本次XX区交通基础数据采集、信号控制设备排查与配时服务（三期）项目工作范围主要为XX区134个信号控制交叉口。 在服务期内，辖区新增信号控制交叉口纳入本次服务范围，不另外变更费用。 (四)服务周期 服务周期共24个月。服务期限自项目合同之日起计算，合同签订后第一个月，为项目准备阶段；准备阶段结束后正式进入服务周期（24个月），项目服务期周期到期后一个月，为项目收尾阶段。 (五)指导原则 1.规范性原则。服务人员严格按照规定的流程进行工作，严格遵守相关法规和XX市公安局交通警 察支队增城大队的相关工作要求，并做好记录和工作总结。 2.安全性原则。服务要以保证系统数据安全、系统运行安全为前提，严格遵守保密协定，尊重用 户利益，涉及外场设备的工作中，以保证服务人员人身安全为前提，做好防护措施，保证工作的顺利进行。 3.高效原则。建立服务的快速响应机制，保证业务问题解答、重大故障的现场处理、紧急工作任 务处理等在用户要求的时间内完成。
二、信号控制管理现状 截止目前，智能交通管理系统（第一期）项目通过对XX区荔城信号控制路口基础信息的摸查和排查，以及单点路口的信号优化，已取得了显著的效果。现需对信号控制方案进行持续跟踪、优化，并加强对信号控制方案的研究，推进SCATS系统的本地化应用，建立规范的SCATS系统操作指南。 智能交通管理系统（第二期）项目新增的新塘43个信号控制交叉口、永宁街道7个信号控制交叉口、开发区31个信号控制交叉口及新城大道11个信号控制交叉口正进行智能升级改造。目前仍均使用单点控制信号机，大部分使用年限久远，且每个路口独立控制，管理方式落后，配时手段较单一，通常信号机全天只有一个控制方案，尤其是早晚高峰期，信号灯的配时与流量大小不匹配，导致某些车道放行时间不够，排队长度较长，停车次数较多。在信号控制调试上，缺乏理论支持，仅依靠经验设置，在高峰期中降低了道路的通行能力。 三、本期的服务项目任务、范围和规模 本次XX区交通基础数据采集、信号控制设备排查与配时服务（三期）工作范围为对XX区134个信号交叉口建立台账信息管理系统、更新已有信号控制路口信息、摸排新增信号控制路口信息，并进行路口基础信息核查更新和信号控制方案优化。 在服务期内，辖区新增SCATS信号控制交叉口及交警部门要求的交通管理服务纳入本次服务范围，不另外变更费用。 主要服务任务如下所示： （1）总结现有交通信号控制理论及相关技术，完善标准化流程和关键技术工作流编制，编制SCATS交通信号控制系统日常操作指南，进一步优化工作流程，形成一套高效、实用的工作 机制，为XX区信号控制工作提供理论支持。 （2）对所有信号控制路口的基础信息和设备建立台帐系统，实现大队统一管理部署。对现有的信号控制路口及新建路口进行路口基础数据更新，并录入台账系统；对本期新增控制路口交通 基础数据进行摸、排查，建立路口基础数据管理库，并录入台账系统。对所有路口进行五项规 则排查并进行相应的优化。 （3）对项目范围内的所有交通信号控制路口进行周期性巡查，及时发现存在不足的问题路口并予以改善、跟踪，优化路口的运行方案，从而不断提高路口的运行水平。安排技术人员在早晚 高峰时段值班，监控交通运行，及时解决交通问题，维持高峰交通秩序。在举办大型活动等特 殊日期根据流量的变化对信号控制方案进行微调，或设置特殊管控时段，特定控制预案，保障
学习中心_________ 姓名_____________ 学号 西安电子科技大学网络教育学院 模拟试题三 《软件形式化方法》期末考试试题 （120分钟） 题号一二三四五六七总分 题分 得分 一、填空题。（20分） 1. 软件危机是指在计算机软件的过程中所遇到的一系列严重的问题，应对软件危机的方式分为两种方法：和。对于软件开发组织和管理的规范化方法中，主要研究、和三个要素。 2. 形式化方法研究如何把（具有清晰数学基础的）（描述形式、技术和过程等）融入软件开发的各个阶段；包括、形式化验证和程序精化三种活动。形式化验证主要技术包含和；程序精化是将与相结合，研究从抽象的推演出具体的面向计算机的。 3. 模式是Z语言规格中一个重要的元素，模式是由、和 组成。 4. Larch方法是软件系统规格的一种；Larch方法的程序规格包括和与目标语言相关的两个部分。 二、利用有限状态机描述“AB协议”。（15分） AB协议包含发送端和接收端两个实体。发送端协议实体从发送方用户获取一个报文，将序号寄存器值赋给报文，然后向接收端协议实体发出报文，发送方发出报文之后启动超时时钟，等待认可报文。如果在给定的时间内未收到认可报文，则重发报文；如果收到认可报文，其序号与发出报文序号相同，则发送端实体从发送方用户获取下个报文。接收端协议实体在收到报文之后，如果报文无错误，则想发送端实体发送认可报文，然后将报文递交给接收方用户；如果接收的报文有错误或者序号不正确，则丢失报文。假定所用通道不会中断；报文重复n次后最终能够被接收；认可报文只要发出就能正确收到；报文不会损坏；序号寄存器初始化为0 。 三、构造下图所示Petri网的覆盖树。（10分） 四、利用CSP对“生产者-消费者”系统进行规格。（10分） 五、逻辑演算证明。（15分） （1）?(Q∨R) ∧(P?Q)├?P （2）(P?(Q?S)) ∧ (?R∨P) ∧Q├ R→S （3）($x)P(x)?("x)(P(x)úQ(x)?R(x)), ($x)P(x), ($x)Q(x)├ R(a)ùR(c) 六、如图中所示的Kripke结构，利用标号算法对公式进行模型检验。（15） （1）E((p ∧r) ?p) （2）A(p?q) = ?E(?(p?q))
形式化方法 Formal Methods (实例研究) 裘宗燕北京大学数学学院2006年2－6月 2006年4月 2 实例1：实时内核 问题简介 实时内核 进程状态和内核数据结构（原文档） 内核状态 后台处理 中断处理 总结 2006年4月 3 简介 ?嵌入式系统得到越来越广泛的应用 ?需要一个小操作系统提供进程调度和中断处理功能?嵌入式系统应用有时是安全攸关和生命攸关的?下面的研究是用Z 描述了一个X 光治疗仪的内核?原系统包含大约50 页汇编代码，生成的目标代码将近1K ?本研究发现原内核实现有可能出现死锁，当时中断都被禁止，处理器空等待进程的运行 –由于实时和并行，这种错误很难通过测试查出并排除 –原来的系统错误并没有威胁到病人安全，一个原因是安装了一个限时硬件，以防控制计算机的软件或硬件错误–但这种错误有可能由于系统的修改或者升级而产生严重的后果?这里介绍简化后的这个实时内核规范 2006年4月4 内核基本情况 这是一个典型的用于嵌入式系统的实时内核：?支持后台处理进程和中断处理器 ?若无中断发生，将有一个后台进程被作为当前进程，处于运行中 ?当前进程一直运行到自己显式释放处理器，这时调度器将选择另一进程作为当前进程 ?每个后台进程有一个就绪标志，调度器只在就绪进程中选择 ?如果一个或几个中断激活，就根据它们的优先级（用一个数表示）选出其中最紧急的中断，令相应的中断处理器运行 ?中断激活的条件是它们的优先级高于当时已激活的中断，当相应的处理器发出自己已结束的信号时，该中断离开激活状态 ?后台进程可以注册到某个优先级，使自己变成一个中断处理器 图1：内核实现的数据结构（取自原文档） 进程，链接成一个环 中断控制下的进程 调度器控制下的进程 ready = true ready = false 当前活动进程 图2：进程状态 被迫转换（其他进程导致）自主转换（自己执行命令） 中断控制下的进程 调度器控制下的进程 箭头反了
第十四讲形式化方法--程序的正确性验证 一、概述 计算机的程序是一种静态的对象，但它所描述的问题（问题的解）却是一个动态的对象。所谓的程序设计就是用程序设计语言中的语句改变程序中数据对象的状态，构造所描述问题的动态行为。这是不自然的，程序所描述的动态行为也无法直接用程序本身的静态结构进行正确性证明。 形式化规约（formal specification）是需求阶段的形式化说明，是用户需求的严格描述，其一般形式用Hoare逻辑描述[1]如下： ├{Φ}P{Ψ} <1> 其中Φ和Ψ分别表示初始和结束断言条件，其含义是：“假如初始状态d I满足条件Φ，那么程序结束并且终结状态d f必须满足Ψ”。 设D＝D1×……×D n为程序P的状态空间，其中，D j(j=1,……,n)表示程序中数据对象的值域。显然，由Φ和Ψ断言条件所确定的合法初始和结束状态的集合是D的一个子集。 执行函数E：Φ×P→Ψ定义如下： 无定义对合法的初始状态d i，程序P不结束 E（P,d I）= 终结状态d f对合法的初始状态d i，程序P结束 程序的正确性即为： ├{Φ}P{Ψ} iff <2> ?d i(├Φ(d i)→(├程序P结束 and ├Ψ(E(P,d i)))) 总地来讲，验证一个程序的正确与否有两种办法，一种是程序的测试，另一种是程序的正确性证明。 1．程序的测试与程序的验证 对给定的一个合法的初始状态d i，当程序执行结束时其终结状态为d f，那么，Φ(d i)和Ψ(d f)都应该被满足。这一点可用下式表示： {d i}P{d f} <3> 所谓程序的测试就是验证测试用例{d i}P{d f}，即验证程序对d i的执行结果是否为d f。由于合理的初始状态是无限的，因此，对程序验证来讲，测试不是一个完备的方法。测试被认为是一种尽量发现错误，但并不能保证程序中没有错误[2]的方法。对大数应用来讲，它是可满足的；但对有些应用来讲，测试是一种不能满足的验证方法，例如：航空、航天等领域的软件系统。 显然，对要求绝对正确的软件，测试是一种不能采用的方法。无论白盒测试还是黑盒测试都是在无限集合{(d i,d f)|?d i,?d f, d i和d f满足{d i}P{d f}中选择有限的一些(d i,d f)对进行验证，而各种测试方法只是选择(d i,d f)的策略不同而已。 因此，验证程序是否完全正确要寻求另外的解决途径。那就是程序的正确性验证。 2．形式语义与程序的正确性验证 程序的正确性验证应该具有严密的推量过程，以保证程序每步执行结果都是希望的结果，而与程序执行的某个初始状态无关。程序的正确性证明现有三种方式：操作语义、指称
需求分析(一)概念、方法、实践步骤 1.概念、方法、实践步骤 需求分析阶段主要通过收集、分析、导出的方法，将客户、业务、用户的需求转换为对应的（软件）系统需求的过程。典型的工作产品：软件需求说明（Software Requirements Specifications，以下简称SRS）其主要包括系统基本概要、业务功能、系统功能（性能、安全性、信赖性、扩充性、移植性、多语言对应性等要求）、接口功能要求等内容。 1.1 需求分析阶段的主要活动 需求分析阶段的主要活动可以分为需求开发、需求管理2类： 需求开发通过对客户、业务、用户、原系统等调查获取原始的需求，经过需求分析逐步识别并使业务具体化，通过形成制作规格说明书（或SRS）使业务系统化，项目团队同客户、用户逐步达成共识对需求得以最终确认，其间可以通过系统建模、POC等方式评估需求的可实现性。 需求管理在需求开发过程中，通过需求范围认定、需求形式化记录、需求数据库建立、需求状态跟踪、需求变更分析和波动评估、需求评审控制等活动，通过使用需求管理工具等手段，实现对系统需求按基线进行控制和管理。其核心内容变更管理、版本管理以及需求跟踪。 1.2 需求开发的主要概念以及核心步骤 业务需求反映了企业或组织对（软件）系统的业务要求，通常也包含问题或机会的定义。问题是指企业或组织运作过程中遇到的问题，例如物资供应脱节、用户投诉量大、客户流失率较高等。机会是指抓住外部环境变化所带来的机会，以便为企业带来新的发展，例如电子商务、网上银行、基于即时通信的工作协同系统等。业务需求通常由管理人员提出，业务需
求的解决往往要结合制度、（人员）能力、系统功能等多方面综合解决。另外,业务需求也反映了企业或组织对（软件）系统的高层次目标要求，就是系统的建设的目的以及目标。 用户需求是指描述用户使用（软件）系统需要完成什么任务，怎么完成的需求，通常是在问题定义（业务需求）的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立用户角度的需求。解决如何使用（软件）系统完成具体工作。 软件系统需求是在业务需求的指导下，对用户需求进行整理、分析、提炼，从而指导开发的、更精确的、规格化的需求。一般来说，软件需求可以作为软件验收依据与合同契约。软件系统需求可以分为业务功能需求、系统功能需求、设计约束等方面的内容。 ?业务功能需求：（软件）系统必须完成的业务功能，即为了向它的用户提供有用的 功能，产品必须执行的动作。这部分工作将分散的用户零散的需求采用结构化的方 法去定义，以便支撑后续的设计、开发、测试。 ?系统功能需求：（软件）系统必须具备的功能、性能、属性。包括系统性能（功能 速度、响应时间、恢复时间等等）、可靠性、易用性、安全性、移植、部署等方面 的内容需求。 ?设计约束的需求：影响系统实现的各种设计约束，包括开发语言、数据完整性方针、 资源的限制、运行的环境的要求等等。 2.主要流程 需求分析阶段的主要活动围绕需求开发进行，包括制定及修改需求开发计划、开展需求调查以及分析、需求验证、需求规则说明制作、需求确认几个步骤。 1．制定及修改需求开发计划包括建立需求团队的组织并授权、对需求分析阶段的WBS 进行分解、协商并制定调查分析以及评审计划、评估工作量等等方面的内容，其目的是保证各项活动有序、可控的进行。 2．需求调查以及分析的过程，主要活动通过沟通、收集项目中的各级关系人的需求，形成需求调查报告。需求调查通过现场参观、开调查会、业务专家培训、询问沟通、设计调查表并调查、收集查阅记录等方式获取客户、用户各级组织对（软件）系统需求，分析并识别客户以及用户的需要、期望、业务要求，归纳整理后形成需求调查报告。 3．需求验证环节主要通过原型（Prototype）、POC（Proof of Concept）、用例（Use Case）或简单的功能列表的方式同客户、用户沟通逐步将业务需求、用户需求等转化为软件系统需求。 ?原型（Prototype）模拟最终软件的屏幕显示，这样用户可以看到最终软件将是什么样，有些原型可以模拟实际的操作，对关键的输入输出数据也可以一定 程度的模拟。对于用户体验为主的系统往往可以起到很好的效果。 ?POC（Proof Of Concept）原意是“为观点提供证据”。对于关键的技术或者业务模型，论证需求、设计的可实施性,评估和确认概念设计方案，POC的评 价可能引起需求和设计的调整。一般来说，进行POC的条件：1. 论证业务中 涉及到的模型或者算法的可行性。2. 论证技术模型实现的可行性、成本等。 ?用例（Use Case）：对（软件）系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说
软件需求分析（Software Reguirement Analysis）是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。 软件需求分析是一个项目的开端，也是项目实施最重要的关键点。据有关的机构分析结果表明，我们设计的软件产品存在不完整性、不正确性等问题80％以上是需求分析错误所导致的，而且由于需求分析错误造成根本性的功能问题尤为突出。因此，一个项目的成功软件需求分析是关键的一步。 一、软件需求分析理论 如果我们用数学方法来描述软件需求分析，可以将一个应用软件定义为S，可能应用软件涉及功能性问题非常广，我们用抽象化理论分析，可以划分为各个功能域，可以用D1、D2、… Dn表示，那么，我们可以用一个表达式描述为S={D1，D2，D3，…Dn} 但是，功能域Di依然存在着有若干个问题P1、P2、P3、… Pm组成，并且每个功能对应于子系统中的一个软构件，我们可以表示为 Di={P1，P2，P3，…Pm} 同样，功能Pj有若干个行为F1、F2、F3、… Fk，每个行为对应于软构件中的实现方法 Pj={F1，F2，F3，…Fk} 一个软件包含了所有功能的集合，同时包含了实现所有功能的所有方法和算法描述。需求分析是依据于用户需求，经过需求问题识别，进行分析、消化与综合，制订规格说明，评审，分为四个阶段，形成用户需求与设计同步，设计满足用户需求目标。 需求分析方法始终贯穿着吸收、同化、贯彻方法和手段，用商业化行为解决需求与实现中存在的矛盾，解决用户需求与商业化产品融通，解决规范与个性化追求。 二、软件需求分析目标 软件需求分析的主要实现目标：
安全协议的形式化分析方法 安全协议是采用密码技术来保障通信各方之间安全交换信息的一个规则序列。其目的是在通信各方之间提供认证或为新的会话分配会话密钥。尽管现有的安全协议是安全专家精心设计和详细审核过的但仍然可能存在一些不易发现的安全缺陷有些甚至数年后才被发现。长期以来，形式化方法被公认为分析安全协议的有力武器。 目前分析安全协议的形式化方法主要有： （1）推理构造法，该方法基于知识和信念推理的模态逻辑，如K3P逻辑等，但K3P逻辑只能分析协议的认证性质而不能分析协议的保密性质； （2）攻击构造法，该方法从协议的初始状态开始，对合法主体和一个攻击者所有可能的执行路径进行穷尽搜索，以期找到协议可能存在的错误。这种方法主要有基于模型检测技术的模型检测器QRS( 验证语言、代数简化理论模型以及特定专家系统（如特殊目的NRL分析器和Interrogator），但这种方法无法解决状态空间爆炸问题； （3）证明构造法，该方法集成了以上两类方法的思想及多种技术，主要有Bolignano证明方法和Paulson方法等。以上形式化分析方法的主要缺点是无法解决状态空间爆炸问题在很大程度上被限制在规模很小的协议分析中这显然不适应网络通信规模日益增大等发展的需要。 安全协议是建造网络安全环境的重要基石，是保证网络安全的核心技术。设计和证明安全协议自身的正确性和安全性，成为网络安全的基础。形式化分析方法已被证明是用于分析、设计和验证安全协议的重要方法，对安全协议的形式化分析、设计和验证已经成为当今形式化分析研究领域的一个热点问题。 虽然人们使用形式化分析方法已成功发现了许多现存安全协议存在的缺陷和针对她们的攻击，但是这些分析方法还存在许多缺陷。有些形式化分析方法自身不太完善，存在一定的局限性，不能分析和验证某些类型安全协议的安全性；有些只能分析安全协议的不安全性，不能给出协议安全性的精确证明。 在总结安全协议现存各种缺陷的基础上，根据缺陷产生各种原因将缺陷分为：过小保护缺陷、消息可重放缺陷、消息不可达性缺陷、并行会话缺陷和其他类型缺陷等五类。同时把针对安全协议的各种攻击方法可分为：重放消息型攻击、猜
形式化方法与软件可靠性 作者：郭洋 摘要：形式化方法是一种基于数学的表示方法。它能帮助发现其它方法不容易发现的系统描述的不一致，不明确或不完整，有助于增加软件开发人员对系统的理解，因此形式化表示方法是提高软件系统，特别是提高安全苛刻系统的安全性与可靠性的重要手段。软件测试作为提高软件可靠性的一种形式化方法，在不同层次不同阶段可采取不同的方式方法。测试覆盖准则是判断测试充分性的重要手段。 关键词：形式化方法；软件；可靠性；软件测试；测试覆盖 形式化表示方法的出发点是数学逻辑方法。其目的是开发可靠的软件产品。以目前常用软件开发方法为出发点，主要研究怎样将这些方法形式化，使软件系统的描述更精确化，以减少可能的误解所带来的问题；或以目前常用的软件开发过程为出发点，研究怎样在软件开发过程中增加一些形式化方法的应用，以提高软件的可靠性。 1 什么是形式化方法 形式化方法是描述系统性质的基于数学的技术。这样的形式化方法提供了一个框架，人们可以在框架中以系统的而不是特别的方式刻划、开发和验证系统。如果一个方法有良好的数学基础，那么它是形式化的，典型地以形式化规约语言给出的。这个基础提供一系列精确定义的概念，如一致性和完整性，以及更进一
步，定义规约、实现和正确性。 形式化方法的一个重要研究内容是形式规约，它是对程序“做什么”的数学描述，是用具有精确语义的形式语言书写的程序功能描述，它是设计和编制程序的出发点，也是验证程序是否正确的依据。对形式规约通常要讨论其一致性和完备性等性质。形式规约的方法主要可分为两类：一类是面向模型的方法也称为系统建模，该方法通过构造系统的计算模型来刻画系统的不同行为特征；另一类是面向性质的方法也称为性质描述，该方法通过定义系统必须满足的一些性质来描述一个系统。不同的形式规约方法要求不同的形式规约语言，即用于书写形式规约的语言，如代数语言One/Two等；进程代数语言；时序逻辑语言等；这些规约语言由于基于不同的数学理论及规约方法，因而也千差万别，但它们有一个共同的特点，即每种规约语言均由基本成分和构造成分两部分构成。前者用来描述基本规约，后者把基本部分组合成大规约。构造成分是形式规约研究和设计的重点，也是衡量规约语言优劣的主要依据。 形式化方法的分类：（1）根据说明目标软件系统的方式，形式化方法可以分为面向模型的形式化方法和面向属性的形式化方法。（2）根据表达能力，形式化方法可以划分为基于模型的方法、基于逻辑的方法、代数方法、过程代数方法、基于网络的方法。 2 软件可靠性的定义 软件可靠性是软件系统固有特性之一，它表明了一个软件系统按照用户的要求和设计的目标，执行其功能的正确程度。软件可靠性与软件缺陷有关，也与系统输入和系统使用有关。理论上说，可靠的软件系统应该是正确、完整、一致和健壮的。但是实际上任何软件都不可能达到百分之百的正确，而且也无法精确度
根据说明目标软件系统的方式，形式化方法可以分为两类： 1）面向模型的形式化方法。面向模型的方法通过构造一个数学模型来说明系统的行为。2）面向属性的形式化方法。面向属性的方法通过描述目标软件系统的各种属性来间接定义系统行为。 根据表达能力，形式化方法可以分为五类： 1）基于模型的方法：通过明确定义状态和操作来建立一个系统模型（使系统从一个状态转换到另一个状态）。用这种方法虽可以表示非功能性需求（诸如时间需求），但不能很好地表示并发性。如：Z语言，VDM，B方法等。 2）基于逻辑的方法：用逻辑描述系统预期的性能，包括底层规约、时序和可能性行为。采用与所选逻辑相关的公理系统证明系统具有预期的性能。用具体的编程构造扩充逻辑从而得到一种广谱形式化方法，通过保持正确性的细化步骤集来开发系统。如：ITL（区间时序逻辑），区段演算（DC），hoare 逻辑，WP演算，模态逻辑，时序逻辑，TAM（时序代理模型），RTTL（实时时序逻辑）等。 3）代数方法：通过将未定义状态下不同的操作行为相联系，给出操作的显式定义。与基于模型的方法相同的是，没有给出并发的显式表示。如：OBJ，Larch族代数规约语言等；4）过程代数方法：通过限制所有容许的可观察的过程间通信来表示系统行为。此类方法允许并发过程的显式表示。如：通信顺序过程（CSP），通信系统演算（CCS），通信过程代数（ACP），时序排序规约语言（LOTOS），计时CSP(TCSP），通信系统计时可能性演算（TPCCS）等。 5）基于网络的方法：由于图形化表示法易于理解，而且非专业人员能够使用，因此是一种通用的系统确定表示法。该方法采用具有形式语义的图形语言，为系统开发和再工程带来特殊的好处。如Petri图，计时Petri图，状态图等。
形式化方法和半形式化方法 扬州职大电大贾湛2007.1.20 古代东西方的文化差异，让东西方走上了不同的路。西方人在求真上的突破，为后来的科学埋下了种子，又为真善美的全面发展下了基础。而我们古代中国则把重点放在求善上，自然因为没有真的帮助，让社会停滞。为什么这么说呢？如果能理解科学方法中非常重要的形式化方法，则我们就知道我们的大脑是怎样被科学开发的了。 形式化指公理系统中所有的概念定义后都用符号表示，推理规则约定后也用符号表示，公理、定律和定理等也完全用符号表示出来。古代人不象现代人懂得思维的规律，这些方法几乎是受逻辑学的影响慢慢地自发产生的。 思维形式化有什么好处呢？现在我们可以解释了，因为我们每个人思维能力都是有限的，打比方说，我们的大脑在推理能力（希望不要理解为综合能力）上讲像是一台很笨的电脑，不仅CPU的时钟频率即在单位时间内的运算次数非常有限，基本字长（参加一次定点运算的操作数的位数）非常短，远远不能与我们现在32位或64位的计算机相比，而且内存也很有限…。这就决定了人们用生活语言难以有深入的推理，西方人由于各种原因在求真上比东方人重视，逐渐明白了这一点，所以一步步将推理形式化，逐步拉开了与东方人的差距。为了理解，我们来看一下数学形式化的发展过程。 古埃及人曾使用一种古老的象形文字作为数字符号： 显然这种方法表示繁琐，古巴比伦人的符号较之简单。用一种特制的硬笔压进湿的粘土板中： 代表1或60或3600，根据具体情况而定 代表10。25= 在3000多年前的殷商时期的甲骨文： 这些符号后来逐渐演变成了“一，二，三，四，……十，百，千，万”等字，但由于这些符号在运算时不方便，到春秋战国时期我们的祖先创造了筹算。筹算用的算筹是竹制的小棍，也有骨制的。筹算有
软件开发中的形式化方法 郑红军张乃孝 （北京大学计算机科学技术系，北京 100871） 摘要本文基于研究的角度，首先讨论了在软件开发过程各阶段使用形式化方法的可能及困难，进而研究了形式化方法在理论上和应用上的能力、局限性及其产生原因，以及由此产生的对形式化方法的讨论。最后，综合上述讨论，从形式化方法的实质出发，在方法上，对形式化方法的研究提出了几点建议，以及基于这些建议所能看到的形式化方法研究可能的一些发展方向。 关键词形式化方法软件开发 1 形式化方法 随着软件系统复杂度的不断增长，开发正确、可靠的软件，成为一个急待解决的问题。解决此问题的一个有前途、有希望的技术是形式化方法的应用。形式化方法建立在严格的数学基础上，其目标是希望能使系统具有较高的可信度和正确性，并能使系统具有良好的结构，使其易维护，关键是能较好地满足用户需求。 “形式化方法”一词虽然一直被广泛地应用，但在不同程度上，因理解不同，使其具有了不同的含义。一般说来，形式化方法是指具有坚实数学基础的方法，它是数学上的综合、分析技术的应用，用于开发计算机控制的系统，经常有推理工具的支持，它可提供一个用于模型设计和分析的一个严格而有效的途径。从形式系统和复杂问题的本质来看，还未有一个适于全面描述和分析一个复杂系统的形式系统。所以，可以说，一个“形式化方法”并不是系统设计者开发系统时可能选择使用的方法，而只是设计者在此过程中希望利用的一种工具之一[Wood* 1988]。 总体上，形式化方法大致可分为五类[Barroca* 1992]： （1）基于模型的方法—给出系统（程序）状态和状态变换操作的显式但亦是抽象的定义，但对于并发没有显式的表示，如：Z和VDM[Jones 1990]。（2）代数方法—通过联系不同操作间的行为关系而给出操作的隐式定义，而不定义状态，同样，它亦未给出并发的显式表示，如：OBJ、CLEAR。（3）过程代数方法—给出并发过程的一个显式模型，并通过过程间允许的可观察的通讯上的限制（约束）来表示行为，如：CSP、CCS。 （4）基于逻辑的方法—有很多方法采用逻辑来描述系统的特性，包括程序行为的低级规范和系统时间行为的规范，如：时态逻辑[Galton 1992]。 ------------------------------------------------------------------- *本文受到国家自然科学基金项目和863-306项目资助 （5）基于网络的方法—根据网络中的数据流显式地给出系统的并发模型，包