第一節 軍事需求分析的主要內容

IEEE軟件工程詞匯表（1997年）為“需求”作了如下定義：1）用戶解決問題或達到系統目標所需要的條件；2）為滿足一個協約、標準、規格或其他正式制定的文檔、系統或系統構件所需要滿足和具有的條件或能力；3）對上述條件或能力的文檔化描述。^[1]而軍事信息系統的需求一般可以分為三個層次——作戰需求、用戶需求和系統需求。本質上，這種層次劃分是從作戰應用、系統用戶以及系統開發者三個角度來闡述軍事需求。從作戰應用角度來說，軍事需求是“為完成或支持作戰功能所需要的任務、作戰要素和信息流的描述”，它強調作戰要素、任務、使命和活動，是一個高層次的研發目標。從系統用戶角度來說，軍事需求強調需要系統協助用戶干什么事，它反映了用戶特性以及系統支持用戶完成任務而需要進行的軍事活動。從系統開發者角度來說，軍事需求定義了系統必須實現的系統功能，包括系統功能需求、性能需求、約束條件和其他非功能需求，是在開發過程中對系統的約束。

兵棋系統通常不會直接進入作戰指揮控制的鏈路，更多的是訓練或檢驗作用，因此，需要結合軍事指揮信息系統需求分析的三個層次進行有針對性的探討。同時，根據實踐經驗來看，在作戰需求、用戶需求和系統需求這三個層次之上，還需要加入一項更為全局和綜合性的內容，以便參與兵棋系統研發的軍事人員和技術人員可以更全面地把握其需求。因此，兵棋系統的軍事需求分析可以分為確定兵棋研發目標、分析研究作戰問題、構建用戶運用場景和明確兵棋系統功能等四部分內容。

一、確定兵棋研發目標

顯而易見，無論是手工兵棋還是計算機兵棋，抑或不同層級的兵棋，確立研發目標是兵棋設計的第一步，也是最重要的一步，研發目標定位是否準確，描述是否清晰，直接決定兵棋總體設計，甚至最終研發能否取得成功，以及設計與研發過程的順利程度。但是這一步驟的有效落實，實際上往往非常困難。

影響兵棋項目研發目標定位的因素是多方面的，軍隊單位研發專業兵棋，主要的影響因素包括上級任務要求、研發隊伍能力、可用資源支持等方面，其中上級任務要求是核心，研發隊伍能力是關鍵，研發資源支持是重要條件。一個適當的研發目標是這些影響因素綜合作用的結果，如果上級任務要求的條件不具備或不充分，則項目往往難以成功，因此，研發目標通常是任務和條件的平衡。不論是哪種性質的兵棋，確定其研發目標時均應綜合考慮這些因素。

一是上級任務要求。這是軍隊單位與地方公司研發兵棋的最大區別所在。地方公司研發兵棋是一種商業行為，利潤是他們優先考慮的因素，雖然對于某些實力雄厚的公司來說，可以承受短期的純投入，但如果在可預見的時間內，看不到盈利的希望，通常不會再作無謂的投資。而軍隊單位研發兵棋，通常的表現形式是上級下達任務，是作為一項上級任務來完成的。上級任務的制約主要包括兩個方面，任務的定位和時間。兵棋研發的總體目標或中長期目標，往往會受到軍事斗爭形勢變化的影響，隨著軍事斗爭軍隊任務的轉變，做出相應的調整。而對于一款具體兵棋的研發任務，首先需要關注的是上級的基本定位，這是上級意圖的直接體現，也是確定研發目標的基本遵循。同時，軍事任務通常有很強的時效性，時效性是軍事任務的重要因素，有時甚至會成為影響兵棋研發目標的首要因素。為了符合時效性的要求，必要時可能需要降低兵棋某些方面的要求，譬如減少一部分不甚重要的功能，或者是降低不太關鍵的性能指標。當然，也可能將任務要求進行分解，區分緩急，按照“急用先建”的基本思路，劃分多個相對獨立的階段來完成最終的研發目標。

