軍事信息系統的體系需求論證方法分析 *

高 斌 ，賀 慶

(中國電子科學研究院，北京100041)

0 引 言

隨著軍事信息系統的不斷發展，系統之間的連接越來越復雜，交互越來越頻繁和緊密，以往強調單系統、單平臺的發展模式已經難以滿足成體系、快速發展的需要。軍事信息系統發展也逐步從強調功能的系統工程轉變為強調能力的體系工程[1-2]。

經過多年對體系工程的研究[3-6]，體系工程概念已基本達成共識。體系工程是通過設計、開發和集成復雜大系統來完成特定任務，實現能力、使命或期望結果的理論方法和技術。從體系的研制構建過程來看，體系工程包括體系需求論證、架構設計、標準研制、綜合集成和評估分析等過程。本文重點針對體系需求論證開展研究。

體系需求論證是指運用有效的方法與技術開發任務需求，確定體系建設能力目標，并用規范化文檔形式進行描述、定義目標體系的所有外部特征的一項復雜的過程。與系統需求的相對確定性不同，體系需求論證是不斷變化的，要根據外部環境變化和內部系統演化而持續迭代。

軍事領域的體系需求論證，面向軍事人員和戰場，具有復雜性、易變性、對抗性等特征。美軍經歷從“基于威脅”向“基于能力”的轉變，強調對己方軍事作戰能力的建設，以對抗不確定的未知威脅[7]；英軍強調“精明需求”，重點關注對體系全壽命周期的需要，而不只是最初的采購需求[8]。

當前，開展需求論證工作依然面臨需求獲取難、描述不統一、驗證手段缺乏等問題[9]。針對該問題，本文開展了體系需求論證理念、方法、論證過程等方面的研究，以實現從體系用戶的任務需要到能力需求的轉換。

1 體系需求論證理念

理念是對思想、觀念的總結，是客觀事物的本質反應。體系需求論證的理念對軍隊建設、兵力運用、戰法設計等產生了深遠影響。軍事領域的體系需求論證理念主要有基于威脅、基于能力和基于效果等，在實踐中經常綜合多種理念開展需求論證。

1.1 基于威脅的需求分析

基于威脅的需求分析理念，以面臨的現實安全威脅為驅動力，從假想敵可能發起的軍事威脅為出發點，以打贏或阻止戰爭為目的，以一個或幾個想定為背景，通過全面或局部力量間的對比分析，規劃己方所需力量。該理念源于應對安全威脅的現實需要，有賴于安全威脅情況刺激，是情況刺激-反應模式，具有被動性、維持性等特點，適用于弱國面臨安全威脅大的強國，或者是處于冷戰狀態下的大國等情況，但該理念在面對不確定性較大的對手時有一定的局限性。

1.2 基于能力的需求分析

基于能力的需求分析理念[10]，著眼期望塑造的能力，從不確定的多元威脅出發，在一定的經濟條件約束下，對廣泛挑戰和多變環境所需要的軍事作戰能力進行分析，意在明確需要什么能力來對抗未知威脅，達到“以不變應多變”效果。該理念源于戰略目標的牽引，是為了達到某種戰略目標而謀求塑造能力的發展，是目標牽引-塑造模式，具有主動性、創新性等特點，適用于安全環境相對寬松的大國或者強國，尤其是崛起的大國，往往著眼于國家戰略目標，追求與之相適應的軍事發展戰略。

1.3 基于效果的需求分析

基于效果的需求分析理念[11-12]，以獲得期望的作戰結果或對敵人造成期望作戰效果為目標，通過協調、增效和累積等方式運用己方軍事力量，達成敵方系統失能。這種理念以作戰結果為導向，反向提出我方的作戰運用方式，具有前瞻性、結果性、對抗性等特點，適用于對抗性較為激烈的戰術行動中，在保障作戰任務完成的前提下，通過最優使用我方作戰力量，盡可能減少己方損失。

2 體系需求論證方法

體系需求論證包括需求獲取、需求描述與建模、需求驗證等階段，每一個階段都有相應的論證方法，通過綜合運用不同方法，獲取準確需求。

2.1 需求獲取方法

需求獲取是指通過各種途徑收集和征詢，得到建設新體系或者其他相關信息，以及任務清單和部分能力約束和要求的過程。隨著體系規模的擴大，需求獲取活動不再僅限于體系開發的初期階段，它貫穿于整個體系開發的生命過程，常用方法有用戶訪談法、問卷調查法和快速原型法等。

用戶訪談法是需求論證人員與用戶通過面對面交流與溝通的形式，進行事實發現和信息聚集，通常采取召開會議的形式進行座談或調研等。問卷調查法是指就用戶需求中的一些個性化的、待進一步明確的需求，通過發放問卷調查表的方式，達到徹底弄清楚項目需求的方法。采用本方法，可有效地獲得大量不同崗位和專業人員的需求。快速原型法即把體系主要功能和接口快速開發制作為“原始樣機”，以可視化的形勢展現給用戶，及時征求意見和建議，從而明確無誤地確定用戶需求。三種方法的優缺點及適用情況如表1所示，可根據實際情況綜合使用三種方法。

