陳 鑫，王 輝，牟 明

（中國航空計算技術研究所，陜西 西安710068）

0 引 言

民用航空電子系統(tǒng)的開發(fā)在提高生產力和保證安全性這兩方面有著非常嚴格的要求［1］。越來越多的國家將適航標準 DO－178B 《Software Consideration in Airborne Systems and Equipment Certification》（《機載系統(tǒng)和設備合格審定中的軟件考慮》）［2］作為機載軟件必須的資格認證。我國把DO－178B標準作為機載軟件開發(fā)規(guī)范已是大勢所趨。

實際工作中發(fā)現(xiàn)，雖然與機載軟件需求相關的內容在GJB2786A－2009 《軍用軟件開發(fā)通用要求》［3］、GJB141－2004《軍用軟件測試指南》［4］、GJB438B－2009 《軍用軟件開發(fā)文檔通用要求》［5］和 GB/T9385－2008 《計算機軟件需求規(guī)格說明規(guī)范》［6］等眾多標準中均有提及，但是它們大多是策略、過程、準則、要求、標準和模板，沒有明確提出可以滿足DO－178B的要求，對具體的操作步驟更是少有論述，這使得開發(fā)出一份滿足DO－178B要求的機載軟件需求規(guī)格說明書非常困難。本文將通過基于結構化激勵響應（structured stimulus response，SSR）方法的6個具體步驟解決這個難題。

1 DO－178B對機載軟件需求的要求

適航是對載人航空器飛行最低的安全性要求［7］。適航標準DO－178B認為需求是軟件質量的源頭［8］。DO－178B第6.3.1節(jié)和6.3.2節(jié)指明了軟件高級需求和低級需求應該滿足準確性和一致性、可驗證性，以及其他特性［2］。

按照DO－178B標準要求進行軟件測試的策略是由上到下，即依照軟硬件集成測試、軟件集成測試和軟件單元測試的順序進行。如果上一級測試能夠滿足特定級別（A、B、C或D級）軟件的需求和代碼結構覆蓋率要求，就不再執(zhí)行下一級測試。因此，軟件需求應該在盡可能高的層次上為測試人員提供軟件輸入輸出信息。

總之，DO－178B要求機載軟件需求應該是準確的和一致的，可驗證的，并在盡可能高的層次上描述軟件行為。

2 機載軟件需求存在的問題

大型機載軟件通常都具有規(guī)模大、數(shù)據(jù)關聯(lián)復雜、安全級別要求高等特點。它們的需求存在下列問題，達不到DO－178B的要求：

（1）可維護性差：機載軟件的激勵和響應數(shù)量眾多，關系復雜，現(xiàn)有需求中經常把每個激勵和每個響應，連同處理方式單獨描述一遍，這使得軟件需求可維護性差。

（2）相同操作描述不一致：軟件需求開發(fā)人員用自然語言描述相同或相近的操作、狀態(tài)、條件等內容時差異較大，彼此不一致，軟件設計編碼人員和測試人員理解困難。

（3）含有較多不可驗證的信息：開發(fā)出來的軟件需求含有較多設計、編碼、測試、工程管理信息，甚至是硬件信息，這些內容從軟件角度無可驗證性。

（4）低層次需求多，高層次需求少：需求大部分篇幅直接描述軟件中函數(shù)、過程、對象等細節(jié)；高層次需求僅寥寥數(shù)語，這樣的軟件需求并不適用于集成測試。

導致這些問題的主要原因是軟件需求開發(fā)人員還沒有一種滿足DO－178B要求的，適用于大型機載軟件的需求開發(fā)方法。下面先簡要介紹結構化激勵響應（SSR）方法，然后通過需求開發(fā)的6個步驟，解決這些問題。

3 SSR方法及具體步驟

3.1 上述問題的解決途徑

SSR方法最早用于描述Hughes Aircraft of Canada Limited公司開發(fā)的加拿大空中交通自動化系統(tǒng)的軟件需求。后來該方法被逐漸用于安全級別要求高的復雜系統(tǒng)當中，尤其是航空航天領域當中的嵌入式軟件［9］。針對上面提到的機載軟件需求中存在的問題，SSR方法有相應的解決途徑，見表1。

