萬會兵，劉 陽

(1.陸軍裝備部駐北京地區(qū)航空軍事代表室，北京 100024；2.上海航空電器股份有限公司，上海 200233)

0 引言

航空產品研制一般以需求為根本出發(fā)點，是自頂向下逐層分解，自底向上集成驗證的正向研發(fā)過程[1]。需求管理過程一般包括需求捕獲、需求分析與定義、需求分解分配、需求驗證策劃、需求驗證和確認、需求變更、需求追溯及需求驗證跟蹤管理等活動，覆蓋了航空產品研制全過程[2]。目前在航空領域，研究者們針對需求工程已開展了不少相關研究工作。陳重陽等[3]討論了海軍裝備發(fā)展作戰(zhàn)需求生成流程和機制，王煥青[4]、周璇[5]等論述了飛機需求變更管理技術，但對于軍品研制技術要求確認與傳遞方法研究較少。

當前，軍品研制中還存在研制技術要求傳遞不準確、確認不規(guī)范、驗證不充分等問題，導致出現(xiàn)了一系列質量問題。存在這些問題的主要原因，是研制技術要求還缺乏統(tǒng)一有效的收集、確認、傳遞、變更以及驗證的流程和方法，從而導致技術要求承接、傳遞、跟蹤、記錄、確認和反饋存在問題，有時甚至出現(xiàn)一些技術要求不落實或未驗證等現(xiàn)象。本文借鑒適航管理中研制要求管理的成熟經驗，采用需求工程方法，結合軍品研發(fā)管理體系要求，提出了一套基于需求工程的軍品研制技術要求確認與傳遞方法。

1 研制技術要求應遵循的基本要求

對于軍品研制技術要求，一般要做到滿足三個方面的基本要求，一是確保要求是無二意的，正確的，一致的，可操作的，技術可行的，可驗證的；二是要對產品全壽命周期明確要求內容，確保要求的完整性、可用性和壽命周期可追溯性；三是在定義要求時，每項要求的定義都須嚴肅慎重認真，以確保要求的制定是周密的、恰當?shù)摹?/p>

同時，基于需求工程的要求，軍品研制技術要求確認與傳遞應遵循以下基本原則：

1)明確性：用簡潔明了的語言來表述各項需求，對所有的需求都有清晰的解釋。

2)完整性：不遺漏任何必要的需求信息，每項需求都必須描述清楚。

3)正確性：每項需求都必須準確地反映待開發(fā)系統(tǒng)的真實要求。

4)一致性：每項需求的描述不應存在表面的或隱含的矛盾。

5)層次性：每項需求應根據(jù)待開發(fā)系統(tǒng)的需要，確定需求的層次和優(yōu)先級。

6)可實現(xiàn)性：每項需求都必須從現(xiàn)實條件出發(fā)，確保能夠在一定時間內得到滿足。

7)可追溯性：需求開發(fā)最終成果必須與用戶原始需求建立可追溯的關聯(lián)關系。

8)可驗證性：每項需求可通過檢查/評審、分析、試驗/演示或使用/服役經驗四種方法驗證。

2 基于需求工程的軍品研制技術要求管理流程

對于每一個軍品系統(tǒng)/產品，其完整的研制過程包括系統(tǒng)/產品的定義、系統(tǒng)/產品的設計及實施、系統(tǒng)/產品的集成驗證。需求管理作為研制的重要的活動，貫穿整個研制周期，它主要包括三個過程：需求的捕獲、需求的確認以及需求的驗證。此外，系統(tǒng)研制活動每一個環(huán)節(jié)均可能出現(xiàn)需求的變更情況，因此，需求變更與需求活動的每個環(huán)節(jié)都有聯(lián)系。圖1描述了軍品系統(tǒng)/產品需求管理流程中的關鍵活動和環(huán)節(jié)(包括需求更改)之間的關系。

圖1 需求管理過程

2.1 需求捕獲

需求捕獲的目的，是獲得與系統(tǒng)/產品相關的功能需求、性能需求、接口需求、操作需求、物理和安裝需求、安全性需求、維護性需求等，它們來源于利益攸關方(包括客戶、主制造商、供應商、分包商等)和相關的設計準則及理念(包括行業(yè)技術標準、政策法規(guī)等)。另外還有一種需求成為衍生需求，主要來源于系統(tǒng)/產品方案設計或設計實現(xiàn)的選擇(包括系統(tǒng)架構設計、安全性評估等)。

