郭 蕾， 褚文奎， 田 松， 張鳳鳴

(1.空軍裝備研究院航空研究所，北京 100076;2.空軍工程大學(xué)工程學(xué)院，西安 710038)

0 引言

美國(guó)宇航局在標(biāo)準(zhǔn) NASA-STD-8719.13B［1］中將“直接指揮、控制關(guān)鍵硬件或危險(xiǎn)源”以及“監(jiān)視關(guān)鍵硬件或危險(xiǎn)源的狀態(tài)”的軟件稱(chēng)為安全關(guān)鍵軟件(Safety Critical Software，SCS)。這類(lèi)軟件一旦故障或失效，將導(dǎo)致生命、財(cái)產(chǎn)或環(huán)境等方面難以承受的災(zāi)難性后果。

文獻(xiàn)［2］分析了20世紀(jì)90年代發(fā)生的5起航天器事故，結(jié)論歸咎于軟件存在安全性問(wèn)題;文獻(xiàn)［3］對(duì)國(guó)外發(fā)生在1980～1996年間的8起災(zāi)難性事故進(jìn)行分析，結(jié)果表明軟件需求缺陷是導(dǎo)致這些事故的主要因素;文獻(xiàn)［4］搜集的證據(jù)表明，單元測(cè)試發(fā)現(xiàn)的軟件缺陷和錯(cuò)誤中，需求錯(cuò)誤占70%;文獻(xiàn)［5］的研究數(shù)據(jù)表明，軟件需求缺陷導(dǎo)致的安全性問(wèn)題已占到了60%～80%。這些數(shù)據(jù)無(wú)一例外地說(shuō)明了一個(gè)事實(shí)，即需求缺陷是導(dǎo)致事故發(fā)生的主要根源。

采用基于模型的開(kāi)發(fā)(Model-Based Development，MBD)方法［6］進(jìn)行安全關(guān)鍵軟件開(kāi)發(fā)時(shí)，上述結(jié)論將得到進(jìn)一步印證和鞏固。在MBD方法中，引入了軟件自動(dòng)編碼、自動(dòng)集成、自動(dòng)測(cè)試、自動(dòng)配置等自動(dòng)實(shí)現(xiàn)技術(shù)，這些技術(shù)的引入有效地避免了人為錯(cuò)誤，同時(shí)也使得軟件工程師將工作重心由編碼實(shí)現(xiàn)轉(zhuǎn)向需求模型的構(gòu)建。隨著軟件自動(dòng)實(shí)現(xiàn)技術(shù)的日益成熟，以及人們對(duì)安全問(wèn)題的日益重視，安全關(guān)鍵軟件在編碼實(shí)現(xiàn)、集成測(cè)試等階段引入的足以導(dǎo)致危險(xiǎn)后果的錯(cuò)誤日益減少。相對(duì)應(yīng)地，因需求規(guī)約缺陷所導(dǎo)致的安全性問(wèn)題所占比重日益上升，并逐漸占據(jù)了主導(dǎo)地位。從這個(gè)意義上也可以說(shuō)，在MBD軟件開(kāi)發(fā)方法中，軟件開(kāi)發(fā)能否成功或者運(yùn)行是否安全，更多地取決于軟件需求模型的構(gòu)建而不是編碼實(shí)現(xiàn)。

從需求工程視角而言，軟件需求(可視為目標(biāo))的模糊特征使其可以在不同的抽象級(jí)別上進(jìn)行求精，并最終形成一個(gè)引導(dǎo)系統(tǒng)設(shè)計(jì)的目標(biāo)結(jié)構(gòu)圖。兩種比較具有代表性的基于目標(biāo)的方法是自動(dòng)規(guī)約中的知識(shí)采集(Knowledge Acquisition in Automated Specification，KAOS)［7］和 非 功 能 性 需 求 框 架 (Non-Functional Requirement Framework，NFRF)［8］。

