航空產品研制條目化需求管理應用發展探討

董亮，劉俊堂

航空工業第一飛機設計研究院，陜西 西安 710089

隨著航空產品創新研制能力的水平不斷提升，采用信息化手段對產品研制中需求演變過程進行精準管控已成為行業發展必須面臨和解決的技術問題之一，也是全面推進基于模型的系統工程（Model Based Systems Engineering ，MBSE）的關鍵技術之一[1]。而航空產品的復雜性、長周期性、傳統的仿制模式及長期文檔化需求管理模式的應用，造成了條目化需求管理的認識差異，如需求與需要的差別、需求在飛機產品MBSE研制過程的演變特點、需求管理從文檔化向條目化轉變的突破點選擇等，影響了條目化需求管理方法的深入應用和推廣。為此，本文對需求管理應用的發展歷程、需求演變過程、條目化需求管理的特點等方面進行了介紹，為實現條目化需求管理以及需求條目驅動產品設計分析、驗證和確認等研制活動提供技術支撐。

1 需求管理在航空領域的應用

20世紀80年代中期，美國參謀長聯席會議要求在軍方項目中引入需求管理，并聯合美國蘭德公司（RAND）對需求管理的架構體系進行了研究。國際上自1994年起每兩年舉辦一次需求工程國際會議（International Conference on Requirements Engineering，ICRE）， 在1996年Springer-Verlag發行了新的刊物——《Requirements Engineering》。一些關于需求工程的工作小組也相繼成立，如歐洲的需求工程網絡國際合作研究小組 （Requirements Engineering Network of International Cooperating Research Groups，RENOIR），并 已 開 始 開 展 工 作[2]。1998 年，在 IEEE Std830ü1998 中，推薦了有代表性的8種需求規格說明模板，這8種模板雖然在需求的組織方式各有側重，但在結構上有一個共性：需求均為樹狀的層次結構[3]。

20世紀90年代中期，需求管理在航空工業界開始應用起步，當時需求分析師在設計和驗證過程對設計需求設置唯一的編號，以實現對需求控制。

在美國聯合攻擊戰斗機（JSF）項目研制中，美國國防部（DoD）強制要求整個項目全部使用需求管理平臺，JSF F-35對需求管理的要求是：整個項目周期中管理和開發客戶的需求、在客戶需求和試驗之間建立動態的關聯、允許存儲詳細的試驗達標數據、對試驗狀態的準確監控、按照合約規定自動產生試驗報告。這保證了JSF F-35的研制要求既要充分滿足客戶定義的需求，又要通過試驗直接與需求項關聯以驗證試驗結果，證明產品與需求的符合性。

21世紀初，以波音公司、空中客車集團、洛克希德－馬丁公司、霍尼韋爾公司等為代表的國外飛機制選商以及系統供應商均應用需求管理軟件管控研發過程中的設計需求，以JSF、A400M、A350、波音787等軍用和民用飛機研制為代表。與此同時，與需求管理相關的標準也逐漸提出，以飛機安全性為核心的ARP 4754，以飛機軟硬件開發安全性為核心的DO-178、DO-254、DO-160等一系列標準是其中的典型代表。

國內航空行業于2010年之后逐步開展需求管理技術的研究與應用工作，采用需求管理技術以提升型號研制對客戶的滿意度。起步較早、應用規模較大的是中國商用飛機有限責任公司（中國商飛）。中國商飛以C919飛機研制為契機，成立了飛機需求管理“集成產品協同組”（IPT）團隊，搭建了需求管理平臺，實現了對飛機級、系統級、子系統級等需求數據的管理，覆蓋各設計專業、標準、適航、供應商、試驗等用戶。但整體來看，數字化環境下的需求管理尚未走完完整的飛機研制過程，其技術完整性及成熟性仍處于應用探索階段。航空工業需求管理的簡要發展歷程如圖1所示。

圖1 航空工業需求管理的發展歷程Fig.1The development of requirement management in aviation industry

2 從需要到需求的演變控制

2.1 需要—需求—要求

在產品研制過程中，圍繞“需求”的內涵，通常有需要、需求、要求等三個不同的概念，每種概念都是對產品的抽象定義，對應不同的認識階段。