對于系統(tǒng)/產品供應商，其需求主要來源于主機單位之間的技術協(xié)議和頂層文件。通過符合性矩陣的方法，能夠快速準確地捕獲主機單位的需求。首先，對主機單位高層級需求內容條目化，并建立與需求相關的屬性列；然后，逐條進行分析和評估，從而捕獲其中有用的需求，形成系統(tǒng)/產品供應商低層級設計需求。圖2所示為非衍生需求捕獲過程模型。

圖2 非衍生需求捕獲過程模型

符合性矩陣方法的優(yōu)勢，是對需求內容進行結構化和多維度的管理，確保需求捕獲的有效性和準確性。除了第一列編號和第二列內容之外，符合性矩陣共有5個屬性列：“類型”、“符合狀態(tài)”、“偏離及說明”、“偏離批準”以及“是否傳遞”，其中：

“類型”，用來識別技術協(xié)議或頂層文件內容的類型屬性，共包括四個類型：標題、描述、技術需求、管理要求。

“符合狀態(tài)”，用來記錄對類型識別為技術需求或管理要求的條目符合狀態(tài)初步判斷的結果，共包括4個狀態(tài)：符合、部分符合、不符合、不適用。“符合”表示系統(tǒng)/產品供應商能夠滿足該技術需求；“部分符合”表示系統(tǒng)/產品供應商只能滿足該技術需求或管理要求的一部分；“不符合”表示系統(tǒng)/產品供應商不能滿足該技術需求或管理要求；“不適用”表示該技術需求或管理要求對系統(tǒng)/產品供應商不適用。

“偏離及說明”，用來記錄該技術需求或管理要求符合狀態(tài)原因以及對于判斷為部分符合、不符合和不適用技術需求或管理要求的偏離說明。

“偏離批準”，用來記錄客戶/主機單位對判斷為部分符合、不符合和不適用技術需求或管理要求及其偏離說明的批準情況?！芭鷾省北硎究蛻?主機單位同意該技術需求或管理要求的符合狀態(tài)及其偏離，“未批準”表示客戶/主機單位不同意。

“是否傳遞”，用來記錄技術需求或管理要求是否向下傳遞的狀態(tài)。對于不適用的需求，標示為“否”，即不向下傳遞；對于其他適用的技術需求或管理要求則標識為“是”，即需要傳遞到系統(tǒng)/產品供應商的設計需求。

2.2 需求確認

需求捕獲所形成的設計需求，是后續(xù)研制工作的設計輸入。為了保證后續(xù)研制工作正確開展，需要對捕獲的需求開展需求的確認工作，即通過確認來保證需求的“正確性”和“完整性”?！罢_性”表示一種程度，意指需求個體是否是清楚的、可實現(xiàn)的、可驗證的、與其它需求是相符合的，以及對需求集是必要的；“完整性”表示一種程度，意指對于給定的一組需求或需求集，所定義的系統(tǒng)功能或特性能夠在所確定運行環(huán)境的壽命周期各個階段的所有運行模式下滿足所有利益攸關方的需求。需求確認過程模型見圖3。

圖3 需求確認過程模型

需求的確認方法包括：評審、分析、建模仿真、試驗、追溯性。評審是邀請各專業(yè)專家對需求評審確認，在該過程中，依靠個人工程經驗對需求完整性和準確性進行評估；分析是通過理論計算、邏輯推理對需求進行確認，如功能危害性分析、初步安全性分析、相似性分析等；建模仿真是通過建模仿真的手段對需求進行確認；實驗是根據(jù)原型機、模擬器或實際實物模型，通過實驗室測試、演示等方法確認所捕獲的需求是否合理正確；追溯性是通過與上一層級已確認的需求(頂層需求)的追溯關系進行需求確認。

根據(jù)不同的需求特點，確定需求確認的方法，并根據(jù)確認方法開展相應的需求確認活動，最終形成需求確認矩陣。需求確認矩陣是在捕獲的設計需求(設計任務書)的基礎上形成的，除了包含設計任務書的內容和屬性，還增加了四列屬性：需求集、確認方法、確認狀態(tài)、確認證據(jù)。其中“需求集”是為了確認需求的完整性，按照一定的原則劃分的若干個需求的集合，通常按照系統(tǒng)/產品的功能特性或產品各專業(yè)領域來進行劃分；“確認方法”用來記錄開展相關確認活動的手段；“確認狀態(tài)”用來記錄需求確認結果的屬性，共有兩種狀態(tài)：“已確認”表示該需求已完成相關確認工作并得到確認，“未確認”表示需求工作未開展或者確認結果不滿足要求；“確認證據(jù)”用來記錄已得到確認的需求的相關確認支撐材料，主要包括分析報告、評審記錄、實驗報告、檢查單等。