KAOS以目標(biāo)結(jié)構(gòu)的形式支持需求工程。在這種目標(biāo)結(jié)構(gòu)中，高級(jí)目標(biāo)由目標(biāo)系統(tǒng)(包括軟件系統(tǒng)及其環(huán)境)的初始文檔中析出得到，然后反復(fù)求精，直到分配到某個(gè)智能體(比如操作者、硬件設(shè)備、軟件)上。其中，目標(biāo)求精通過(guò)合并自上而下的AND/OR分解模板或領(lǐng)域特定的求精模板得以實(shí)現(xiàn)。KAOS方法的缺點(diǎn)在于它將所有的目標(biāo)都當(dāng)作了硬目標(biāo)，只能以形式化方式進(jìn)行規(guī)約和實(shí)現(xiàn)。實(shí)際上很多質(zhì)量屬性如可靠性、安全性只能以可接受的標(biāo)準(zhǔn)(即軟目標(biāo))進(jìn)行實(shí)現(xiàn)［9］。

NFRF主要用于質(zhì)量需求的表達(dá)和分析。它將非功能需求作為可能會(huì)被違反的軟目標(biāo)，并認(rèn)為只有通過(guò)特定的設(shè)計(jì)技術(shù)才能予以實(shí)現(xiàn)。除了質(zhì)量需求之外，該框架還將設(shè)計(jì)方案的選擇決策和背后的原理作為目標(biāo)。由此，該框架提供了一個(gè)統(tǒng)一模型，能夠利用圖形結(jié)構(gòu)求精并實(shí)現(xiàn)質(zhì)量需求。NFRF的缺點(diǎn)一是不能提供有效的機(jī)制闡明質(zhì)量需求，二是缺乏負(fù)面需求開(kāi)發(fā)方面的實(shí)踐指南［9］。

除此，美國(guó)麻省理工學(xué)院的Leveson教授帶領(lǐng)的團(tuán)隊(duì)還開(kāi)發(fā)了一種意圖規(guī)約［10］結(jié)構(gòu)。該結(jié)構(gòu)分為7級(jí)，每一級(jí)都從人、系統(tǒng)、環(huán)境、驗(yàn)證與有效性確認(rèn)(Verification and Validation，V＆V)的角度設(shè)計(jì)、管理系統(tǒng)規(guī)約，不僅說(shuō)明了系統(tǒng)規(guī)約的內(nèi)容及如何規(guī)約，也說(shuō)明了相應(yīng)的原因。與目標(biāo)層次化分解方法不同，意圖規(guī)約的每一級(jí)并不是對(duì)上一級(jí)信息的精煉細(xì)化，而是從一個(gè)新視角重新審視系統(tǒng)，但上一級(jí)包含了對(duì)下一級(jí)的約束。

假設(shè)在安全性關(guān)鍵系統(tǒng)和安全性關(guān)鍵軟件開(kāi)發(fā)過(guò)程中，已經(jīng)開(kāi)發(fā)出了大量的軟件需求。本文著重探討一種有別于上述方法的新的軟件需求管理方法，避免由于軟件需求的無(wú)序性導(dǎo)致需求缺陷的生成。

1 層次分析法的啟示

1.1 層次分析法

層次分析法(Analytic Hierarchy Process，AHP)［11］由美國(guó)運(yùn)籌學(xué)家Saaty于20世紀(jì)70年代提出，致力于利用定性與定量相結(jié)合的方式解決復(fù)雜的項(xiàng)目評(píng)價(jià)問(wèn)題。

該方法應(yīng)用的首要一步是分解項(xiàng)目評(píng)價(jià)問(wèn)題，按支配關(guān)系建立項(xiàng)目評(píng)價(jià)問(wèn)題的遞階層次結(jié)構(gòu)。這種結(jié)構(gòu)一般分為3層，如圖1所示。

圖1 AHP中的遞階層次結(jié)構(gòu)示意Fig.1 Hierarchy used in AHP method

最高層表達(dá)的是分析問(wèn)題的預(yù)定目標(biāo)或期望實(shí)現(xiàn)的理想結(jié)果;中間層是指為實(shí)現(xiàn)目標(biāo)而涉及的中間環(huán)節(jié)，包括所需考慮的準(zhǔn)則、子準(zhǔn)則等，可以細(xì)分為若干層;最底層表示為實(shí)現(xiàn)目標(biāo)可供選擇的各種解決方案、具體措施等。

