面向民機復雜系統需求管理過程研究

田 彬 / Tian Bin

(上海飛機設計研究院，上海201210)

?

面向民機復雜系統需求管理過程研究

田 彬 / Tian Bin

(上海飛機設計研究院，上海201210)

需求是商用飛機研制的基礎，并貫穿于整個飛機研制的生命周期。在需求研發團隊中建立一套有效的需求管理流程，使捕獲、傳遞和更改需求的過程更規范高效。在飛機研制早期就保證需求的正確性和完整性，這樣最終達到節約成本和優化進度的目的，設計出客戶想要的飛機。

需求; 需求管理; 需求確認; 需求驗證

0 引言

商用飛機具有技術要求高，研發周期長，項目投入大等特點。其研制過程就是基于需求的實現過程，把客戶的需求如何一層層地傳遞下去，使最終生產出來的飛機是客戶想要的。需求的影響貫穿于系統研制的始終，無論是設計、驗證還是集成都離不開需求。需求管理確保通過分配、驗證和更改的調整和控制使解決方案符合利益攸關者的需求和期望。需求管理影響系統全生命周期的質量和成本。需求管理也逐步成為各工程領域和學術界研究的重點。

1 需求管理過程

需求管理的主要目的是確保利益攸關方對飛機需求理解一致。需求管理通過在需求開發過程中建立基線使需求受控；確保計劃、產品和活動與需求相一致。為了達到以上目標，必須保證需求更改是受控的。需求管理貫穿整個系統生命執行過程，以一致的、可追溯的、可關聯的、可驗證的方式捕獲、確認、驗證、管理和控制需求和相關文件[1]。

如圖1所示，需求管理主要過程包括：需求捕獲流程，需求確認，需求驗證，需求變更管理等，評審評估和構型管理活動也屬于需求管理的活動。

圖1 需求管理過程

1.1 需求管理捕獲流程

需求管理捕獲活動流程的目的是實現統一的方式記錄相關方的需求，并確保需求被正確理解，以實現在項目初始即確保滿足利益攸關方的需要和期望。在捕獲需求時，還要記錄需求的來源[1]。

需求捕獲的具體活動流程如圖2所示，這些流程活動是按先后順序逐步實現的。

圖2 需求捕獲流程

1.1.1 捕獲利益攸關方

識別利益攸關方是需求管理工作的第一步。現代航空制造商在立項研發新的飛機型號過程中，為了取得最終的適航、市場、運營及商業成功，必須完整地標識所有攸關方，通過體系化的方法捕獲利益攸關方的需求，并在決策和具體工作中落實利益攸關方的需求，使產品滿足攸關方預期[2]。

圖3 確定利益相關方

1.1.2 需求信息架構

在項目初期定義出需求的層次關系，提供需求組織和分解的標準，描述項目開發階段和需求文件層次的關系。對多系統建立需求組織架構可以清晰地表述需求信息的流向，表達出需求各層級之間的關系，說明需求之間的直接追溯關系。這是非常重要和必要的。

在飛機級主要的需求模塊有：

0—規章和市場需求文件夾里主要有：RM01適航模塊，RM02 市場需求模塊。

1—頂層需求和目標文件夾里主要有：AMRO飛機制造需求模塊，CSRO客戶支持需求與目標模塊，DRO飛機設計需求與目標模塊。

2—飛機級需求文件夾主要有：AFDD飛機級功能定義模塊；AFRD 飛機級功能性需求模塊；ANFRD 飛機級非功能性需求模塊。

在系統級主要的需求模塊有：

3—Systems需求文件夾里主要有：系統的功能性需求模塊；系統的非功能性需求模塊；系統功能危害性評估模塊；系統功能定義及分解模塊；系統需求確認矩陣模塊；系統驗證矩陣模塊。

PS—系統產品技術規范。

圖4是需求模塊的層次架構，需求按照從飛機級到系統級層層分解傳遞和分配。

圖4 需求層次架構

1.1.3 模塊化需求

需要對飛機和系統產生的需求模塊按照需求管理規定進行編號，每一個需求模塊都按照分類的需求模板填寫需求的相關內容，和相關屬性內容。圖5是系統需求文件夾下的需求模塊集。

圖5 需求模塊化

1.1.4 規范化需求

需求的編寫有具體、可測量、可接受、可實現和可追溯5大標準，應根據此標準對需求進行初步規范。根據每份需求的類別建立不同的屬性，在研制的不同階段建立不同的屬性便于需求捕獲、需求確認、需求驗證等活動的展開。每個屬性都應可見，其值可更新。

應存儲每個需求的信息或者屬性。每個成員能夠瀏覽這些屬性，指定權限的工程技術人員能夠更新它們的數值。需求管理工具生成系統定義的幾個屬性，例如需求產生的日期和版本，并且允許客戶定義其他類型的屬性，譬如需求ID、需求類型、需求源和成熟度。