2.3 需求驗證

系統(tǒng)/產品設計實施完成后，需要對已完成的設計或實現(xiàn)的系統(tǒng)進行驗證。其目的是表明系統(tǒng)/產品的設計或實施滿足了已確認的需求，即實現(xiàn)的系統(tǒng)/產品是否達到了預期的功能、性能以及規(guī)定的工作環(huán)境等要求。需求驗證過程模型見圖4。

圖4 需求驗證過程模型

需求的驗證方法包括：實驗/演示、檢查或評審、分析、使用/服役經驗。實驗是通過運行已實現(xiàn)的系統(tǒng)/產品，來評估系統(tǒng)/產品達到了預期的功能、性能以及規(guī)定的工作環(huán)境要求，以此表明需求得到滿足；檢查或評審是通過對過程文件、圖紙、硬件或軟件的檢查，以驗證需求是否得到了滿足，通常使用檢查單或類似的支持工作來進行，檢查系統(tǒng)是否符合已確立的實施過程和工藝是一種典型的檢查/評審方式；分析是對系統(tǒng)進行理論計算、邏輯推理(如建模仿真分析、安全性分析等)，并以此來表明系統(tǒng)/產品的設計或實現(xiàn)滿足預期的目標；使用/服役經驗，相似性和服役經驗是以其它軍品上相同系統(tǒng)或相似系統(tǒng)的合格服役經驗來表明實現(xiàn)的系統(tǒng)/產品滿足需求的驗證方法。

基于需求驗證方法開展相應的驗證活動，記錄并更新驗證狀態(tài)和驗證證據(jù)，形成驗證矩陣。需求驗證矩陣和需求確認矩陣合并在一起，最終形成需求確認與驗證矩陣。需求驗證矩陣主要包含三列屬性：驗證方法、驗證狀態(tài)、驗證證據(jù)。其中“驗證方法”用來記錄每一條需求的驗證方法，共有前面提到的四種常見的驗證方法；“驗證狀態(tài)”用來記錄需求驗證結果的屬性，共有兩種狀態(tài)，“通過”表示該需求驗證工作已經完成且需求已得到滿足，“未通過”表示需求驗證工作未開展或者驗證結果表明系統(tǒng)/產品的實現(xiàn)未滿足預期需求；“驗證證據(jù)”用來記錄需求驗證結果的相關支撐材料，主要包括分析報告、評審記錄、檢查單和實驗報告等。

2.4 需求更改

需求基線首次建立或需求文件首次發(fā)布后，需求更改還可能發(fā)生在系統(tǒng)/產品研制過程中任何一個階段，它會影響到需求過程的任何一個環(huán)節(jié)，因此，需求更改需要在整個系統(tǒng)/產品生命周期進行管理和控制，以評估需求更改的必要性、可行性以及更改的影響，并記錄需求更改評估及實施的整個過程。需求更改過程流程見圖5。

圖5 需求更改過程流程

需求更改的來源有兩個：內部更改和外部更改。內部更改是系統(tǒng)/產品研制方內部需求確認、需求驗證或設計實現(xiàn)過程引起的需求變更；外部更改是上級主機單位或者下級次級供應商的外部需求變更，一般采用技術協(xié)調單的形式通知系統(tǒng)/研制方。

需求更改的管理和控制屬于構型管理的范疇，其更改評估及實施過程與一般構型控制過程一致，即通過更改申請單(ECR)和更改建議(ECP)實現(xiàn)。無論更改來自內部還是外部，都要發(fā)起更改申請單以評估需求更改的必要性。若需求更改ECR不通過，則需求更改終止；若ECR通過，則回到需求捕獲環(huán)節(jié)并進行需求的確認，以評估需求更改后的正確性和完整性，然后發(fā)起ECP以評估需求更改的可行性及其影響，并將需求確認的正確性和完整性作為需求更改可行性評估的依據(jù)。若ECP批準不通過，則重新進行需求捕獲與需求確認環(huán)節(jié)，并重新進行ECP評估，直到ECP評估通過，最后執(zhí)行需求的更改，發(fā)布新的需求基線。