1.2 啟示

由層次分析法建立的這種遞階層次結(jié)構(gòu)明確表達(dá)了目標(biāo)(包括子目標(biāo))、準(zhǔn)則(包括子準(zhǔn)則)、方案等各種要素之間的聯(lián)系，具有直觀清晰性。

從需求工程的視角看，如果將軟件需求不斷逐層分解為各種精細(xì)的子需求，而子需求可以通過(guò)相應(yīng)方案予以直接實(shí)現(xiàn)，那么這種遞階層次結(jié)構(gòu)將有助于合理管理軟件需求特別是安全性需求，這對(duì)于消除軟件需求缺陷大有裨益。

2 軟件需求的遞階層次結(jié)構(gòu)

2.1 聯(lián)合與匯聚支持模式

在建立軟件需求的遞階層次結(jié)構(gòu)之前，首先考慮軟件需求上下兩個(gè)層次之間的支持關(guān)系。

一項(xiàng)軟件需求可以在下一層次上分解為一至多項(xiàng)子需求。上層軟件需求是通過(guò)下層所有子需求得到滿(mǎn)足從而得以滿(mǎn)足的。如果下層子需求有任何一項(xiàng)得不到滿(mǎn)足，那么上層需求就無(wú)法得到滿(mǎn)足。本文將這種下層子需求支持上層需求的模式稱(chēng)之為聯(lián)合支持。

實(shí)踐過(guò)程中，一項(xiàng)軟件需求可以由一到多種方案予以滿(mǎn)足。如果將這些解決方案看作是上層需求的子需求，那么這意味著上層需求可以由任一下層子需求得到滿(mǎn)足從而得以實(shí)現(xiàn)。本文將這種下層子需求支持上層需求的模式稱(chēng)之為匯聚支持。兩種支持模式分別用如圖2所示的符號(hào)進(jìn)行表示，其中，箭頭代表需求分解方向。

圖2 遞階層次結(jié)構(gòu)中的聯(lián)合和匯聚支持模式Fig.2 AND and OR support modes in hierarchy

2.2 需求遞階層次結(jié)構(gòu)

假設(shè)已經(jīng)開(kāi)發(fā)出了所有軟件需求，借鑒AHP的遞階層次結(jié)構(gòu)思想以及圖2所示的符號(hào)，可以建立軟件需求的遞階層次結(jié)構(gòu)，如圖3所示。

圖3 軟件需求的遞階層次結(jié)構(gòu)示意Fig.3 Software requirement hierarchy

相關(guān)要素說(shuō)明如下:

SRi，j，…，n表示遞階層次結(jié)構(gòu)中第 i/i+j/j+ … +n/n層的某項(xiàng)軟件需求。

SRi，j=Ri，j，k表示遞階層次結(jié)構(gòu) 中第 i/i+j/j層軟件需求SRi，j可以在第i/i+j/j+k/k層分解為m個(gè)部分，由這些部分共同構(gòu)成軟件需求SRi，j。比如對(duì)于安全性需求“構(gòu)件A和構(gòu)件B之間的交互是安全的”，可以細(xì)化求精為需求“所有的危險(xiǎn)都已識(shí)別”和“識(shí)別的每個(gè)危險(xiǎn)都已得到充分減輕”。

SRi，j=SRi，j，k表示遞階層次結(jié)構(gòu)中第 2 層軟件需求SRi，j可以在第3層求精為r項(xiàng)軟件需求的任何一項(xiàng)。比如，安全性需求“構(gòu)件A和構(gòu)件B之間的交互是安全的”既可以求精為“危險(xiǎn)從不會(huì)發(fā)生”，也可以求精為“危險(xiǎn)后果已得到充分減輕”。

下層需求得到滿(mǎn)足后，在“與”、“或”邏輯關(guān)系作用下，將能夠確保上層需求同樣得以滿(mǎn)足。

3 遞階層次結(jié)構(gòu)在軟件安全性需求管理中的應(yīng)用

