張粉婷 趙新宇

（中國民航飛行學院，四川 廣漢 618307）

1 需求分析方法

1.1 需求分析概念

需求分析（如SE 過程集）是一個迭代活動，其中隨著概念的發(fā)展和更多細節(jié)的了解，確定并不斷完善新的需求。對這些進行分析，并找出缺陷和成本動因，并與客戶一起檢查，以建立項目的需求基準。 需求分析的第二個目的是提供對各種功能之間相互作用的理解，并根據(jù)用戶目標獲得一組平衡的需求。 需求不是憑空開發(fā)的。 需求開發(fā)過程的重要組成部分是ConOps，它所伴隨的隱式設計概念以及相關技術的相關需求。需求來自多種來源，包括：客戶/用戶，法規(guī)/代碼和公司實體，如圖1 所示。

這個復雜的過程采用績效分析，貿(mào)易研究，約束評估和成本/收益分析。 如果不確定它們對較低級別元素的影響（可實現(xiàn)性），則無法建立系統(tǒng)需求。因此，需求定義和分析是一個迭代。

1.2 良好要求的特征

在定義需求時， 應注意確保適當?shù)刂贫诵枨?。對于每個需求，應考慮以下屬性：

必要——每個需求都會以處理，維護和驗證的形式付出額外的努力。 僅應寫下必要的要求。 不必要的需求有兩種：（1）不必要的設計規(guī)范，應由設計者自行決定；（2）多余的要求包括在某些其他要求組合中。

圖1 需求來源

獨立于實施——客戶要求可以按他們希望的任何級別強加。 但是，當客戶需求指定設計時，應該提出質(zhì)疑。 適當?shù)囊髴ㄟ^描述“框”將執(zhí)行的轉(zhuǎn)換來處理被指定為“黑框”的實體。 需求應指定在該級別上將要執(zhí)行的操作，而不是在該級別上將要執(zhí)行的操作方式。

簡潔明了——需求必須傳達將要進行的工作到下一個開發(fā)階段。

完整——要求是對設計者（或?qū)嵤┱撸┑南乱粋€要求。

一致——在許多情況下，存在適用的政府，行業(yè)和產(chǎn)品標準，規(guī)范和接口，需要遵守這些標準。

可實現(xiàn)的——實施設計師必須參與需求定義。

可驗證——必須通過4 種標準方法（檢查、分析、演示或測試）之一對每個需求進行某種程度的驗證。

2 功能和目標

2.1 定義系統(tǒng)功能和性能目標

生產(chǎn)、部署、操作和支持的概念是一個很好的基礎，系統(tǒng)工程師可以從中識別感興趣的系統(tǒng)所需的功能以及系統(tǒng)的相關性能目標。作為此功能定義活動的結(jié)果，將確定許多性能要求。

2.2 派生和完善功能/性能要求

在項目開始時，SE 主要關注用戶需求分析，導致將用戶需求轉(zhuǎn)換為基本功能和一組可量化的性能需求，這些需求可以轉(zhuǎn)化為設計需求。

建立一套完整的系統(tǒng)要求是一項復雜，耗時的任務，幾乎涉及所有項目領域，都是一項交互式工作。它必須盡早完成，因為它構成了所有設計，制造，驗證，操作、維護和處置工作的基礎，因此決定了項目的成本和進度。 該活動在每個階段都是迭代的，隨著設計詳細程度的提高， 持續(xù)不斷地反饋， 并且來自SRD，SOW，公司政策和程序，ConOps 文檔（或運營概念文檔），設計概念，系統(tǒng)層次結(jié)構和數(shù)據(jù)項描述（標識規(guī)范的預期內(nèi)容）。 總體需求分析過程如圖2 所示。

質(zhì)量功能部署（QFD）是一種有用的技術，尤其是在“客戶的聲音”不清楚的情況下。它提供了一種快速的方法來將客戶需求轉(zhuǎn)換為規(guī)格，并系統(tǒng)地將需求降低到較低的設計、零件、制造和生產(chǎn)水平。陰影的關系矩陣顯示了功能和需求之間的相關性。 兩個同心圓（雙圓）用于指示特征和需求之間的強相關性。單個圓圈表示適度的貢獻?？瞻琢斜硎鞠鄬τ诹谐龅囊蠖圆槐匾墓δ?。同樣，空白行表示未解決的要求。其他有用的方法包括：使用系統(tǒng)層次結(jié)構，F(xiàn)FBD，時間表，控制/數(shù)據(jù)流程圖，貿(mào)易研究和需求分配表進行功能分解。

圖2 需求派生，分配和流動