3 需求管理實踐

此處用一個軍工產品的真實范例說明需求管理過程的實踐流程(圖6)。

圖6 需求管理實踐活動流程圖

3.1 活動F0—技術協(xié)議、頂層文件可達性論證分析

技術協(xié)議、頂層文件可達性論證分析，主要是收集與系統(tǒng)研制相關的顧客需求(如軍品通用技術規(guī)范、技術協(xié)議、產品頂層需求、接口文件等)，行業(yè)標準(如GJB、HB、MIL標準)，法律法規(guī)要求等，通過具體開展F0.1-F0.8的活動，將其按照符合性矩陣的方法進行標記分析，輸出頂層文件的符合性矩陣(見表1)。

完成需求符合性矩陣后，要對F0.1-F0.6開展符合性矩陣檢查，對技術協(xié)議、頂層文件中的所有需求以符合性矩陣檢查單形式進行檢查，確認是否滿足如下要求：

1)符合性矩陣中是否包含源文件的所有需求？

2)所有需求是否與源文件一致？

3)所有偏離的需求是否定義了審批狀態(tài)？

4)是否所有產品相關需求都在“向下傳遞”屬性中標記了“是”？

5)所有在“向下傳遞”屬性中標記為“是”的需求是否都是產品相關需求？

根據(jù)檢查并回答以上問題的最終結果，結合開展F0.1-F0.7活動的具體信息，整理發(fā)布最終技術協(xié)議、頂層文件需求的符合性矩陣(VCM)，并根據(jù)軍品研制的要求，形成可達性論證分析報告。

表1 技術協(xié)議、頂層文件可達性論證分析符合性矩陣表

3.2 活動F1—需求捕獲

需求捕獲的主要目的，是根據(jù)技術協(xié)議、頂層文件需求的符合性矩陣，通過開展F1.1-F1.4活動，捕獲頂層非衍生需求，如表2-非衍生需求和衍生需求捕獲矩陣表中編號SYRD-7的源自技術協(xié)議等項層文件的技術需求，以及技術協(xié)議、頂層文件沒有提出但研制系統(tǒng)不可缺少的衍生需求，如表2中編號SYRD-22、 SYRD-23的技術需求，源自過往系統(tǒng)研制經驗和用戶好的體驗，然后后輸出需求捕獲文件。

表2 非衍生需求和衍生需求捕獲矩陣表

在這里，表2中根據(jù)工程經驗對已經條目化的需求進行需求判斷，將條目表中的文字分為需求、標題和描述三類，并做標記。其中，“標題”指文件中的標題、抬頭；“描述”指幫助理解需求撰寫的一些輔助信息，但不是對系統(tǒng)/設備研制做出的要求；“需求”指本系統(tǒng)/設備研制要求。同時，需求類型分為“技術需求”和“管理要求”，在需求傳遞過程中，僅對技術需求確認，而管理要求傳遞至設計任務書。

根據(jù)F1.1-F1.3捕獲的非衍生需求和衍生需求編寫設計任務書。捕獲的需求中需求不明確或者顧客對所有供應商提出的通用需求，可以改寫成意思明確、適用于本研制系統(tǒng)/設備的需求，同時根據(jù)捕獲的系統(tǒng)/設備需求在設計任務書中加入系統(tǒng)/設備描述(非必須)，幫助設計任務書閱讀者理解該研制系統(tǒng)/設備的需求。

3.3 活動F2—需求確認

需求確認主要是在需求捕獲的基礎上，通過F2.1-F2.7活動，確認需求的正確性和完整性，最終輸出需求確認矩陣(見表3)。

確認需求的“正確性”，意指需求個體是否是清楚的、可驗證的、與其他需求是相符合的，以及對需求集是必要的；“完整性”，意指當一個系統(tǒng)滿足了一組正確的需求時，這組需求是否在所確定運行環(huán)境的壽命周期各個階段滿足顧客、用戶、維修人員以及軍品、系統(tǒng)、項目開發(fā)人員等方面的需求。

在需求確認矩陣增加了“需求集”信息。定義需求集的目的在于方便硬件工程師、軟件工程師、結構工程師等有針對性地確認與本專業(yè)相關的需求，提升確認效率。系統(tǒng)工程師、六性工程師和驗證工程師要對所有需求進行確認，需求集標注的需求條目須經除上述三類工程人員之外的相應工程人員確認。