二是研發隊伍能力。兵棋研發所涉及的專業領域繁多，技術難度大，對兵棋研發人員的能力素質提出了很高的要求。一支能力素質全面的兵棋研發隊伍是兵棋研發成功的關鍵因素，中等規模以上和具有一定復雜程度的兵棋研發隊伍中通常應包括以下四類專業人才：項目管理人員、軍事專家、軟件技術專家、技指合一人才。每一類別的人員多少取決于項目的規模和復雜程度，項目規模越大越復雜，則每一類別需要的人員越多，而人員達到一定規模后，還需進一步區分層次或專業。需要注意的是，這里所說的研發隊伍是指參與兵棋項目研發的所有人員的集合，并不只是軟件研發人員。通常，兵棋研發的任務受領方不管是軍隊科研院所，還是軍事院校，或者是作戰部隊，都難以保證自身具備所需要的四類人才。因此，通常需要聯合組建課題組，由其中某個單位擔負總體職責，再從多個相關單位引入人才。中等規模以上和具有一定復雜程度的兵棋研發項目，課題組的人才優先順序為項目管理人員、技指合一人才、軍事專家、技術專家，總體單位自身擁有的人才越是順序靠前，則兵棋研發通常就會越順利。不過，無論是直接進入課題組的軍事專家，還是臨時外請的軍事專家，在兵棋研發的整體性、全局性、關鍵性問題上應該始終處于主導地位。

三是研發資源支持。兵棋研發是創新性很強的復雜系統工程，需要整合各種資源形成合力，其中，除了必要的保密場地、設施設備之外，最為關鍵的還是經費支持。首先，在確定兵棋研發目標時，必須考慮能夠得到的經費支持，綜合考慮預定的經費支持力度和上級任務要求、研發隊伍能力，確定兵棋的范圍、復雜程度、功能完備性、性能要求、界面設計要求等。固然，在軍隊體系中，上級的任務要求通常有條件要完成，沒有條件也要創造條件去完成。但是，兵棋研發作為復雜的創新活動，有其自身的規律和要求，不是簡單的多加班、多花力氣就能干出來的。當然，財力只是一個重要的外部保障條件，而不是決定性條件，它對研發目標的影響從屬于前兩個因素。需要注意的是，兵棋系統的需求在研發過程中會面臨不斷的變更，而需求變更則意味著要增加額外的工作量，額外的工作量就意味著需要增加資源的消耗。斯坦迪什咨詢公司的研究表明：IT項目的實際成本是原始估算的189%。所以，在盡可能明確兵棋系統目標的基礎上，兵棋項目的研發預算一定要留有余地，以便應付各種各樣的變化。

有了目標定位后，還需要準確、清晰地描述出來，如果在研發初始對此重視不夠，到兵棋進入試用階段時，就會發現研發出來的兵棋只能用于某種特定的情況，即只是達到了用戶的部分要求，而沒有完全實現用戶的期望。原因固然是多方面的，但往往最基本的原因之一就是最初的研發目標描述得不夠準確、不夠清晰。對研發目標的準確描述，可以結合具體的需求一起表述，也可以單獨表述，但不管是以何種方式進行描述，某些關鍵性的問題或要求必須以準確的語言表達出來，使用戶和所有參與研發的人員對此都沒有疑義。例如，某款兵棋的目標定位是“滿足想定訓練”，這個目標描述就不夠清晰和準確。滿足哪個層次的想定訓練，是戰役級的，還是戰術級的，還是戰役戰術通用？是院校用，還是部隊用，還是兩者都能用？是完全以同一身份并行作業，還是分組輪流作業？很顯然，不同的選擇會導致不同的兵棋需求。如果這些問題不搞清楚，則后續的兵棋研發，每個人都會按照他自己的想法去理解目標的含義，看似認識一致，實際上卻相差甚遠，從而導致研發過程協調任務量大大增加，更嚴重的是，最后研發成功的兵棋不能滿足需要。

