民用飞机机载系统和设备软件设计要求

民用飞机机载系统和设备软件设计要求本标准规定了民用飞机机载系统和设备软件开发过程中的软件需求分析、软件体系结构设计和软件详细设计等软件设计要求。本标准适用于民用飞机机载系统和设备的软件设计过程。2规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。GB/T11457-2006软件工程术语3术语和定义GB/T11457-2006界定的以及下列术语和定义适用于本文件。派生需求derivativerequirements软件开发过程产生的附加需求，它不可以直接追踪到高级需求。设计模型deignmodel定义软件设计的模型，如低层次需求、软件架构、算法、组件内部数据结构、数据流和/或控制流。用于生成源代码的模型是设计模型。在系统运行中，根据需要进行分配，远行结束后应释放的内存空间。外部接口eaternalinterfaceCSCl与其他CSCl或硬件之间的数据关系。一个模块被其他模块调用。一个模块直接调用其他模块。高层需求high-levdrequirements分析系统需求、安全性有关的需求及为系统设计结构而开发的需求。2对系统方面的给定集合的抽象表示，用于系统的分析、验证、仿真、代码生成或这些工作的组合。出于系统安全和可靠性等方面的考虑，人为地对一些关键部件或功能进行重复的配置。产品具有的不导致人员伤亡、系统毁坏、重大财产损失或不危及人员健康和环境的能力。共享内存sharedmemory在多处理器的计算机系统中，可被不同CPU访问的大容量内存。描述高层需求的模型，该模型提供了软件组件的功能、性能、接口或安全特定的抽象描述。规范模型不定义软件设计细节，如内部数据结构、内部数据流或内部控制流。用户可修改软件usermodifiablesoftware在原认证项目中规定的修改限制范围内，未经过认证机构、机身制造商或设备供应商的审查，而进行修改的软件。下列缩略语适用于本文件。COTS-commercialoff-theshef,商用现货；CPU—centralprocessingunit,中央处理器：CSC—computersoftwarecomponent,计算机软件部件：CsCl-computesoftwareconfiguratianitem,计算机软件配置项：CSu-computersoftwereunit,计算机软件单元；FMECA—failuremodeeffectsandcriticalityanalyss,故障模式、影响及危害性分析；FTA-FaltTreeAndysis,故障树分析。5.1软件需求分析5.1.1软件需求分析的目标软件需求分析的目标是依据软件的策划过程，基于系统要求和系统架构的分析，开发出软件的高层需求。软件高层需求包括功能需求、性能需求、接口需求和安全性相关的需求，以及在系统安全性评估过程中明确派生的高层需求。5.1.2软件需求分析输入用于软件高层需求分析的输入，包括需求标准、分配给软件的系统需求、安全性相关要求、软硬件接口定义和系统架构。5.1.2.2需求标准高层需求分析应满足以下要求：a)能够正确地体现软件产品具有的特性；b)确保软件需求实现；c)确保软件需求对于设计过程是足够完整的；d)确保每条需求描述详细、准确且无歧义性；e)确保分析的软件需求与更高层需求一致，可以满足更高层需求的目标；f)详细描述需求，以确保可以成为软件设计和测试的依据并具有可验证性；g)确保每条需求都有明确的出处并且便于跟踪、或被其他文档引用；h)标识对成本、进度、功能性、风险或性能有强烈影响的关键需求。5.1.2.3模型标准模型标准定义了每种类型模型的建模技术。每种建模技术的定义应包括下列内容；al用来开发模型的方法和技术；b)要使用的建模语言，对于每种建模语言，针对该模型所代表的软件生命周期数据的类型，对清晰定义该种语言语法和语义的数据进行引用。必要时，对该建模语言的某些功能进行限制使用说明；c)用于标识并限定模型中包含的需求的方法，以及在需求和其他生命周期数据之间建立可追溯性的途径；d)用于标识并限定模型中包含的派生需求方法，以及向系统流程(包括系统安全评估流程)提供这些派生需求的方法：e)用于标识无助于表示软件需求或软件架构，且不是后续软件开发流程或活动输入的每一个模型元素的方法：f)规范模型或设计模型所表述信息类别的技术适合性的依据。5.1.2.4分配给软件的系统需求分配给软件的系统需求，用于确定该软件在任何可预见的运行条件下正确地执行其预定功能。一般应包括：a)功能和操作要求，包括功能描述和用户操作描述等；b)接口要求，包括内部接口和外部接口；c)性能要求，包括性能分析、时间和内存空间限制等：d)维护要求：e)设计约束，包括设计限制条件和分区要求等；f)数据安全性、保密性要求，包括定义使用的各种数据，说明数据的约束；定义被采集数据的特性和要求和范围；g)认证要求，包括任何适用的认证机构规章和发行文件等；h)为软件生命周期过程提供帮助所需的附加要求5.1.2.5安全相关要求安全相关要求包括安全策略、设计限制条件和设计方法，如分区、多版本非相似软件、冗余成安全性监控等。当该系统为另一系统组成部分时，另一系统的要求和失效条件也可作为系统安全性要求的一部分分配给软件。安全相关要求一般由系统向下传递，或是系统在初步的安全性评估结果中获得的与软件相关的安全性需求，其中，也有少数是软件开发过程中新识别再由系统采纳下达的。为了避免重复和遗漏，也可将领域经验提炼总结，形成专属领域的通用安全需求，通用安全需求会随着技术进化或新应用的实现而更新。系统安全性要求的输入一般应包括：a)飞机级功能危害性评估报告：b)系统级初步的安全性评估报告；5c)系统安全性工作计划等。5.1.2.6软硬件接口定义软硬件接口定义了系统中软件与硬件之间的数据传递，一般应包括：a)硬件/软件集成所需的接口需求以及派生需求，如用于硬件和软件之间接口的协议、时序限制条件和解决方案的定文等：b)硬件和软件验证活动需要协调的情况。5.1.2.7系统架构在系统的设计过程中确定系统架构，一般应包括：a)系统设计说明；b)系统总体设计要求；c)系统设计标准。在软件设计过程中，任何影响软件更改的用户要求或问题报告，均应作为软件需求分析的输入，并对设计进行迭代。5.1.3软件需求分析的一般要求5.1.3,1一般要求高层需求包含软件需求以及派生需求。软件需求分析应满足以下要求；a)对每条分配给软件的系统需求，均需要在高层需求中进行定义、分解或说明，包括与安全性有关的要求和潜在的失效状态：b)如果软件在多种状态或方式下运行，并且不同的状态或方式具有不同的需求，则标识和定义每种状态和方式，并描述每种状态或方式下的操作要求。状态和方式的示例包括正常、准备和紧急情况等；c)确保分析的高层需求符合软件需求标准，与分配给软件的系统需求一致，并且是可追踪和可验证的；d)标识对成本、进度、动能、性能、质量、风险或环境要求等方面有强烈影响的关键需求；e)描述高层需求的优先级，以标识其优先顺序；f)确保每条高层需求的描述详细、准确，无歧义；如果发现有歧义、不一致或未定义的高层需求，需要迭代需求分析活动，或反馈至软件生命周期过程、分配给系统的软件需求，直至高层需求完善，或取消有歧义、不一致的地方；g)如适用，软件的高层需求应采用含误差范围的定量术语陈述；h)定义派生的高层需求及其存在的原因；i)派生的高层需求需提交系统生命周期过程，包括系统安全性评估过程；j)除规定的合理设计约束外，高层需求不描述设计细节或验证细节。5.1.3.2基于模型方法的分析要求在基于模型的需求分析中，高层需求表现为规范模型。采用基于模型的方法时，应满足以下要求：a)能详细描述功能、性能、接口或安全特性的抽象表征：b)从功能、行为和数据等多个视图分析需求，对于显示系统中有用户界面的配置项，开发用户界面原型；c)采用软件故障树的方法对安全性需求进行分析；6d)规范模型应足以支持设计模型的实现和验证。如：包含支持设计模型的开发和验证的详细信息的级别；提供软件功能的功能说明等；e)对规范模型的建模语言及工具使用定义指导原则和复杂度限制，例如；命名习惯、示意图布局、可允许的元素、嵌套级别最大数量、每个示意图的模型元素最大数量、架构层级的最大数量；f)对规范模型的建模工具及模型元素库的使用做出要求；g)对不描述软件需求且不作为后续软件开发工作输入的所有模型元素(例如注释块)进行标识：h)标识为完成或实现任何高层需求而派生的规范模型元素：i)在分析过程中，若发现系统需求存在缺陷时，有些模型也可以加添到系统需求中。5.1.4软件需求分析的具体要求应详细分析需求输入，对分配给软件的需求进行划分，分析划分的软件配置项之间如何交互，以及每个划分的软件配置项的级别，并将其转化为软件的功能、性能、接口、数据和软件安全性等方面的高层需求。5.1.4.2功能和性能功能和性能需求分析应满足以下要求：al确定与功能有关的所有信息，并按某种合适的结构组织功能需求，包括模式、对象、特征、激励和层次等；b)确定系统的容量要求，包括处理和记录数据的最大容量；c)确定系统的精度要求，包括数据传输的精度；d)确定系统的时间特性要求，包括处理时间和响应时间等。内部接口需求分析应包括：a)接口的优先级：b)接口的类型；c)接口需提供、存储、发送、访间和接受的数据元素特征；d)用于接口的通信方法；e)接口所需的协议。一般情况下，软件的内部接口也可在设计时描述。5.1.4.4外部接口外部接口需求分析应包括；a)与外部设备接口的需求分析，一般包括接口的优先级，接口类型的要求，软件应提供、储存、发送、读取、接受的各数据元素所要求的特征，和使用接口的通信方法b)与其他系统的接口；c)确定人机界面和操作方法等用户接口。5.1.4.5数据处理数据处理需求分析应满足以下要求：al定义系统使用的各种数据：b)规定静志数据、动态输入输出数据；c)说明对数据元素的约束。7环境需求分析应包括：a)硬件环境；b)软件环境。5.1.4.7安全性分析安全性需求分析应根据系统安全相关要求的输入，查找关键安全功能，确定安全性需求。查找关键安全功能的方法主要有基于软件功能的FTA和FMECA。软件安全性分析应重点考虑以下内容：a)安全运行模式、运行状态和安全条件；b)容错和失效，包括失效状态及其影响、失效状态等级以及验证方法等；c)危险命令处理：d)分配给软件的功能研制保证等级；e)派生的安全性需求。5.1.4.8配置数据分析某些安全关键系统会被设计为可配置的。此时，应依据系统需求或配置文件设计规格说明来捕获配置数据的需求，并将配置数据的需求分析为一条或多条高层需求。一般应包括：a)确定配置数据的使用形式。包括现场可加载、用户可修改等；b)通过安全性评估，确定配置数据适用的软件级别；c)配置数据需包含的数据内容。包括激活或不激活的功能、建立时间和内存分区分配、为软件提供的初始值等。应在分配给软件的系统需求和高层需求之间建立可追溯性，一般应包括：a)每条分配给软件的系统需求可追溯至一条或多条高层需求；b)除派生需求外，每条高层需求可追溯至至少一条分配给软件的系统需求。基于模型开发的可追溯性与使用传统方法的开发的可追溯性要求相同，重点是划分基于模型的逻辑关系中的层级关系，建立各种模型元素之间的关联关系。也可将模型变为条目列表并进行跟踪管理。5.1.5软件需求分析输出在软件需求分析的基础上，确定所开发软件的功能、性能、接口、数据、环境要求和约束条件，并将需求文档化，来描述这些需求。软件需求分析的输出应包括；a)软件需求规格说明或高层需求：b)软件高层需求与分配给软件系统需求之间的追踪关系；c)规范模型(若有):d)系统功能危害性评估报告。5.2软件体系结构设计5.2.1软件体系结构设计目标软件体系结构设计的目标是根据软件的高层需求，定义出待开发软件的全貌，记录软件的重要设计决策，并指导之后的详细设计和实现工作。5.2.2软件体系结构设计输入软件体系结构设计的输入包括软件高层需求、软件需求规格说明文档和软件设计标准。若高层需求描述为规范模型，应提供以下数据作为输入：a)规范模型开发的需求依据；b)模型配置项(描述模型的文件或数据);c)软件建模技术的标准或规范；d)模型元素库：e)建模技术的开发环境和用户手册。5.2.3软件体系结构设计的一般要求5.2.3.1一般要求软件体系结构设计应满足以下要求：a)准确地依据高层需求和派生的高层需求，如果发现有歧义、不一致或者未定义的地方，需要迭代软件设计活动，或反馈至软件生命周期过程、高层需求/派生的高层需求、分配给软件的系统需求，直至设计完善，或取消歧义和不一致的地方；b)可采用自顶向下或并发等方法进行；c)确保在现行软/硬件环境条件下是可行的；d)指明部件的层次特性(各部件间的控制关系和相互作用)和过程特性(部件间的时间关系和顺序关系):e)完整地描述每个部件的静态特征，一般包括：1)名称(标识符);2)作用(简要功能描述);3)类型(如进程/线程、临时/永久);4)位置(运行所在的处理机);5)特权(如对资源的访问特权):6)资源需求(如存贮页面、CPU、文件、公用区、同时占用的资源数);7)静态组织(即其下层的组成成份)。f)完整地描述每个部件的动志特征，一般包括：1)运行激活条件；2)初始化处理要求；3)运行优先级要求：4)输入信息(源、类型、格式、量化单位、值域，精度和周期);5)输出信息(目的地、类型、格式、量化单位、值域、精度和周期):6)部件的处理逻辑及其每个异常情况的处理要求；7)运行中的各种状态及其转换条件；8)部件间的通信关系；9)部件间的同步关系：10)运行终止条件。g)借助规范化的结构图，其中各种图形符号应使用标准符号、每个部件只能出现一次、一个决策的影响域应是其所在部件控制域的一个子集；h)按命名规则对配置项、部件、单元、接口数据和变量命名；i)所有已定义的元素(如CSCl、CSC、接口数据和变量等)均应被引用；所有被引用的元素均已B9定义。5.2.3.2基于模型方法的要求设计模型可以部分或全部表述软件体系结构和/或低层需求，采用基于模型的方法时，设计模型应满足以下要求：a)规定内部数据结构、数据流和控制流；b)对软件架构的描述，该软件架构可定义软件结构，以便实现需求：c)列出所有的系统需求和安全需求，确认每个预期操作的功能是否有对应的分解，每个非预计后果的保护功能是否也有对应的分解；d)对设计模型的建模语言及工具使用定义指导原则和复杂度限制，例如：命名习惯、示意图布局、可允许的元素、嵌套级别最大数量、每个示意图的模型元素最大数量、架构层级的最大数量：e)对设计模型建模工具使用及模型元素库的使用做出要求；f)标识为完成或实现任何软件体系结构而派生的设计模型元素。5.2.4软件体系结构设计的具体要求体系结构设计侧重选择软件质量属性的设计策略，确定设计模式，定义软件部件，设计软件接口(包括软件与外系统之间，软件与用户之间，以及软件部件与部件之间的接口)。使软件系统在架构层面的设计上满足功能性和非功能性的高层需求。设计决策通常包括分配至各个软件部件的需求分配方案，也包括在软件体系结构中使用COTS软a)方案应涵盖成本、进度和性能可接受的范围，方案选择应考虑以下因素：1)开发、维护和支持等成本；2)软件部件的复杂度；3)性能、技术约束和风险，如选定的算法/规则，对非法输入或条件的处理；4)对软件操作、使用条件、运行模式、环境等的健壮性；5)最终用户的能力和限制。b)选择COTS软件。COTS软件可以直接使用或修改后使用。如果COTS软件的软件生命周期资料存在缺失，需补充相关资料才可使用。c)为满足安全性和保密性需求所选择的方法。以及为提供灵活性、可用性、可维护性等所选择的方法。如操作系统和开发语言的选择等。d)如果选择的硬件和操作系统支持分区，考虑最大限度地利用分区，以便于检测和隔离故障，减轻软件组件的验证负担。5.2.4.3结构分层结构分层应满足下列原则：a)将部件按控制(调用)关系在逻辑上构成层次结构，软件结构的形态特征应呈树型结构；b)使高层有较高的扇出，低层有较高的扇入；c)下层处理的输出数据定义于其上层调用者，并受其控制：d)下层处理的控制返回至其上层调用者：e)下一层部件的处理独立于其上一层部件(调用者)。5.2.4.4部件设计通常意义的部件是对软件有意义的分组，在面向对象中表现为类、包和子系统。每个部件应相对独立。设计时应满足下列要求：a)赋予每个软件部件唯一的标识符；b)可采用图标和描述来说明各软件部件间的动态关系，如部件的调用关系、控制流程、数据流图、状态转换图、时序图、活动图等。部件间调用不宜采用直接访问部件内部有关信息的方式；c)限制部件间传递的参数个数，控制交联关系。部件间的公用信息作为参数显式传递：d)部件的独立性应以提高其内聚度，降低耦合度来实现；e)部件/软件单元内的变量要局部化；f)将可能发生变化的因素或需经常修改的部分尽量放在少数几个部件中；g)说明软件部件的开发状态/类型，如新开发、重用已有部件或为重用而开发的部件等。针对重用的部件，说明其详细信息，如名称、版本、引用来源等。还该识别产生的派生需求和任何需停用的功能。5.2.4.5内部接口和数据设计内部接口和数据设计应满足下列要求：al详细定义部件间的所有接口数据：b)在各层次之间接口的存取和使用方式一致；c)按标准的表示法使用数据，按标准格式描述接口数据；d)以某一类型定义的数据在其使用全过程中始终保持类型不变；e)尽可能不用或少用全局数据；f)指明变量的定义域(值域),必要时进行值域检查；g)在处理开始前，所有的输入均是可用的。5.2.4.6外部接口设计外部接口设计应满足下列要求；a)确定软件与其他系统的接口，并说明对系统的要求；b)说明接口的目的、传输速率、要交换的数据、数据传输量、传输数据格式及其转换要求：c)在传输数据前，检测通信通道状态；d)对模拟和数字输入、输出信息作极限检测或合理性检测：e)设计硬件接口的软件时，对外部输入、输出设备做故障检测，并正确处理故障；f)在设计硬件接口的软件时，预定信息传输格式和内容，考虑接口元器件的故障模式；g)人机界面的交互方式应清晰、简明：h)合理设计警报、告警信息。对性能的设计应满足下列要求：a)尽量减少软件处理时间对资源的需求，包括采用适合的优化算法、控制队列长度等：b)尽量用多个线程并行处理事件，提高资源利用率；c)分区或模块中使用的任务在启动初始化时配置和创建。禁止动态创建任务；d)如需要，可定义事件优先级，合理调度资源。5.2.5软件体系结构设计的输出根据软件高层需求，开发出软件体系结构，并将其文档化。软件体系结构设计的输出可能为：a)软件设计文档中架构设计部分的文档；b)COTS软件评价报告(如有);c)软件体系结构；d)设计模型(如适用)。5.3软件详细设计5.3.1软件详细设计目标软件详细设计的目标是根据高层需求和定义的软件体系结构，开发软件的低层需求(包含派生的低层需求),对每一个CSU进行设计，分析系统所采用算法的逻辑关系，并给出明确、清晰的表达，为软件实现提供必要的说明。5.3.2软件详细设计输入软件详细设计的输入应包括：a)软件的高层需求；b)软件的体系结构：c)软件的设计标准。5.3.3软件详细设计的一般要求5.3.3.1一般要求软件详细设计应满足4.2.3的要求。对于每一个软件单元，详细设计信息描述应满足下列要求：a)输入/输出数据元素：标识该CSU的每一个输入和输出数据元素，并说明其用途，提供这些数据元素的设计信息：b)局部数据元素：标识该CSU内部产生的且不被其他CSU使用的每一个数据元素，并说明其用途，要描述每一个数据元素的名称、简要说明、数据类型、数据表示、大小、量纲、限值/值域、精度、分辨率以及任何其他属性，可以通过CSC局部数据表来描述这些信息；c)中断和信号；标识该CSU处理的中断和信号，并说明其来源、目的、优先级、期望响应和响应时间、最大值、最小值和发生的概率；d)算法：标识算法，并描述其目的和细节。算法的描述应包括对输入和内部数据元素的处理以及输出数据元素的生成：e)错误处理：标识和描述CS的错误诊断和恢复功能，包括对错误的输入数据和影响CSU执行的其他条件的处理；f)数据转换：标识和描述为实现CSU的接口需实现的数据转换操作；9)其他元素的使用。描述CSU使用的其他元素，它包括但不限于：1)其他CSU(如库函数调用、访问数据库、海量存储设备和实时I/O通道的1/O服务调用):2)全局内存中的共享数据(如数据库或数据文件、表、公用数据块);3)输入输出缓冲区，包括消息缓冲区。h)逻辑流程。根据a)到g)项内容描述CSU的逻辑流程。应描述启动CSU执行的条件、被激活的通信接口功能(如有)、把控制传给其他CSU的条件等。如果在CSCl的操作期间，执行顺序是动态控制的，则应描述顺序控制的方法以及该方法的逻辑和输入条件，如定时变更、优先级分配、内部存储器的数据移入移出的内部操作、离散输入信号的判读以及CSCl的各种操作之间的定时关系：i)数据结构。描述CSU实现的局部数据结构以及CSU使用的所有共享数据结构；j)局部数据文件或数据库。如果数据文件或数据库是CSU的局部数据的一部分，则说明其用途，并用记录、字段等描述其结构，还要说明其访问机制(如顺序的、随机的);k)局限性：描述限制CSU性能的任何局限性或独特功能；D定义和分析派生的低层需求及其存在的原因，以确保不会影响较高级别的需求；m)软件设计活动可能将故障模式引入到软件中，也可能防止某些故障模式。在软件设计中使用划分或者其他架构方法可能会改变软件的某些组件的软件级别分配。在这种情况下，将其他数据作为派生的低层需求定义并提供给系统流程(包括系统安全评估流程):n)定义其他派生的低层需求并向系统流程提供(包括系统安全评估流程)。5.3.3.2基于模型方法的要求采用基于模型的方法时，用于描述软件体系结构和/或低层需求的设计模型，除了应满足4.2.3.2的要求外，还应满足下列要求：a)对软件如何满足规定的高层需求(包括算法、数据结构、以及如何将软件需求分配到处理器和任务)的详细描述；b)输入/输出描述，例如；数据词典，包括贯穿软件架构的内部和外部词典；c)设计模型的数据流和控制流；d)资源限制、用于管理每项资源及其限制的策略、测量的方法，如计时和内存；e)调度步骤及处理器/任务间通讯机制，包括时间排序、抢先调度和及中断：f)设计方法及实现这些方法的细节，如软件加载、用户可修改软件或多版本非相似软件；g)划分方法及防止违背划分的途径；h)对软件组件的描述，这些组件是新组件还是此前开发的，如果是此前开发的，可参照取得这些组件的基线：i)分析由软件设计流程导致的派生的低层需求；j)标识为完成或实现任何软件低层需求而派生的设计模型元素；k)如果设计模型描述了低层需求和/或架构，则标识没有描述系统需求或软件架构并且并非后续软件开发流程或活动的输入的所有模型，如注释块；1)某些设计决策可追溯至与安全有关的系统需求的理论依据。5.3.4软件详细设计的具体要求5.3.4.1完整性软件详细设计的完整性应满足下列要求：a)每条高层需求，都应定义、分解或说明为软件低层需求；b)有充分的资料(如逻辑结构图、算法、存贮分配图等)保证设计的完整性；c)算法和公式等要充分、准确和完善：d)标识出程序的每一个输入、输出或数据库成份：其描述应达到可编码的程度；e说明程序的操作步骤和处理步骤；f)考虑到所有可能的情况和条件；g)指明在出现异常情况和不正当输入的情况下的行为。软件详细设计的一致性应满足下列要求：al不能包含内在的矛盾；b)计算中的输入、输出和数据库数据的计量单位、计算精度和逻辑表达式一致；c)对失效状态的响应与安全性相关的需求保持一致。b)与模型、算法和数值定义一致；c)正确实现上层所确定的输入、输出和数据库所含的数据格式、内容和数据率。5.3.4.4可行性a)所设计的模型、算法和数值定义对于应用领域c)在可用的资源条件下，所设计的功能是能实现的。a)设计覆盖高层需求中所要求的容错和故障处理的需求，减轻故障造成的后果；b)判定所有错误情况，并告警和记录。涉及并发进程的错误检测应做到：在等前，检测该进程是否已启动或已超时。不必等待已终止进程的结束。5.3.4.6安全性软件详细设计过程会引入一些可能的失效模式，同时，也可能阻止另一些失效模式当安全性需求提出诸如看门狗定时器、合理性检查和交叉通道比较等要a)设计中对每一个函数的描述都使用准确的术语和符号；可验证它与需求定义是否一致；b)定量地说明使用条件、限制和处理结果等内容。a)谨慎使用中断嵌套，使用时进行状态保护；b)谨慎使用循环控制语句，避免出现死循环，中断服务程序避免出现超时：c)尽量