需要是從利益相關方獲取的，對產品使用、監管、經濟性等各方面的描述，通常具有較強的隨意性、主觀性，反映了利益相關方對產品對象應用場景及各種特性的理解或期望，對應早期的論證階段。因此，需要所描述的內容通常是隨意性的、定性的、可實現性較差的，不能直接用于產品研發。

需求是由工程人員對需要進行一定的工程分析和轉換，并進一步與需要對應的利益相關方進行權衡分析與妥協平衡，所形成產品技術要求定義，通常對應方案設計階段。因此，相對于需要，需求的基本特性是可實現、可驗證的。在實際應用中，需要只有被轉換為需求之后，才能進一步往下傳遞并指導約束產品研制過程。因此，需求是面向解決方案的，但可能不是唯一的解決方案。

要求是經過方案權衡選擇之后，基于選定的設計方案，補充衍生需求之后，形成的需求集合，這相對需求更加具體、更加貼近工程實際。因此，要求本身就是需求，是面向特定解決方案的完備需求集合，是進行產品詳細設計和制造的直接依據。而需求向要求轉換的過程是設計的過程，也是需求細化分解的過程。因此，三者都是對產品的抽象描述，反映了隨認識水平提升對產品定義不斷明確細化的過程。而條目化需求管理應覆蓋包含需要—需求—要求為核心的各類形式的需求數據，如用戶調研報告、標準規范、研制總要求、飛機各級產品研制規范、接口定義文件、四性分析文件、測試規范、符合性驗證文件、成品協議書等。以條目為粒度對這些產品定義文檔進行結構化描述、精細化管理，是條目化需求管理的基本特征。

2.2 V模型中的需求管理

系統工程V模型是系統開發過程的圖形化表示，V是驗證和確認的統稱。左側代表需要沿飛機架構自上向下逐級傳遞的過程，右側描述了各種需求自下向上的逐級驗證，直至右側最頂端的、自左向右的產品最終確認。V模型最早于20世紀80年代由德國和美國科學家同時提出?，F行的是美國的V模型，其最早由系統工程國家委員會（NCOSE）（現為國際系統工程委員會（INCOSE））于1991年提出，并最先應用于衛星系統的研制，目前已廣泛應用各類工程研制項目。該模型的顯著特點是產品研制的成熟度隨時間自V模型左側向右側逐漸增加，所有的設計迭代是沿系統層級垂直向上或向下的。

而V模型中的需求管理（如圖2所示），首先在V模型左側，以需求細化傳遞的角度實現需要—需求演變過程的管理（圖 2中深色圓圈范圍），其次在V模型右側，要以需求驗證的角度實現需求—產品的驗證確認管理。

圖2 系統工程V模型中的需求管理Fig.2 Requirement management in system engineering V model

2.3 五個一致性控制

MBSE通過有效的需求演變控制，可把需求以“自頂向下”的方式體現在飛機研制過程中，并滿足“五個一致性”控制的要求：（1）需要（即用戶期望）與工程需求的一致：將用戶期望完整、正確、清晰地轉化為產品研制的頂層需求。（2）上下游需求分解分配的一致：將產品頂層需求按照產品“自頂向下”的方案分解過程推進，逐步分解到產品的各級組成，確保各級產品研制需求輸入的正確性、完整性及來源的合理性。（3）需求與設計方案的一致：將需求定義與功能架構設計、物理架構設計結果進行分配和關聯，并基于設計方案產生相應的衍生需求。（4）需求與工程實現結果的一致：隨著產品“自底向上”的實現過程，逐層按照需求要求進行測試驗證，確保工程研制結果與需求定義的一致性。（5）最終產品與需要的一致：產品最終交付結果與產品使用環境、用戶需要等一致性判定。

這5個過程依次為：需求（需要）確認、需求確認、設計驗證、產品驗證與產品確認，如圖3所示。

圖3 需求管理過程中的“五個一致性”Fig.3 Five kinds consistency in requirement management

通過“五個一致性”的控制，一方面避免研制需求不能對用戶期望完整覆蓋，而成為無效設計，另一方面，避免設計超標而帶來研制風險。

3 條目化需求管理

3.1 需求管理發展水平等級