3.1 危險(xiǎn)場(chǎng)景與安全性需求

危險(xiǎn)場(chǎng)景描述了軟構(gòu)件之間交互背離正常行為的場(chǎng)景，這種交互行為將實(shí)現(xiàn)非期望的結(jié)果，可以稱(chēng)之為反目標(biāo)。比如，戰(zhàn)機(jī)飛行員擬投射巡航導(dǎo)彈，卻將飛機(jī)的副油箱意外投射出去，這種異常行為將致戰(zhàn)機(jī)于無(wú)充足返航油量的危險(xiǎn)境地。

規(guī)避反目標(biāo)得以實(shí)現(xiàn)的根本措施在于消除危險(xiǎn)場(chǎng)景。防止系統(tǒng)進(jìn)入危險(xiǎn)場(chǎng)景、導(dǎo)致危險(xiǎn)后果的軟件需求即是軟件安全性需求。在軟件安全性需求的具體技術(shù)實(shí)現(xiàn)上，可以有不同的方案或措施，這些一般統(tǒng)稱(chēng)為危險(xiǎn)規(guī)避或減輕措施。

3.2 軟件安全性需求的遞階層次結(jié)構(gòu)

如果將反目標(biāo)看作是頂層需求，將危險(xiǎn)場(chǎng)景看作是實(shí)現(xiàn)反目標(biāo)的準(zhǔn)則，將軟件安全性需求看作是規(guī)避危險(xiǎn)場(chǎng)景的準(zhǔn)則，將危險(xiǎn)規(guī)避或減輕措施視為規(guī)避反目標(biāo)的解決方案，那么可以建立軟件安全性需求的遞階層次結(jié)構(gòu)，如圖4所示。該結(jié)構(gòu)同時(shí)也說(shuō)明了軟件安全性需求與反目標(biāo)、危險(xiǎn)場(chǎng)景、危險(xiǎn)規(guī)避或減輕策略之間的關(guān)系。

圖4 安全性需求與反目標(biāo)之間的聯(lián)系Fig.4 Relations between safety requirements and anti-goals

相關(guān)要素解釋如下:

1)AGi，i=1，…，m，表示第 i個(gè)具有危險(xiǎn)后果的反目標(biāo)。

2)NSi，j，j=1，…，n，表示能夠?qū)崿F(xiàn) AGi的第 j個(gè)危險(xiǎn)場(chǎng)景。

3)SRi，j表示由 NSi，j派生的安全性需求(當(dāng)然一個(gè)危險(xiǎn)場(chǎng)景可以派生多個(gè)安全性需求，圖4中僅給出一個(gè)示意)。

4)MSi，j，k，k=1，…，r，表示遵循安全性需求 SRi，j的危險(xiǎn)規(guī)避或減輕策略。

由上述要素，給出下述條件。

條件1 任何一個(gè)風(fēng)險(xiǎn)不可接受的危險(xiǎn)場(chǎng)景存在，將導(dǎo)致系統(tǒng)滿(mǎn)足具有危險(xiǎn)后果的反目標(biāo)。換言之，如果系統(tǒng)不處于任何風(fēng)險(xiǎn)不可接受的負(fù)面場(chǎng)景中，那么系統(tǒng)將能夠規(guī)避反目標(biāo)得以實(shí)現(xiàn)的場(chǎng)景?？梢员磉_(dá)為

條件2 安全性需求必須有效規(guī)避危險(xiǎn)場(chǎng)景的出現(xiàn)。即

?i∈［1，m］，?j∈［1，n］，即

條件3 對(duì)于每個(gè)安全性需求，至少存在一個(gè)危險(xiǎn)規(guī)避或減輕策略可以實(shí)現(xiàn)安全性需求，即

比如，針對(duì)圖4有

推論1 如果條件1、條件2、條件3同時(shí)成立，那么實(shí)現(xiàn)所有的危險(xiǎn)減輕策略(即 MSi，j，k，i=［1，m］，j=［1，n］，k=［1，r］)將能確保反目標(biāo) AGi不會(huì)發(fā)生。