在兵棋的設計過程中，確立總體研發目標的最初過程需要各方面的密切合作：軍事需求方、兵棋研發方、兵棋受訓方（也就是最終的推演者）。一款兵棋的研發，所要做的不僅僅是確立兵棋研發的目標，還要制訂一系列的途徑（或者說是方法）來使兵棋滿足這些預定目標。最初的研發目標往往只是意向性的，比較概略。這種情況下，兵棋研發方就需要幫助軍事需求方（或者是兵棋的“立項決策者”）來分析、明確、分解兵棋的設計目標；而且兵棋研發方往往在行政上也隸屬于軍事需求方。這種情況下，兵棋研發方在某種程度上，需要協助兵棋軍事需求方來確定具體的研發目標。在這一過程中，兵棋研發方，需要圍繞著軍事需求方的概略目標，具體確立兵棋推演需要得到哪些結果以及能夠得到哪些結果。當然，確定兵棋的研發目標，也不是一步到位的，往往需要結合后面幾方面的分析反復進行調整。但是最終只有兵棋的軍事需求方、研發方，以及推演者代表，在兵棋的研發目標以及如何實現預定目標的方法途徑上達成一致，兵棋才能夠成功“立項”，并獲得相應的經費支持，兵棋研發才能真正地展開。

二、分析研究作戰問題

作戰需求通常包括軍事信息系統的作戰任務和使命，以及完成這些作戰任務所需進行的作戰活動和具有的功能。軍事信息系統的作戰需求主要可以通過使命任務分解、作戰樣式分析以及指揮體制分析等形式進行描述。對于兵棋系統而言，雖然與作戰的耦合不如指揮信息系統那么緊密，但研發目的仍然是作戰使用，每一款兵棋都必然與一定的作戰問題相關。在兵棋總體研發目標的分析確定中，通常已經基本界定了所針對的作戰問題以及兵棋的訓練（檢驗）目的，但僅僅是概括性的總體描述，包括作戰樣式、作戰類型、指揮級別以及訓練（檢驗）的層級、對象等。除此之外，還需要對兵棋所涉及的作戰問題進行全面分析，通常包括以下幾個方面：

一是作戰目的。作戰目的是作戰問題分析的基礎，主要用來約束兵棋推演的終點條件，也可叫勝利條件，即兵棋推演到什么程度可以結束。同時，它還影響兵棋的數據規模、評估指標、講評依據等方面。由于兵棋是雙方或多方的博弈，因此，對立的雙方或多方的作戰目的是對立的。通常需要先分析紅方的作戰目的，再依次分析藍方及其他方的作戰目的，最終綜合形成多方勝利條件集合。比如說，一款登陸作戰兵棋，其作戰目的可以是“搶灘成功”、“建立登陸場”、“完成登陸作戰”等，不同的作戰目的顯然在兵棋的規模、復雜程度、數據、評估等諸多方面有明顯的差異。作戰目的越小，則涉及的地幅小，需要的兵力少，涉及的行動少，推演的時間短，因此，兵棋的規模也小，復雜程度降低，講評和評估也會相應簡單。反之亦然。

二是作戰編成。作戰編成是兵棋推演雙方可使用的作戰力量的集合，主要用來確定兵棋要設計的雙方棋子的數量、種類，以及雙方的指揮層級。需要注意的是，作戰編成的分解通常需要逐級進行，最終分解到兵棋設計的最基本要素——最小分辨率作戰單位。隨著兵棋系統總體設計的深入，其作戰單位最小分辨率可能會進行調整，至少是部分調整，此時需要重新根據作戰單位最小分辨率來分解作戰編成。同時，不同的訓練課題、不同的訓練階段可能會根據需要對作戰編成提出不同的要求，比如在聯合登陸作戰訓練兵棋中，為增加“搶灘登陸”這個訓練問題的難度，推演組織者要求提供的航空兵火力支援力量少于典型條件，這時候通常不應該采用縮小空中作戰編成的方式，而是通過限制推演者對航空兵的使用來實現。通俗的說，在兵棋分析和設計之初，必須要按照雙方在推演中可能需要使用的最大作戰編成來進行分析，為兵棋提供最大程度的適用性。

三是作戰階段。對抗雙（多）方作戰階段的典型劃分，對于總體理解作戰行動，確定重點推演的階段和行動具有重要意義。回合制推演的兵棋中，作戰階段的劃分對于具體確定兵棋推演的回合長度也具有決定性意義。通常，一款兵棋只有一種回合長度，但如果涉及的作戰階段有若干個，不同的作戰階段作戰行動的時間跨度相差很大，而且每個階段的重要程度不一樣時，可能需要設定多種回合長度。同樣，以聯合登陸作戰兵棋為例，其涉及的作戰階段可能區分為裝載上船、海上航渡、搶灘上陸、建立和鞏固登陸場、島上作戰等，其中，裝載上船、海上航渡階段，行動類型相對簡單，而且時間跨度較大，而搶灘上陸、建立鞏固登陸場和島上作戰等階段，所涉及的行動種類多、時間短、關系復雜，因此，可以把各個作戰階段的回合長度進行不同的區分，這樣既可以突出作戰重點，又可以保證內容的完整。當然，這還要和訓練的要求結合起來考慮。