根據需求管理的應用范圍及深度，將需求管理劃分為5個等級，如圖4所示。等級1：特例管理。對產品研制過程的關鍵過程的需求傳遞進行管理，并未覆蓋全部的研制環節。主要存在于仿制及仿制改進階段。等級2：集中管理。按照產品研制要求全面進行需求管理。這是文檔化需求管理的典型階段。等級3：分布式管理。對部分研制環節的需求傳遞過程按需求條目粒度進行管理，如軟件開發過程，但主體還是文檔化需求管理。這是一個條目化與文檔化混合的階段。等級4：以產品數據的方式管理。產品研制過程的全部需求均以需求條目為粒度進行定義和管理，這是需求條目化全面覆蓋的階段。等級5：擴展到整個企業級的管理。在需求條目化管理的基礎上，建立需求條目與產品研制數據的結構化關聯關系，條目化需求成為企業產品研制過程的各項活動開展的顯性驅動因素。

圖4 需求管理發展的5個等級Fig.4 Five levels of requirement management development

當前國內航空產品研制大多集中與等級2階段，而條目化需求管理對應等級4發展階段。條目化是相對文檔化而言的，其變化不僅需要定義描述粒度的變化，更重要的是建立以需求條目為核心的數據模型，該數據模型既要滿足對需求信息的全面描述，還要對需求與產品研制其他數據對象的關聯關系進行描述。

3.2 文檔化向條目化的轉變

隨著我國飛機研制能力的提升，研制模式正逐步實現“以仿制、改型研制為主”向“以創新、正向研制為主”的模式轉變，當前需求管理及需求驅動的飛機研制技術正在得到研究和應用，其中需求管理模式正逐步從“文檔化”向“條目化”轉變。條目化需求管理帶來的變革，不僅涉及需求數據對象的定義、需求數據的組織，還將對需求的變更和追溯過程產生變革，同時需求在整個產品研制過程的作用將更加突顯，二者的比較見表1。

從表1可看出，條目化需求管理相對于文檔化需求管理在需求數據管理精確程度、需求數據與產品數據集成及驅動、知識重用等方面有明顯優勢。

而采用條目化需求管理，也將降低對幾種常見問題的影響：設計內容與需求描述混合、用戶需要與系統需求混合、產品需求中出現方法和計劃、需求缺少明確的所有者、沒有明確的需求測試方法、客戶過于被動或過于強勢、結構不完整，需求重復或缺失、需求配置版本沒有管理、表述模糊歧義、承諾不合實際的需求集合等。

表1 文檔化需求管理與條目化需求管理比較Table 1The difference between documentation requirement management and itemized requirement management

3.3 條目化需求管理系統

條目化需求管理必須借助成熟的需求管理系統的應用才能實現。而在條目化需求管理工具方面，國外己出現了一批優秀的商業化需求管理工具軟件，其中具有代表性的是 Calibe-RM，IBM DOORS，Retional RequisitePro，Dassalt Catia Reqtify，Dassalt Enovia RMT等。在航空信息系統供應商中，IBM的DOORS、法國達索公司（Dassalt）的REQTIFY、PTC的INTEGRITY、Dassalt的ENOVIA RMT是幾種比較有代表性的需求管理系統產品，均相對成熟并具有豐富的市場應用案例。

（1）DOORS系統。IBM Rational DOORS前身是Telelogic DOORS，起源于1983年，2008年被IBM收購后更名為IBM Rational DOORS。DOORS是最老牌的企業需求管理套件，具有良好的市場占有率，特別適合在同一地理位置工作的組織和在同一地理位置處理的項目，它能夠增強業務目標、客戶需求、技術規格和規則的可見性，以此提高產品質量[4，5]。

（2）REQTIFY系統。REQTIFY軟件是達索公司針對基于文件開展需求管理，推出的高度可定制化、易用的需求管理工具，可進行需求跟蹤和沖突分析管理，尤其擅長需求管理信息統計、需求跟蹤、版本管理和定制報告等，并允許用戶將需求條目和原始文件（文本、Excel、PDF、UML、分析和模型、代碼等）進行直接關聯。REQTIFY的應用案例包括空客公司的A340與A380軟件研發和航電系統、泰雷茲（Thales）、歐洲導彈集團（MBDA）導彈軟件開發、ALCATEL Space衛星地面站等。REQTIFY被IBM DOORS 軟件OEM定為Gateway，輔助DOORS進行需求可視化追溯。