推論1可以采用上述條件的傳遞性進(jìn)行證明。

4 案例研究

懸掛物管理系統(tǒng)［12］(Stores Management System，SMS)是現(xiàn)代戰(zhàn)機(jī)遂行對(duì)空對(duì)地作戰(zhàn)任務(wù)不可或缺的重要航空電子系統(tǒng)。它的一項(xiàng)基本功能是發(fā)射或投放導(dǎo)彈、炸彈、副油箱等懸掛物，從質(zhì)量屬性的視角看應(yīng)確保這一投射功能是安全的。

如果將“安全投射懸掛物”作為一項(xiàng)基本的安全性需求，記為S1，1，將“戰(zhàn)機(jī)在炸彈爆炸殺傷半徑范圍內(nèi)投射炸彈”作為反目標(biāo)，記為AG1，1，那么考慮兩種可能危險(xiǎn)場(chǎng)景，一是戰(zhàn)機(jī)在地面滑行或靜止時(shí)意外投射懸掛物，這個(gè)后果足以對(duì)飛機(jī)和地面人員造成災(zāi)難性后果，記為NS1，1;二是戰(zhàn)機(jī)在攻擊投射炸彈時(shí)的飛行高度小于炸彈爆炸殺傷半徑，如此行為將對(duì)己方戰(zhàn)機(jī)和飛行員造成危險(xiǎn)后果，記為NS1，2。對(duì)于這兩種場(chǎng)景，衍生兩項(xiàng)安全性需求，一是禁止戰(zhàn)機(jī)在地面投射懸掛物，記為S2，1;二是警告飛行高度過(guò)低投放懸掛物，記為S2，2。這兩項(xiàng)安全性需求可以初步采用下述危險(xiǎn)減輕策略予以解決，針對(duì)S2，1，以起落架是否有載荷作為炸彈投射的使能條件，如果起落架有載荷，說(shuō)明戰(zhàn)機(jī)在地面上，此時(shí)禁止投射功能，記為 MS3，1，1;針對(duì) S2，2，如果起落架沒(méi)有載荷，此時(shí)比較飛機(jī)飛行高度和該型炸彈的爆炸殺傷半徑，若前者小于后者，予以告警，提示飛行員爬升，記為 MS3，2，1。

由上述需求分析，利用本文的需求層次化分解思想，可以建立這些需求的遞階層次結(jié)構(gòu)，如圖5所示。

圖5 安全性需求遞階層次結(jié)構(gòu)及其與反目標(biāo)之間的聯(lián)系Fig.5 Safety requirements and relations to anti-goals

圖5 中:MS3，1，1SR2，1;MS3，2，1SR2，2;(SR2，1∧SR2，2)SR1，1;(MS3，1，1∧MS3，2，1)SR1，1。

5 討論

傳統(tǒng)的軟件需求多以自然語(yǔ)言形式進(jìn)行表達(dá)，難以理清系統(tǒng)需求、軟件需求、軟構(gòu)件需求等不同層次需求之間的關(guān)系。

本文建立的軟件需求遞階層次結(jié)構(gòu)，有助于進(jìn)行橫向檢查(比如圖 3 中由 SR2，2，1到 SR2，2，n)確保同一層次的軟件需求之間不相互沖突。同時(shí)這種結(jié)構(gòu)也有助于進(jìn)行縱向檢查(比如圖 3 中由 SR2，1到 SR2，1，1)確保不同層次的軟件需求之間的一致性，從而維護(hù)了安全性關(guān)鍵系統(tǒng)的安全性。

由軟件需求的遞階層次結(jié)構(gòu)，能夠建立軟件需求的可達(dá)矩陣和鄰接矩陣［13］。由此，對(duì)某項(xiàng)軟件需求進(jìn)行修改或求精時(shí)，易于觀察其影響范圍，這有助于確保軟件需求的可溯性。