表1 需求獲取方法優缺點比較

2.2 需求描述與建模方法

需求描述與建模是通過規范化的方法和手段，建立體系需求模型，將已獲取的需求準確地表現出來，便于達成一致的理解，減少二義性，提供直觀、通用、標準的圖表信息。已有大量文獻[13-17]提出了多種需求描述與建模方法，滿足描述建模需要。本文通過歸納，將需求描述建模方法總結為結構化描述法和面向對象描述法等。

結構化描述方法采用自頂向下分層解決的方法進行分析、描述和構造模型，按照特定功能劃分為不同模塊，通過對每個不同的模塊進行描述，實現對體系的整體描述，一般應用IDEF圖進行描述。該方法具有較嚴密的邏輯性及較高的精確性，能有效地將一個較復雜體系逐層分解為更小的體系或系統，其描述方法直觀易懂，便于用戶交流。但缺點是由于被分解成的模塊體系結構依賴于上層的業務劃分，對業務需求變化具有高度的敏感性，需求變更與追蹤管理工作量很大。

面向對象描述方法繼承面向對象的編程思想，通過使用對象和類兩種描述方式，進而實現對用戶需求的描述。一般用UML對需求進行描述。該方法優點是以自然方式描述客觀世界，容易把握分析重點，系統功能和定義的操作實現簡便，采用集成的思想提高了資源的可重用率。但缺點是開發的冗余較多，開發效率不高，實例化的對象依據客觀邊界劃分，很難保證描述的準確性。

2.3 需求驗證方法

需求驗證用于確定論證成果在邏輯上是否一致，在性能和行為上是否可行，在效能上是否滿足用戶要求并達到最優，重點進行語法驗證、一致性驗證、邏輯合理性驗證、完備性驗證和規范性驗證，一般使用需求評審法和需求模型執行方法[18-19]。

需求評審法通過組織成立由用戶、研發人員、測試人員組成的評審小組，以會議的方式對成果進行仔細檢查，解決需求文檔中二義性，消除模糊性。該方法簡單易行，但難以處理大型、復雜的需求文檔，且由于審查過程涉及龐大的群體，花費時間長。

需求模型執行方法可分為形式化驗證和邏輯性驗證。形式化驗證能解決需求文檔中不一致和二義性；邏輯性驗證往往依賴于可執行驗證技術，將信息流、數據流等內容在用戶描述并建立起來的需求模型中進行模擬運行，再通過從用戶處得到的業務邏輯流程和規則來檢驗其模型的正確性。

3 體系需求論證組織過程

體系需求論證過程是一個反復不斷迭代的過程，涉及多方的利益相關者：既涉及最終運用體系完成其業務職能的使用方，也涉及對體系建設過程進行規劃監督的管理方，更有體系建設的研制方。因而，既要兼顧使用方對于體系的業務使用要求，又要兼顧技術發展所產生新的實現途徑需要，將業務需求和技術需求結合起來，共同驅動需求論證過程。需求論證過程包括明確利益相關者的業務期望需求和定義研制方的技術實現需求。

3.1 業務期望需求

明確利益相關者的業務期望需求是體系工程的初始工作，確認誰是利益相關者，以及準備如何使用體系滿足其業務職能需要。一般通過用例想定、設計參考使命任務和運用使用構想實現，主要流程包括確定利益相關者和明確利益相關者期望兩大步驟，其典型過程如圖1所示。

圖1 明確利益相關者業務期望需求流程

確定利益相關者的明確利益相關者：待建設的體系工程可能來自組織或上級領導指示的要求，利益相關者就是那些受到本項使命任務結果影響或某種程度上對結果負有責任的組織或個人。利益相關者可以分為使用者和其他關注團體。其中，使用者是那些直接接受體系的人，或是直接受益人；其他關注團體通過提出寬泛約束對項目施加影響，在這些約束下滿足使用者的需求，例如，裝備管理組、規劃顧問組、體系工程負責人等。

明確利益相關者的業務期望需求：需要明確利益相關者對指定項目的最終狀態或目標產品是什么，或為項目目標增加約束范圍來確定。這些約束范圍可能包括(資源)消耗、交付時間、性能目標，及其他非定量約束。經過使命任務授權、使命任務目標、運行使用目標、成功準則、設計動因等一系列步驟，明確體系的目標，表達體系最終用戶的需求，明確利益相關者期望、運行使用構想、輔助產品保障策略和效能指標等。

3.2 技術實現需求

定義研制方的技術實現需求是把利益相關者的期望轉換成對體系問題的定義，再轉換成經認定的技術需求，便于組織開展研制。以“需要”形式陳述的需求能夠用于定義體系分解結構模型和相關附屬體系的設計方案。需求定義對利益相關者需求、系統開發需求和底層產品/組件需求等三方面需求進行論證，逐漸形成層產品/組件需求文檔。通過初步評估利益相關者期望，以理解待解決的技術問題并建立設計邊界，流程如圖2所示。

圖2 技術需求定義流程