1.1.5 需求確認

需求確認的目的是為了確定所捕獲和分析的需求是正確的、一致的、完整的，以減少需求缺失、需求沖突、需求錯誤等對后期研發工作的影響。

需求的正確性是指在需求陳述和屬性中不存在歧義和錯誤。如果需求彼此之間沒有出現矛盾沖突，就可以說這一系列需求是正確的。

需求的完整性是指確保產品的所有特征、功能和約束條件能夠通過完整的需求集合來表達，需求集合的遺漏將帶來很多問題。

需求確認活動如表1所示。

表1 需求確認活動

1.2 需求初步確認

需求初步確認是對需求的正確性和完整性進行初步的判定。

(1)正確性要求對每一條需求進行檢查。正確性檢查單樣例如表2所示。

表2 正確性檢查單樣例

(2)完整性要求對需求集合進行檢查。完整性檢查單樣例如表3所示。

1.3 需求驗證

需求驗證是建立需求和驗證結果之間的追溯鏈

表3 完整性檢查單樣例

接關系，為此必須要定義具體的驗證程序，單獨的驗證計劃定義具體的流程與方法。記錄需求與驗證程序的鏈接，并記錄驗證結果。確保需求使用了建議的驗證方法，通過驗證標識出產品的不足和與需求不一致的部分。 需求驗證活動主要有：開發定義驗證程序——制定驗證計劃和初始驗證矩陣；鏈接需求與對應的驗證程序——需求與驗證矩陣之間的鏈接；捕獲驗證證據；評審驗證結果；輸出數據進入構型管理。

1.4 需求變更管理

雖然需求達到了發布狀態，但是隨著復雜系統研究的深入，需求不可避免地會發生變更。

一般來說，由需求開發團隊提出需求變更請求，交由技術團隊進行評估，內容包括需求更改的必要性和合理性評估，對其他需求的影響評估等。如果同意變更，由需求管理人員對需求的狀態從已批準狀態變為待更新狀態，并由需求開發團隊進行需求更新，直到需求再次批準；如果不同意變更，則終止此項活動。需求變更流程如圖6所示[2]。

1.5 需求管理工具

在項目的整個生命周期中，高效的需求管理工具是項目團隊成員之間有效溝通的重要保障。

需求管理工具是管理和控制需求流程并進行追溯的需求管理平臺，可以由一個或多個工具組成。自動化的需求管理平臺能夠幫助管理項目需求

圖6 需求變更流程

和進展。平臺能夠涵蓋下列功能[3]：

(1)識別單個需求；

(2)將需求分配和分類；

(3)識別需求分組修改并添加基線；

(4)提供基礎數據接口。

隨著研制的進展，自動化的工具集可以輔助管理項目的需求。工具能涵蓋的范圍如下[4]：

(1)管理文檔：通過添加表格或者對先前已存在的文件鏈接來追蹤需求；

(2)追溯需求：在導入的需求集之間追溯和編輯需求；

(3)生成需求：在平臺內部生成需求文件；

(4)嵌入模型或模擬圖。

需求管理工具應能夠通過更改控制來收集和監控需求的穩定性。更改控制追蹤對現有需求的任何添加、刪除和改變。追蹤導致更改的原因，改進流程，降低未來型號的更改及成本。通過這種數據收集進行持續的改進，從而降低未來的不穩定性[5]。

2 結論

針對民用飛機的特點和研制要求，提出了基于狀態流的需求管理過程，闡述了需求開發團隊，需求確認團隊和需求驗證團隊的職責，介紹了需求捕獲流程，需求分析評審，需求確認和需求驗證，需求變更等活動。通過有效的需求管理，確保了飛機早期需求的正確性和完整性，以及系統生命周期中需求的穩定性。

[1] 胡楠.對基于項目需求工程理論的軟件需求管理的研究[J].計算機光盤軟件與應用，2012(14)：116-118.

[2] 呂岸.面向民用記載系統的需求管理過程研究[J].航空研究，2015,5:23-25.

[3] Scott Jackson.Systems engineering for commercial aircraft 1997 .

[4] SAE AIR6110飛機/系統研制過程示例[S].

[5] SAE ARP 4754A民用飛機與系統研制指南[S].

Research on Requirement Management Process for Civil Aircraft Complicated System

(Shanghai Aircraft Design and Resarch Institute,Shanghai 201210,China)

Requirements are the basis of civil airplane development, and run throughout the entire life cycle of the airplane development. An effective requirement management process is established , which is specified and effective to capture ,transfer and modify requirement. At the beginning of airplane development, the correctness and completeness of requirement have to be assured. At last saving cost and optimizing schedule will be got, and the airplane that the custom want will be design.

requirement; requirement management ; requirement validate; requirement verification

F272.7

A