在軟件需求的遞階層次結(jié)構(gòu)中，下一層次的軟件需求是對(duì)上一層次軟件需求的求精和細(xì)化，或者說(shuō)下一層次軟件需求是上一層次軟件需求在遵循某些規(guī)則的前提下的具體實(shí)現(xiàn)。從軟件認(rèn)證的角度看，下一層次軟件需求是上一層次軟件需求的實(shí)現(xiàn)證據(jù)，支撐了上一層次軟件需求的實(shí)現(xiàn)。由此，軟件需求的遞階層次結(jié)構(gòu)有利于支持構(gòu)建一個(gè)完整的、連貫的軟件認(rèn)證案例，從而為后續(xù)認(rèn)證和維護(hù)活動(dòng)提供了幫助。

如果為每項(xiàng)軟件需求分配相應(yīng)的權(quán)重表示可信性，那么利用這種軟件需求遞階層次結(jié)構(gòu)將不僅能夠從眾多候選軟件需求以及危險(xiǎn)減輕策略中篩選最佳的安全性需求及危險(xiǎn)減輕策略，也能夠評(píng)估最終實(shí)現(xiàn)的安全性需求的可信性。

6 結(jié)論

采用自然語(yǔ)言描述的軟件需求容易導(dǎo)致軟件需求之間關(guān)系的不明確性、無(wú)序性。為避免由此引入軟件需求缺陷，本文提出層次化管理軟件需求的思想，建立了軟件需求的遞階層次結(jié)構(gòu)。該結(jié)構(gòu)一方面清晰明確地表達(dá)了不同層次軟件需求之間的關(guān)系，結(jié)合其他工作，這種軟件需求遞階層次結(jié)構(gòu)有助于增強(qiáng)軟件需求的一致性、可溯性等屬性;另一方面該結(jié)構(gòu)突出表達(dá)了軟件安全性需求及其與危險(xiǎn)場(chǎng)景之間的聯(lián)系，有助于消除或降低軟件安全性需求缺陷，從而提高軟件安全性，這對(duì)于軟件需求的后期維護(hù)管理和軟件認(rèn)證都有益處。

［1］National Aeronautics and Space Administration.NASA-STD-8719.13B—2004 Software safety NASA technical standard［S］.Washinton D C:National Aeronautics and Space Administration,2004.

［2］LEVESON N.The role of software in spacecraft accidents［J］.AIAA Journal of Spacecraft and Rockets,2004,41(4):1-27.

［3］楊仕平.分布式任務(wù)關(guān)鍵實(shí)時(shí)系統(tǒng)的防危(safety)技術(shù)研究［D］.成都:電子科技大學(xué)，2004.

［4］MCDERMID J A.Software safety:where's the evidence?［C］//6th Australian Workshop on Industrial Experience with Safety Critical Systems and Software(SCS 2001),Brisbane:Australian Computer Society,2001:1-6.

［5］LUTZ R R.Analyzing software requirements errors in safetycritical,embedded systems［C］//Proceedings of the International Conference on Software Requirements IEEE,1992:53-65.

［6］BIGLARI H.Past,present and future of safety-critical realtime embedded software development［M］.NEW YORK:Fairchild Control Corporation,2008.

［7］LAMSWEERDE A,DARDENNE A,FICKAS S.Goal-directed requirements acquisition［J］.Science of Computer Programming,1993，20:43-50.

［8］MYLOPOULOS J,CHUNG L.Representing and using nonfunctional requirements:a process-oriented approach［J］.IEEE Trans on Software Engineering,1992,18(6):497-499.

［9］WU W.Architectural reasoning for safety-critical software applications［D］.Heslington:University of York,2007.

［10］LEVESON N G.An approach to designing safe embedded software［M］.London:Springer Verlag,2002,LNCS 2491:15-29.

［11］汪應(yīng)洛.系統(tǒng)工程［M］.4版.北京:機(jī)械工業(yè)出版社，2008:120-130.

［12］張鳳鳴，褚文奎，樊曉光，等.綜合模塊化航空電子體系結(jié)構(gòu)研究［J］.電光與控制，2009，16(9):47-51.

［13］王映輝，張世琨，劉瑜，等.基于可達(dá)矩陣的軟件體系結(jié)構(gòu)演化波及效應(yīng)分析［J］.軟件學(xué)報(bào)，2004，15(8):1107-1115.