表1 SSR方法對軟件需求存在問題的解決途徑

3.2 具體步驟

從系統(tǒng)需求演進到軟件需求規(guī)格說明書，共分6個步驟，共生成5份文檔，如圖1所示。軟件需求開發(fā)人員通過采用表1所列的解決途徑，執(zhí)行這些步驟，就可以解決軟件需求存在的問題，從而符合DO－178B的要求。

3.2.1 第一步：分解系統(tǒng)需求

系統(tǒng)需求并不具體區(qū)分軟件和硬件各自需要完成的任務［10］，對系統(tǒng)需求直接使用SSR方法明顯不可行。SSR方法的第一步就是把系統(tǒng)需求由外向內分解成多個軟件需求單元。與傳統(tǒng)意義的軟件單元（計算機軟件配置項設計中的一個元素［3］）不同，這里的軟件需求單元是軟件需求開發(fā)過程中相對獨立的一個開發(fā)對象和開發(fā)結果。需求開發(fā)人員對每一個軟件需求單元單獨執(zhí)行隨后步驟。

圖1 SSR方法開發(fā)軟件需求的步驟

由外向內分解系統(tǒng)需求是隨后各個步驟的基礎。它應該基于傳給軟件的激勵和軟件傳出的響應。分解后得到的軟件需求單元粒度應適中。不同類型的機載軟件，軟件需求單元粒度不同，包括的內容也不同。例如：

（1）對于一些基礎軟件，一個軟件需求單元可以包括向用戶提供的一個或幾個應用程序接口，比如嵌入式操作系統(tǒng)中，任務的創(chuàng)建、刪除；數(shù)學庫的正弦函數(shù)等。

（2）對于沒有顯示界面的軟件，一個軟件需求單元可以包括對用戶而言相對獨立的一個功能，比如AFDX交換機軟件中的上電自檢功能；飛行管理系統(tǒng)軟件中的進近模式設置等。

（3）對于有顯示界面的軟件，一個軟件需求單元可以包括顯示界面上的一個功能點，比如飛行顯示器軟件中的空速值、高度值等。

（4）對于有人機交互界面的軟件，一個軟件需求單元可以包括操作者一次操作，比如信息管理系統(tǒng)中修改貨品目錄等。

3.2.2 第二步：激勵和響應分組

本步驟按照軟件需求單元的處理方式，把若干激勵分為一組，若干響應分為一組，使用命名規(guī)范為各組抽象出一個唯一名稱。在隨后的需求分析和編寫需求規(guī)格說明的工作中，可以直接通過組名索引這些激勵和響應，而不必把組中每個激勵，每個響應，連同處理方式單獨描述一遍，從而使得最終的軟件需求精簡，維護方便。

本步驟將生成命名規(guī)范和接口描述文檔。命名規(guī)范包括對激勵組名、響應組名、源頭、目的地和數(shù)據(jù)類型等數(shù)據(jù)的命名要求。

本步驟中，軟件需求開發(fā)人員主要執(zhí)行下列4項活動：

（1）分析軟件需求單元的各種接口，包括：人機接口、硬件接口、通訊接口、與其他軟件的接口等，對每一個接口還應該分析接口中的數(shù)據(jù)名稱及其稱號、數(shù)據(jù)元素組成、數(shù)據(jù)的來源、數(shù)據(jù)的去處、取值范圍和取值含義等。

（2）根據(jù)接口中數(shù)據(jù)的流向，把接口分成激勵（輸入）和響應（輸出）兩大類。

（3）對激勵類和響應類各自包含的眾多接口分組，根據(jù)命名規(guī)范對各個組進行命名。

（4）綜合每個軟件需求單元接口的分析結果，形成項目的接口描述文檔。

激勵類接口分組的首要依據(jù)是軟件對它們的轉換過程相同，而不必考慮它們各自的消息源是否相同，因此，同一個激勵組中不同激勵的消息源可以不同，與之類似，同一個響應組中不同響應的消息目的地可以不同。

