民用飛機機載系統和設備軟件設計要求本標準規定了民用飛機機載系統和設備軟件開發過程中的軟件需求分析、軟件體系結構設計和軟件詳細設計等軟件設計要求。本標準適用于民用飛機機載系統和設備的軟件設計過程。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)盡量