（3）INTEGRITY 系統。PTC INTEGRITY[6，7]的前身是加拿大MKS INTEGRITY，國際上有超過600個企業以及超過10萬用戶在使用，2011年6月被PTC公司收購，現作為PTC公司的一個重要的商業模塊。PTC INTEGRITY定位于應用生命周期管理（Application Lifecycle Management，ALM），主要管理軟件工程各階段文檔以及文檔間的關系、功能與文檔間的關系、測試及缺陷的處理，可完成從需求概念到需求消亡整個過程中的追溯。

（4）RMT系統。達索RMT系統是Dassalt Systemt整合Matrix One之后推出的產品，用于面向復雜機械產品3D研制的需求管理系統，稱為Enovia Requirements Central，支持從外部文件中捕獲并導入需求，并對需求追溯關系進行管理，對應其V6環境下推行“R-F-L-P”系統工程設計解決方案中的R。目前RMT的主要應用案例是貝爾直升機（Bell Helicopter）、比亞喬航空（Piaggio Aero）、龐巴迪（Bombardier）等，同時RMT與REQTIFY也具有無縫集成能力。此外，PLM供應商西門子（Siemens） Teamcenter系統也有相應的需求管理系統軟件，主要應用于汽車、航空發動機領域。對于航空產品需求管理系統的選型，通常要考慮系統軟件的功能特點、與現有數字化工具的集成性、對未來MBSE工具方案的支持能力及工具背后的方法與企業能力的匹配性等，因此最大可能的選型將是混合選型。

4 結論

在MBSE技術推廣應用中，準確理解需要ü需求ü要求的轉換關系及“五個一致性”的演變過程，理解條目化需求管理發展趨勢及其帶來的革新和挑戰，不僅是正確推進航空產品正向創新設計的認知基礎，更是選擇適合航空企業發展所需的需求管理模式的前提。同時有限的條目化需求管理工具的選型，也是航空企業建全數字化研發環境所必需面臨的選擇。本文對航空企業條目化需求管理建設發展中所遇到的一些認識問題進行了研究，為航空企業構建合適的需求管理模式提供了技術支撐。

[1] 國際系統工程協會. 系統工程手冊：系統生命周期流程和活動指南 [M]. 張新國，譯. 北京：機械工業出版社，2013.INCOSE. Systems engineering handbook： a guide for system life cycle processes and activities [M]. ZHANG Xinguo， translated.Beijing： China Machine Press， 2013. （in Chinese）

[2] 盧梅，李明樹. 軟件需求工程方法及工具評述[J]. 計算機研究與發展，1999， 36（11）：1289-1300.LU Mei， LI Mingshu. Review of methods and tools of software requirement engineering [J]. Journal of Computer Research &Development， 1999， 36（11）： 1289-1300. （in Chinese）

[3] 張亮. 需求管理技術在復雜仿真系統VV&A工作中的應用研究 [D]. 哈爾濱：哈爾濱工業大學， 2008.ZHANG Liang. Research on the application of the requirement management technique in the complex simulation system VV&A [D].Harbin： Harbin Institute of Technology， 2008. （in Chinese）

[4] Roussel J C. AIRBUS presentation benefits of requirement engineering with DOORS [C] // Presentation at Telelogic Capital Market Event， 2005.

[5] Alexander I. Requirements management with DOORS a success story [EB/OL]. http：//easyweb.easynet.co.uk/~iany /index.htm.

[6] MKS 簡介 [OB/EL]. http：//gytian.blog.51cto.com/ 1065457/1204676.Introduction of MKS [OB/EL]. http：//gytian.blog.51cto.com/1065457/1204676. （in Chinese）

[7] 淺談Integrity的架構設計分析[OB/EL]. http：//gytian.blog.51cto.com/ 1065457/ 1204782.Discussion of Integrity architecture design analysis [OB/EL].http：//gytian.blog.51cto.com/1065457/ 1204782. （in Chinese）