激勵組名的形式一般是一個二元組（消息源，消息）或一個三元組（消息源，消息，消息）；其中，“消息源”指明激勵的源頭，“消息”指明激勵的數(shù)據(jù)類型。每個激勵組名在項目中都是唯一的，在對軟件的功能進行分析時可以通過它索引激勵組中的激勵。與之類似，響應組名的形式一般也是一個二元組（目的地，消息）或一個三元組（目的地，消息，消息）；其中，“目的地”指明響應的去向，“消息”指明響應的內容。在對軟件的功能進行分析時也可以通過它索引響應組中的響應。

3.2.3 第三步：確定軟件功能域

本步驟采用黑盒風格分析軟件的功能性需求。黑盒風格基于激勵和響應，考慮系統(tǒng)或軟件在設計和實現(xiàn)上受到的各種限制，分析激勵和響應之間的轉換過程，但不考慮轉換過程的內部設計、編碼、測試、工程管理、以及硬件等細節(jié)。這樣的做法既與用戶角度相同，得到的軟件需求層次較高，便于軟件測試階段能夠從產品的角度最大限度地滿足用戶的需求［11］；又把軟件需求中含有內部細節(jié)的可能性降到了最低，避免了給軟件設計造成過多限制。

在分析轉換過程并描述軟件需求時，需求開發(fā)人員應注意下列三點：①一個軟件需求單元可能含有一個或多個轉換過程；一個轉換過程可以形成一條或多條軟件需求。②不僅要分析正常的轉換過程，還要分析異常的轉換過程，及其產生原因，尤其是在需要對輸入進行有效性檢查的軟件中。③必要時應使用實體關系圖、數(shù)據(jù)流圖、狀態(tài)轉換圖、判定樹和判定表等方法作為需求分析的輔助工具。

本步驟也分析軟件的性能、安全性、可靠性、可測試性、可維護性和可擴展性等非功能性需求［12］，并部分生成需求描述規(guī)范和軟件需求規(guī)格說明書，參見第五步。

3.2.4 第四步：確定軟件數(shù)據(jù)域

本步驟主要是創(chuàng)建數(shù)據(jù)字典。在需求開發(fā)階段，數(shù)據(jù)字典至少應定義用戶數(shù)據(jù)項以確保用戶與需求開發(fā)人員使用統(tǒng)一的定義和術語［13］。

數(shù)據(jù)字典里的“類型名”和“子類型名”，不僅包括軟件開發(fā)所用計算機語言中含有的“類型名”和“子類型名”，還應該包括本軟件項目自己定義的“類型名”和“子類型名”。通常情況下，“激勵組名”和“響應組名”都是“類型名”。

如果多個激勵和響應的類型或子類型各不相同，它們的名字是可以相同的。這樣，數(shù)據(jù)字典即簡潔，又不失明確性。比如：“操作者：＜激勵＞”和“操作者：＜響應＞”兩個聲明就清楚地表明了“操作者”既是激勵（消息源），又是響應（目的地）。

3.2.5 第五步：編寫需求規(guī)格說明

本步驟使用受限的自然語言，綜合第三步和第四步的分析結果，根據(jù)項目軟件需求的描述規(guī)范，依次編寫各個軟件需求單元的功能性需求和非功能性需求。本步驟通過對自然語言施加限制，避免了需求內容的二義性，降低了編寫活動的隨意性，增加了對相同或相近的操作、狀態(tài)、條件等內容描述的準確性和一致性，提高了需求的易理解性。

本步驟將生成需求描述規(guī)范和軟件需求規(guī)格說明書。需求描述規(guī)范的內容至少應該包括：縮減的可用詞匯，約束自然語言使用時的語法和風格，提供標準方法描述重復出現(xiàn)的語句結構和段落結構等。

本步驟中，需求開發(fā)人員應注意下列兩點：

①必須嚴格按照需求描述規(guī)范描述軟件需求。②在盡可能不包含設計信息的情況下，軟件需求描述應該盡可能詳細。不僅包括軟件需求本身，還可以包括激勵和響應的實現(xiàn)途徑。當測試人員讀到這樣的需求后，可以直接通過實現(xiàn)途徑創(chuàng)建激勵，獲取響應，從而方便軟件測試。