四是作戰行動。作戰行動分析是作戰問題分析的核心，既用于確定兵棋的規則條目、詳略程度等，又影響到各種推演指令的輸入參數及交互方式，并會影響態勢顯示的信息內容及重點。以兵棋規則為例，作戰行動的分析包括兩層含義：一是作戰行動的完整性。整個作戰問題中包含了哪些作戰行動，而且這些作戰行動都要分解到以最小分辨率單位來執行的程度，兵棋規則要包含所有的作戰類型。要描述什么樣的作戰行動，就需要有什么樣的規則來支撐。二是作戰行動的重要性。這個重要性不是指作戰行動本身的重要性，而是作戰行動相對于訓練（檢驗）問題的重要性。比如說，在現代戰爭的聯合登陸作戰兵棋中，奪取“三權”無疑是至關重要的，但如果兵棋訓練的重點是海上破障和搶灘登陸，那么奪取“三權”的行動雖然不可缺少，但可以簡略描述之。由于訓練目的不同，有些作戰行動只需作簡要的描述即可，有些作戰行動需要進行盡可能詳細的描述，在制定兵棋規則時，要根據需要來具體確定規則的詳略程度。推演指令的輸入參數及交互方式，態勢顯示的信息內容及重點，也同樣需要根據作戰行動分析的完整性和重要性來進行設計。作戰行動的分析，還對該兵棋推進的時間分辨率——步長起到決定性影響，步長通常是根據所有作戰行動中消耗的最短時間來確定。

另外，在作戰問題分析中，可能會涉及兵棋通用性的問題。在目前的技術條件下，全通用型的兵棋是難以實現的。而且需要注意處理好通用性與專業性的矛盾，通用性越好的兵棋，專業性通常會越差。如果是某一作戰層級的聯合作戰兵棋，可以參照我軍“聯合作戰基本理論”中明確的作戰樣式、作戰行動逐層進行分析，先針對最典型的作戰樣式，分析典型的作戰階段及可能的作戰行動；再針對其他作戰樣式，分析典型的作戰階段及可能的作戰行動；最終，綜合歸并形成總的作戰行動分析，同一種作戰行動需要包含不同作戰樣式、不同作戰環境下所有的影響參數。

三、構建用戶運用場景

用戶需求是指在作戰需求指導下，用戶使用系統必須要完成的軍事任務或活動，包括信息需求、運行或操作需求和其他要求、約束等。兵棋的軍事需求分析中，可以參照用戶需求分析的基本思路，來構建用戶運用的場景。根據對兵棋系統運用流程的分析，對兵棋推演流程中的主要任務進行概要描述，并通過記錄和整理形成結構化、形象化的場景描述。通過構建用戶運用場景，既便于以兵棋推演為主線，系統梳理、整合軍事人員腦海中比較零散的想法，總體形成直觀的畫面感；也便于軍事人員與技術人員以形象化的場景描述作為媒介進行溝通，初始形成共同的語境。通常可按照總體運用場景和幾個關鍵場景來分析構建。

一是總體運用場景。根據具體的推演方式，總體運用場景可分為集團式推演場景和編組式推演場景。而根據具體的推進方式，總體運用場景又可分為實時制推演場景和回合制推演場景。當前設計的兵棋系統，通常需要既支持集團式推演，也支持編組式推演。回合制推演，相對于實時制推演，其組織實施更為復雜。

集團式推演運用場景如圖3.1所示，即各對抗方只有一個推演員或一個推演組，某一對抗方的各類角色，如各個軍兵種、各個級別的指揮職能均由同一個推演組承擔，推演組通過協同研討的方式形成決策，并通過操作終端錄入。想定作業通常適合于采用這種推演方式。