首先，確定設計方案必須遵從的約束條件或體系產品將使用的約束條件，辨識已經在設計控制下并且不能變更的那些單元，有助于縮小對潛在設計方案進行權衡分析的范圍。其次，建立體系內各系統交互必需的物理接口和功能接口。隨著對約束條件、物理/功能接口和功能/行為期望的全面理解，需求可通過建立性能標準做進一步定義。性能表述為需求的定量部分，用來表示每個產品被期望完成的功能。最后，需求應該被定義為可接受的“需求”闡述，每個闡述僅含一個“需要”的完整語句，最終形成技術需求和技術性能指標。

4 典型案例

為闡述上述所提出的方法和過程的有效性，選取外軍島嶼奪控作戰[20]為典型實例，從業務期望需求和技術實現需求等進行需求論證。

4.1 案例背景

島嶼奪控作戰是在聯合指揮所的統一指揮下，聯合作戰編隊對侵占和據守島嶼之敵實施的進攻奪取與有效控制的作戰。島嶼奪控作戰具有作戰進程銜接緊，保持控制權難度大和突擊上島限制多等特點，存在需求變化調整頻繁、需求描述不夠細致等問題，能夠較為充分地體現出體系建設過程中面臨的問題。

4.2 論證過程

聚焦外軍島嶼奪控作戰過程中對于信息系統的建設需要，開展體系需求論證，以期找準需求，并對其需求進行精準描述，牽引和規范后續研制建設，主要包括三個步驟。

(1)明確利益相關者

經過對外軍島嶼奪控作戰的前期資料收集后，項目組確定外軍在執行該項作戰任務過程中涉及的海區奪控、島嶼奪占和島嶼防御等階段。每個階段涉及的利益相關者也不盡相同。以海區奪控為例進行詳細說明。為明確利益相關者，項目組假定目標用戶，采用問卷調查法對目標用戶進行調研，以逐步明確該項作戰階段中涉及到的關鍵用戶，設計了用戶需求說明書和問卷調查表，如圖3所示。

一、被調研用戶基本信息被調研單位名稱被調研用戶姓名職位聯系電話郵編二、業務調研表業務部門名稱職能序號職能名稱12…職能序號1職能名稱業務描述業務事項名稱業務需要哪些數據相關業務標準規范業務關系檢查協同分類協同業務名稱業務協同關系描述涉及相關部門單位內跨部門協同業務跨單位協同業務三、業務發展方向表序號發展方向描述1(如:整體方向)2(如:工作重點如何加強)3(如:工作難點怎樣解決、改善)

經多輪迭代修改，項目組逐漸明確海區奪控階段中重點活動包括作戰海區預警偵察、海上態勢融合、威脅評估、作戰決策、兵力接敵機動、火力打擊和戰果評估等作戰活動，其主要涉及到的利益相關方包括聯合作戰指揮所、海軍特遣艦隊指揮所、水面艦艇突擊群指揮所、空中突擊群指揮所、掩護兵力群指揮所等，因此可以建立利益相關者列表，如表2所示。

表2 利益相關者列表

(2)明確利益相關者業務期望需求

采用資料收集法，確定利益相關方對于待開發信息系統的期望。經過對外軍島嶼奪控作戰的材料收集和整理，擬采用結構化的方法對其期望進行描述。利益相關者重點需要執行海區奪控、島嶼奪占和島嶼防御三個階段，每個階段在階段目標和兵力運用上有所不同，但對于情報信息獲取、實施指揮控制、作戰要素協同運用和作戰效果評估等四個方面有共性期望。由于篇幅有限，主要以作戰要素協同運用期望中的武器協同運用期望為例進行結構化描述，如圖4所示。

圖4 武器協同運用結構化描述示例圖

(3)定義研制方的技術實現需求

通過詳細分析，明確開發系統之間的功能以及功能接口關系。

面向島嶼奪控作戰對于軍事信息系統的構建需求，應具備信息傳輸網絡化、情報獲取多元化、指揮決策智能化、武器控制數字化等特征，能夠簡化指揮流程，縮短指揮周期,提高作戰指揮效能和整體作戰的能力。綜合考慮，提出信息融合處理、協同指揮決策、聯合行動控制、通信保障、安全保密等功能要求，并用結構化方法描述各類功能之間的接口關系。

經過分析設計，形成《島嶼奪控作戰需求規格說明》，并采用需求評審法，對設計成果的邏輯性和可行性進行檢驗。設計了評分標準，總分100分，如表3所示，并組織利益相關方、海上作戰專家、架構設計專家、開發專家和測試評估專家等開展需求檢驗,進一步提高論證成果可行性，降低后期風險。

表3 需求評審評分標準

5 結束語

本文針對大型軍事信息系統研制建設過程中存在的需求獲取難、描述不統一、驗證手段缺乏等問題，基于體系工程過程，研究了一般常用的需求論證的理論和方法，并從業務期望需求和技術實現需求兩個方面創新提出了需求論證的組織過程，便于需求論證工作落地實施。此外，以外軍島嶼奪控作戰為典型案例，闡述了所提出需求論證方法和過程的有效性，進一步驗證了上述方法和組織過程。下一步將針對需求論證過程中使用的常用工具展開研究，提高需求論證工作效率。