3.2.6 第六步：評審軟件需求

軟件需求評審應邀請領域專家、用戶代表、系統(tǒng)設計師、軟件需求分析師和軟件開發(fā)工程師等人員參與，還應邀請軟件測試人員和質量保證人員［14］，主要評審第二步到第五步產生的各個文檔是否明確、正確、完整、一致、可驗證和可追蹤。這些評審內容與DO－178B對軟件需求的要求完全一致。

3.3 軟件需求單元組成和實例

根據(jù)3.2節(jié)的討論和需求管理的要求，用SSR方法開發(fā)出來的軟件需求單元至少應該包括7個組成部分：標題、概述、激勵、響應、轉換過程、聲明和性能［15］。本節(jié)以飛行顯示器軟件中的“航向讀數(shù)”功能點為例進行說明。這些部分還可以組合成其他形式，本文不再贅述。

3.3.1 標題

標題部分應該為本軟件需求單元提供一個在整個軟件需求說明書中唯一的標識符，它應該是有特定含義的，能夠代表本軟件需求單元的。此外，它還可以加上表示特定級別和順序的編號。“航向讀數(shù)”的例子是：“8.1.1.1航向讀數(shù)”。

3.3.2 概述

概述部分應該對本軟件需求單元執(zhí)行的異常和正常處理活動提供一個概要描述。本部分的內容是為了給使用者提供一些背景知識，不是可驗證的需求。

“航向讀數(shù)”的例子是：當前飛機航向的數(shù)字讀數(shù)顯示在主顯示器（PFD）和多功能顯示器（MFD）的方框符號內，參見圖8.1.1.1－1。

3.3.3 激勵

激勵部分包括所有能夠觸發(fā)本軟件需求單元的激勵，由多個激勵組名聲明構成的列表組成?！昂较蜃x數(shù)”的例子如下。例子中有“航向顯示條件”和“航向顯示數(shù)值”兩個激勵組，其格式是：消息源 ＜消息＞。

（1）當從下列源頭接收一個［航向顯示條件］時，飛行顯示系統(tǒng)會執(zhí)行轉換過程：

AHS總線313號字段 ＜航行指示器標線顯示＞；

（2）當從下列源頭接收一個［航向顯示數(shù)值］時，飛行顯示系統(tǒng)會執(zhí)行轉換過程：

AHS總線314號字段 ＜飛機航向數(shù)值＞；

3.3.4 響應

響應部分包括所有本軟件需求單元產生的響應，由多個響應組名聲明構成的列表組成?！昂较蜃x數(shù)”的例子如下。例子中有“航向顯示”一個響應組，其格式是：目的地 ＜消息＞。

經過執(zhí)行轉換過程，飛行顯示系統(tǒng)會發(fā)送一個［航向顯示］到下列目的地：

PFD＜飛機航向數(shù)值＞；

MFD＜飛機航向數(shù)值＞；

3.3.5 轉換過程

轉換過程部分描述如何把一個激勵轉換成一個或多個響應，由一條或多條需求語句組成?！昂较蜃x數(shù)”的例子如下。例子中有一條需求語句。

當接收一個［航向顯示條件］和一個［航向顯示數(shù)值］時，飛行顯示系統(tǒng)會發(fā)送一個［航向顯示］；

3.3.6 聲明

聲明部分包括本軟件需求單元涉及到的所有數(shù)據(jù)的聲明，包括：類型名、子類型名、數(shù)據(jù)間的靜態(tài)關聯(lián)、常量、系統(tǒng)參數(shù)變量、系統(tǒng)狀態(tài)變量、激勵響應變量、本地聲明本地使用的函數(shù)、本地聲明外地使用的函數(shù)、外地聲明本地使用的函數(shù)等。

“航向讀數(shù)”的例子如下。例子中聲明了一個變量，其格式是：變量名：類型名（激勵組名）。

激勵響應變量：飛機航向：＜航向顯示數(shù)值＞；

3.3.7 性能

性能部分描述本軟件需求單元的性能需求，包括時間、空間、顏色、范圍和精度等內容，應根據(jù)具體項目來確定。