編組式推演運用場景如圖3.2所示，即可以按照作戰指揮層級及崗位將推演人員進行統一編組。各個推演人員根據不同的席位指派負責本方不同的推演單位，共同完成全部的推演對抗任務。戰役戰術演習訓練通常采用這種推演方式。

而對于回合制推進的兵棋而言，還需要進一步在總體運用場景中體現其推演的控制過程。回合制編組推演的場景模擬如圖3.3所示。

圖3.1 集團式推演運用場景示意

圖3.2 編組式推演運用場景示意

圖3.3 回合制編組推演運用場景示意

二是推演準備場景。在兵棋推演總體場景下，需要對推演準備工作進行細化和梳理，形成推演準備場景，如圖3.4所示。

圖3.4 兵棋推演準備場景示意

不同的兵棋系統，其應用目的不同、運用對象、推演層級不同，系統推演準備的工作自然也可能存在差異。但是，兵棋系統推演準備的內容歸根到底是錄入各種數據，建立保存想定，并完成推演的初始化工作。數據主要包括地圖數據、棋子模板數據、作戰編成數據、規則數據和用戶數據等，其中棋子（注記）模板數據是某種作戰單位或地物類型在兵棋中的抽象，可以為想定作戰編成的編輯提供模板。在此基礎上，通常需要完成想定情況設置、推演席位設置、初始態勢設置等初始化工作。

三是推演實施場景。在兵棋推演總體場景下，基于推演準備工作，對推演實施進行細化分析，即可形成推演實施場景，如圖3.5所示。

圖3.5 回合制推演實施場景示意

回合制推演的實施過程，除了需要像實時制推演一樣進行導調控制之外，還需要逐個回合進行推進。推演的基本流程是在對抗各方分析態勢、定下決心、輸入指令并提交的基礎上，對當前回合的行動進行裁決，視情進行導調干預后推進到下一回合推進，完成態勢同步，再次進入下一回合的循環。在每一次回合推進時，系統需要將當前的裁決結果和動態干預后的信息同步到數據庫中并同步發送給雙方受訓者。

四是推演總結場景。組織實施兵棋推演，通常都會有一定的具體目的，因此，在推演后需要進行總結。在總結中，除了態勢回放之外，有時候還需要進行復盤推演。由此可以形成推演總結場景，如圖3.6所示。

圖3.6 推演總結場景示意

需要特別注意的是，無論是方案評估檢驗，還是演習訓練或想定訓練的兵棋推演，總結階段都是必不可少的，最終收獲的成果大多都是在推演總結階段才涌現出來。只重視兵棋推演過程，忽視推演總結工作，那就是典型的“買櫝還珠”。但是，在推演總結階段，兵棋系統的功能并非是向各參演方提供現成的分析結論，而是提供有價值的工具手段和信息數據，各參演方在此基礎之上進行定性分析，再得出結論；即使隨著人工智能的發展，未來的兵棋系統直接為各參演方提供的分析結論也僅能作為參考。

四、明確兵棋系統需求

系統需求通常定義了軍事信息系統為完成相應作戰活動所必須實現的功能，使得用戶在其支持下，能完成作戰需求所賦予的軍事活動和任務。系統需求的具體內容，除功能需求之外，通常還包括性能需求、約束條件和其他非功能需求等。而兵棋的系統需求，主要是在總體研發目標和作戰問題分析的基礎上，結合所構建的運用場景，進一步較為全面地分析兵棋的主要功能、性能要求、基本結構、交互方式、應用需求等。必要時，還需要針對系統數據接口、通信環境、配套設施要求等進行分析描述。

一是功能分解。兵棋的主要功能是兵棋最重要的需求。根據前面所確立的兵棋研發目標，先確定總體功能，即兵棋是為解決什么問題而建立。依據總體功能再進行細分，直到用戶和開發隊伍對功能的描述不再有疑義為止。通常可以按照推演流程，區分為推演準備、推演實施、推演總結等幾個階段進一步細分，也可以按照推演參與人員的職責，區分為推演準備人員、推演組織（導調）人員、推演參訓（運用）人員等幾種角色進行功能細分。在明確功能需求時，通常需要最終用戶、富有經驗的軍事人員、老練的軍事分析家、訓練的組織者和技術總體的負責人共同合作，確保對功能的描述為各方所認可，且認識一致。這往往難以一蹴而就，需要多次反復，而且需求分析的負責人應具有良好的溝通和協調能力，才能很好地綜合各方面的想法，最終形成具有約束力的功能需求。這也是后面建立兵棋系統功能架構的重要基礎。