如上所述，較大的系統(tǒng)可能需要從系統(tǒng)體系結(jié)構演變而來的高級系統(tǒng)仿真。該仿真將用于快速檢查各種尺寸和參數(shù)，而不僅僅是“點設計”，以確保獲得“最佳”解決方案——系統(tǒng)始終是合適的尺寸，沒有阻塞點。 檢查推導和合并要求所帶來的任何不利后果。 在無法確認現(xiàn)有用戶需求的地方，請進行貿(mào)易研究以確定更合適的需求，并以最小的成本獲得最佳平衡的性能。 在必須分配關鍵資源（例如重量、功率、內(nèi)存和吞吐量）的地方，可能需要進行貿(mào)易研究以確定適當?shù)姆峙?。將需求分析過程中產(chǎn)生的修訂和衍生的需求和參數(shù)納入需求數(shù)據(jù)庫， 并保持對源需求的可追溯性。準備規(guī)范文件并提交給所有組織，以供審核。批準后，將文檔輸入正式發(fā)布系統(tǒng)，并在配置管理控制下進行維護。 任何進一步的更改都將需要配置控制委員會（CCB）的批準[1]。 需求分析過程的結(jié)果應該是一組完整，準確，無歧義的系統(tǒng)需求的基線，記錄在需求數(shù)據(jù)庫中，所有各方均可訪問，并記錄在已批準的已發(fā)布系統(tǒng)規(guī)范中。通常使用以下措施來評估此需求分析活動的進度和完成情況。

2.3 定義其他非功能性要求

概念文檔還將提出與感興趣的系統(tǒng)提供的主要功能不直接相關的需求，例如可用性、可支持性、安全性和培訓。 例如，0resund 橋案例說明了通過對施工實踐建立約束來避免負面的環(huán)境影響。盡早解決非功能性需求是確保它們不會被遺忘和滿足的一種好方法。

圖3 質(zhì)量功能部署（QFD）：質(zhì)量屋

2.4 開發(fā)規(guī)格樹和規(guī)格

在實踐中， 需求工程不僅是系統(tǒng)開發(fā)過程的前端，而且是一個復雜的通信和協(xié)商過程，涉及將使用系統(tǒng)的各方（即客戶），將提供部分或全部系統(tǒng)的各方（即開發(fā)人員和供應商）以及將驗證系統(tǒng)的各方（即驗證組）。

對于復雜的系統(tǒng)， 定義/設計過程是通過多次分層迭代依次應用到硬件和軟件CI 定義級別的。 目的是在系統(tǒng)設計的特定級別（例如，硬件、軟件和操作）為每個配置項創(chuàng)建規(guī)范基線，并將這些規(guī)范放置在向下的層次結(jié)構中。這將使每個配置項的進一步定義可以與其他所有配置項并行地獨立進行，同時保持需求的可追溯性和設計工程為衍生的需求提供技術定義數(shù)據(jù)，并記錄設計決策。 支持學科監(jiān)視每個專業(yè)領域中需求的執(zhí)行情況，識別需求并查看需求定義過程的結(jié)果。 這項工作的結(jié)果是一組要求聲明，這些要求聲明放置在系統(tǒng)和CI 規(guī)范中。 規(guī)范草案由需求數(shù)據(jù)庫生成，并分發(fā)給審閱者。 然后將副本連同適當?shù)脑u論一起退還給作者。解決所有注釋后，文檔正式發(fā)布。需求數(shù)據(jù)庫工具應直接從數(shù)據(jù)庫生成規(guī)范，而無須人工干預，從而保持數(shù)據(jù)庫的完整性[2]。 注意：一個級別的規(guī)格表示對它以下級別的要求。

2.5 生成系統(tǒng)規(guī)范

系統(tǒng)規(guī)范是一組完整、準確、無歧義的系統(tǒng)需求的基準，記錄在需求數(shù)據(jù)庫中，所有各方均可訪問。在需求分析過程中，通常有必要生成明確的系統(tǒng)需求的“快照”報告。 為了幫助該過程，可能需要在需求數(shù)據(jù)庫中創(chuàng)建一組明確的需求對象，并提供從其對應的原始需求中提供可追溯性的信息。明確的要求可以分為功能性、性能、約束性和非功能性。

3 結(jié)論

需求管理指明了系統(tǒng)開發(fā)所要做和必須做的每一件事， 指明了所有設計應該提供的功能和必然受到的制約[3]。 需求管理的過程，從需求獲取開始貫于整個項目生命周期， 力圖實現(xiàn)最終產(chǎn)品同需求的最佳結(jié)合[4]。因此， 需要以貫徹基于系統(tǒng)工程的系統(tǒng)研制流程、加強過程管控為契機，開展本標準研究，推動系統(tǒng)工程在國產(chǎn)民機研制過程中的深入應用。