“航向讀數(shù)”的例子是：航向讀數(shù)是綠色的，不閃爍，占用3個字符的位置，顯示范圍從001到360，顯示精度是1°。

4 結束語

從上面的討論可以看出，通過采用結構化激勵響應（SSR）方法的激勵和響應分組、使用受限的自然語言和黑盒風格分析需求等途徑，執(zhí)行分解系統(tǒng)需求、激勵和響應分組、確定軟件功能域、確定軟件數(shù)據(jù)域、編寫需求規(guī)格說明和評審軟件需求等6個步驟，就可以開發(fā)出具有7個組成部分的軟件需求。這個需求具有可維護性好、內容一致、不含不可測試信息、高層次需求多、便于隨后軟件開發(fā)和軟件測試等特點?？傊?，SSR方法適用于規(guī)模大、數(shù)據(jù)關聯(lián)復雜、安全級別要求高的機載軟件的需求開發(fā)活動，是一種滿足DO－178B要求的軟件需求開發(fā)方法。

［1］CHEN Xin.Comparison and analysis research between DO－178Band GJB2786A［J］.Engine Control，2010，16（4）37－41（in Chinese）.［陳鑫.DO－178B與GJB2786A比較分析研究［J］.動力控制，2010，16（4）37－41.］

［2］RTCA/DO－178B，1992，Software consideration in airborne systems and equipment certification［S］.

［3］GJB2786A－2009，軍用軟件開發(fā)通用要求［S］.General Requirements for Military Software Development.

［4］GJB141－2004軍用軟件測試指南［S］.Military Software Testing Guide.

［5］GJB438B－2009軍用軟件開發(fā)文檔通用要求［S］.General Requirements for Military Software Development Documentation.

［6］GB/T9385－2008計算機軟件需求規(guī)格說明規(guī)范［S］.Norm of Computer Software Requirements Specification.

［7］CHEN Xin.Airborne software verification research for airworthiness requirements［J］.Engine Control，2010，16（4）：23－27（in Chinese）.［陳鑫.符合適航要求的機載軟件驗證研究［J］.動力控制，2010，16（4）：23－27.］

［8］MU Ming.Research on airworthiness dominated avionics software engineering［J］.Engine Control，2010，16（4）：42－45（in Chinese）.［牟明.適航在軟件工程化推進中的應用研究［J］.動力控制，2010，16（4）：42－45.］

［9］ZHANG Tao.Symbol test command language in embedded software simulation test bed［M］.Xi’anNorthwestern Polytechnical University，2005（in Chinese）.［張濤.嵌入式軟件模擬測試平臺中符號測試命令語言［D］.西安：西北工業(yè)大學，2005.］

［10］KENDRA M L COOPER.Training material for the stimulus response requirement specification notation［R］.The University of British Columbia，1999.

［11］LI Long.Practical technology and commonly used template of software testing［M］.Beijing：China Machine Press，2010：203（in Chinese）.［李龍.軟件測試實用技術與常用模板［M］.北京：機械工業(yè)出版社，2010：203.］

［12］YANG Ruo－song.How to acquire and analyze non－functional requirements［EB/OL ］.http：//www.csairk.com/rjsp/201101170857541969.htm（in Chinese）.［楊若松.如何獲取和分析非功能性需求［EB/OL］.http：//www.csairk.com/rjsp/201101170857541969.htm.］

［13］ZHAO Xi－chao.Requirement analysis of software engineering［EB/OL］.http：//www.yesky.com/114/205614.shtml（in Chinese） .［趙 熙朝.軟件工程之需求分析［EB/OL］.http：//www.yesky.com/114/205614.shtml.］

［14］REN Jia－lin.Method of software requirements review［EB/OL ］.http：//www.jdzj.com/gongcheng/article/2006－8－3/3265－1.htm（in Chinese）.［任甲林.軟 件 需 求評審 之 道［EB/OL］.http：//www.jdzj.com/gongcheng/article/2006－8－3/3265－1.htm.］

［15］KENDRA M L COOPER.Stimulus response requirements specification notation：An empirically evaluated requirements specification notation［D］.The University of British Columbia，2001.