表3 需求確認矩陣表

需求確認檢查單要回答以下兩個方面的問題：

一是需求的正確性：

1)是否是一條需求？

2)是否與上層需求一致？

3)確認方法是否有具體的支撐數(shù)據(jù)？

4)本條需求是否清晰？

5)本條需求是否可驗證？

6)是否存在必要的驗收標準？

7)本條需求是否可實現(xiàn)？

8)如果是一條衍生需求，是否有原理支撐？

9)保持本條需求是否比將其分成幾條好？

10)是否與父需求建立鏈接關系？

二是需求的完整性：

1)本條需求對需求集的完整性是否必須？

2)本需求集單獨存在是否比與其他需求集合并更好？

3)在本需求集中本條需求是否與其他需求一致？

4)軟件的需求能否按符合預期功能被開發(fā)？

5)本需求集是否包含了所有可靠性需求？

6)本需求集是否覆蓋了所有預期功能和模式？

7)本需求集是否覆蓋了所有適用的接口？

8)本需求集是否包含所有PSSA需求？

9)本需求集是否聲明了所有失效條件和禁止行為？

10)本需求集是否覆蓋了所有操作場景/模式？

11)需求和確認的屬性是否都已填寫完成？

根據(jù)需求確認檢查單的最終結果，結合F2.1-F2.6活動的具體信息，整理發(fā)布最終系統(tǒng)需求確認矩陣(活動F2.6是對F2.1-F2.5輸出結果的糾正和調整)。

3.4 活動F3—設計實現(xiàn)

設計實現(xiàn)主要是根據(jù)需求確認矩陣，按照軍品研發(fā)體系要求進行的設備架構、技術方案設計、生產制造等活動，使系統(tǒng)/設備功能、性能得以正確實現(xiàn)。

3.5 活動F4—需求驗證

需求驗證是在設計實現(xiàn)的基礎上進行需求的驗證，以驗證功能、性能需求都已經正確地得以實現(xiàn)。針對需求的不同，可以選擇不同的方法進行確認。需求確認的方法主要有以下四種：“檢查/評審”—通過檢查或評審設計方案、圖紙及相關設計資料，驗證所實施的設計已滿足了確認的需求；“分析”—通過對設計進行詳細的理論分析計算或者采用相似性分析來評估正常和非正常狀態(tài)下功能性能是否滿足預期目標；“實驗/演示”—通過實驗或者演示以驗證需求得以滿足的方式；“使用/服役經驗”—通過其它具有相同或相似設計的合格服役經驗，以及系統(tǒng)/設備在顧客的交付使用評估結論等，表明需求得以滿足的方式(見表4)。

在這里，要根據(jù)確定的需求驗證方法，編寫需求驗證程序，其主要內容包括所需要的資料及信息、環(huán)境條件,具體的驗證活動步驟，以及如何記錄驗證結果和驗證證據(jù)；要基于需求驗證程序，開展相應的驗證活動，并記錄相應的驗證結果、證據(jù)，更新驗證矩陣；要根據(jù)需求確認矩陣和需求驗證矩陣，形成需求確認與驗證矩陣。

表4 需求驗證矩陣表

續(xù)表4

對于采用實驗/演示驗證方法的需求，要根據(jù)實驗大綱，對系統(tǒng)/設備進行驗證，并記錄相關實驗結果和現(xiàn)象；對于采用檢查/評審驗證方法的需求，要按照檢查/評審過程文件的要求，組織相關人員對設計方案、圖紙等相關設計資料進行仔細的檢查，確認設計實施是否滿足要求；對于采用分析驗證方法的需求，要通過對設計進行詳細的理論分析計算及相似性分析來評估正常和非正常狀態(tài)下系統(tǒng)/設備功能性能是否滿足預期目標。

4 結束語

采用基于需求工程的軍品研制技術要求確認與傳遞方法，能夠保證研制技術要求有效地收集、確認、傳遞、變更以及驗證，從根本上克服技術要求出現(xiàn)遺漏、識別不全面或得不到充分驗證等問題。這套方法盡管會在一定程度上增加需求工作的工作量和成本，但由于設計需求更加明確，可以讓承制方從中獲得更高的型號研制工作效益，比如減少設計迭代，改善配置管理，降低人為失誤等等。