二是性能指標。與功能需求緊密相關的是兵棋的性能指標需求，大部分的功能如果沒有一定的性能要求，就會變得如“雞肋”一般。性能指標的確定，通常由用戶或組訓者與技術總體負責人進行磋商確定。單一性能指標的確定，并不是很困難的事情，但總的性能指標往往受到時間、精力、財力等條件的制約，需要根據這些條件對性能指標進行一定的取舍和權衡，犧牲一些性能上的要求，以獲得最佳的效費比，或者滿足一定的時間限制。這個問題需要兵棋研發的各參與方共同面對，也是最不易獲得共識的方面。因此，技術總體負責人要對相關技術有較深入的了解，能夠對各種技術的應用代價做出有說服力的評估，以便用戶在提高費用以獲得高性能，或者降低某些性能以降低費用之間做出合理的選擇。對于軍事訓練或方案檢驗類的兵棋，要高度重視其穩定性和安全性，根據具體的運用條件來考慮各項性能指標，這也是后面建立兵棋系統技術架構的重要基礎。

三是基本結構。對于一個現實的系統來說，系統的結構決定了系統的功能；反過來，設計一個系統，則是功能決定結構。同樣，在兵棋設計中，必須從兵棋的功能出發，設計滿足功能、性能需要的基本結構。如果功能不能滿足需要，性能無法達到基本要求，那么，即使結構再精巧、技術再先進、界面再華美，它仍然不是一個好的系統，甚至是無用的系統。在已經完成功能分解的基礎上，有關兵棋的基本架構重點需要明確三個方面的問題：一是兵棋典型的物理部署方式，它決定了兵棋外在的運用結構和特性，也是后面建立兵棋系統物理（部署）架構的重要基礎；二是兵棋典型的用戶角色區分，它決定了兵棋必須分解為哪些相對獨立的子系統（模塊），也是后面建立兵棋系統邏輯架構的重要基礎；三是兵棋典型的物理應用環境，它主要決定了兵棋的穩定性、靈敏性等性能指標，也是后面建立兵棋系統技術架構，尤其是通信架構的重要基礎。

四是交互方式。兵棋的交互方式對其可操作性、友好性具有關鍵性影響。由于用戶（包括組訓、受訓者等）通常不可能對兵棋系統的內在機理和技術實現都有充分的了解，交互界面是用戶了解和使用兵棋的主要媒介，所以界面對于一款兵棋的設計來說，處于十分重要的位置。如果將兵棋功能實現視為兵棋研發是否達標的標志，那么兵棋交互界面則決定著這款兵棋的生命力。但這一點又很容易被用戶和研發者所忽視。用戶忽視界面，是因為用戶的注意力更多地集中于兵棋的功能和性能。而研發者有意無意地忽略界面，既有能力和水平方面的問題，也有研發條件制約的問題。軟件行業有一句名言：“用100行代碼的代價換取用戶少點擊一次鼠標，是值得的。”這句話，既道出了交互友好的重要性，也說明了交互的改進所消耗的資源通常是巨大的。最終，在交互這個問題上，需要兵棋用戶和研發者形成一種平衡的共識。

五是應用需求。應用是兵棋研發的最終目標，因此，應用需求是兵棋系統所有需求的歸結點。大部分的應用需求分別體現在前面所述的需求方面，例如，“能夠根據想定需要迅速調換地圖”，這是一個功能需求，也是一個應用需求；又如，“兵棋要能夠展開不低于100個推演終端，同時容納不少于15個對抗組并行進行推演”，這是一個性能需求，也是一個應用需求；與組訓方式緊密聯系的兵棋部署架構、與用戶使用兵棋緊密相關的輸入輸出更是應用需求。因此，兵棋的軍事需求本質上是一種應用需求，其他任何形式的需求都是為應用服務的。兵棋的應用需求描述，可能會和功能需求、性能需求等有關內容產生重復，目前還沒有一種成熟的理論或規范來進行區分和描述，因此，確定兵棋的應用需求是一個反復征求意見、反復修改的過程。