需求（Requirement）

需求（Requirement）是一個系統必須或應該滿足的能力或條件。當設計一個產品的時候，最初產生的設計概念或要求都是用文字描述和交流的。這些文字化描述的需求最終需要落實到每個設計細節。SysML通過建立文字化的需求元素，以及這些需求元素和系統中其它設計元素（表示功能的行為、表示架構的模塊等）的關系，以實現設計過程對中文字化需求的跟蹤分析。這種跟蹤分析的工作包括需求實現情況的分析（需求覆蓋分析）、變動之后對設計的影響分析（需求變更分析）等等。

根據需求說明的對象不同，需求分為“利益相關者需求”和“系統需求”。“利益相關者需求”是反映利益相關者需要的表述，是從用戶或其它使用系統的相關人員（包括維護人員、市場人員等）的角度，系統應該向他們提供什么。“系統需求”是系統將要做什么以及必須做到什么程度的表述，是從實現的角度，主要講給內部設計人員的。需求分析的過程，是先有利益相關者需求，然后經過分析、總結，才產生系統需求。

SysML標準附錄中對需求的類型進行了擴展，五種擴展需求的說明如下：

功能需求：代表對系統的功能要求，它將被一個“行為”（如“活動”Activity））滿足或改善（Refine，表示更詳細的說明）。

性能需求：表示系統或系統中的部件的能力應該達到的定量要求。通常用一個約束來更具體的說明（改善），被一個表示系統或部件能力的值屬性來滿足。

物理需求：表示系統或部件的物理特征或物理約束，被一個表示具體結構的元素來滿足。

接口需求：表示對系統或系統部件的端口的要求，被一個端口、連接器、項目流或約束屬性滿足。

設計約束：它表示對系統或系統中的部件給出的一個約束，例如“系統中的某類部件必須使用商業貨架產品”，被一個具體的模塊或部件滿足。

      上面所說的關系可以通過下面一個需求圖來說明：

 需求關系

如上所述，為了實現需求跟蹤和分析，SysML中定義了6種需求關系。

跟蹤關系：用于建立一種可追蹤的需求路徑，可以被后面這幾種更具體的需求關系代替（其它需求關系是從跟蹤關系繼承的）。

復制關系：從需求文本總是和主需求文本相同。這個關系用于同一個需求說明在不同的需求層級被重復使用的情況。從需求不用輸入文本，它總是會和主需求的說明保持一致。

導出需求關系：導出的需求來源于被導出需求。一般用于建立“系統需求”和“利益相關者需求”之間的關系（請注意：這個關系應該是從“系統需求”指向“利益相關者需求”，就是箭頭端是在后者，它表示“系統需求”是從“利益相關者需求”導出的。一些資料中將“導出需求”關系翻譯為“繼承”或“派生”都是錯誤的。“繼承”或“派生”都是子類自動具有父類的所有特征，而導出需求關系只是表示導出的需求和來源需求之間有一個“推導”的關系，兩者的描述內容可能是差距很大的）。

改善關系：用一種更具體、更詳細的方式說明了被改善的需求。例如用一個用例、用例的活動場景來改善一個需求的說明。

滿足關系：建立具體的設計元素實現了一個需求的關系。

驗證關系：建立測試方法和需求之間的驗證關系。測試方法在模型中一般是一個活動或其它的行為，SysML中建立了一種構造型“測試用例”來標記這些專門用于驗證需求的行為（測試用例不是“用例”，而是具體的行為）。

下面這個模型圖中舉出上面所述的各種關系：

需求圖

需求圖是展示需求元素的圖。需求圖的代表元素一般是一個包，需求圖中頂層的需求元素屬于這個包。在需求圖中最常見的表示方法是用需求包含關系把各層需求連接成一棵樹。包含關系表示需求的分解關系。把一個需求逐步分解為更細、更具體的需求項目，也是需求分析的常規工作。進行需求覆蓋分析的時候，如果是按組進行統計，則下層子需求全部滿足了，上層需求就認為也滿足了；如果是按“獨立”的統計方式，則不考慮上下層需求之間的包含關系。在需求圖中也可以顯示其它元素，然后用其它6種關系把這個元素和需求連起來。但為了更方便的建立需求和其它元素的關系，軟件工具中一般用“矩陣”表格的方式建立和顯示需求和其它元素的關系。

下圖是一個表示需求分解的需求圖。

     除了用圖，軟件工具中也經常提供表格的方式來顯示和管理需求。表格一般也展示為一棵樹的形式。如下所示上面需求的表格表示方式。

     在需求表格中，還會有需求導入、導出的功能，可以和其它系統進行需求數據的交換。

建模過程中的需求分析工作

在MBSE建模工作中，有多個工作階段涉及需求。系統建模的開始工作，就是從建立利益相關者需求。經過用例分析、功能分析，進一步總結出系統需求。再經過系統架構分析，最終形成能夠作為機械結構或電子電路設計輸入的物理需求。

（1）建立利益相關者需求。利益相關者需求可能來源于市場調研、參考已有系統、用戶的意見、合同中規定的研制要求、售后產品故障維修記錄等。利益相關者需求也可能是在一個專用的需求管理系統中已存在，導入到我們系統工程建模軟件中即可。而且，這些需求也未必是一開始就非常全面和完備的。我們進行需求分析的過程，也是不斷補充、完善需求的過程。甚至一開始我們連一條需求都沒有，通過后面用例分析才抽出來利益相關者需求也是正常的過程。

（2）建立用例。我們通過上一個文章已經了解到，用例是進行需求分析的重要工具。利益相關者需求和用例是“多對一”的關系，就是一個用例可以和多個利益相關者需求建立關系。可以用“跟蹤”關系、“改善”關系，或者“分配”關系建立利益相關者需求和用例之間的關系。不建立用例和需求的關系、直接建立用例的行為和需求的關系也可以，這個和使用的方法論有關。

（3）建立用例的活動場景，開展系統功能分析。用活動圖建立用例的活動場景，分析功能性的需求必要性和充分性。在這個過程中如果發現新的功能需求，補充到利益相關需求。同時，這個過程又是抽取系統需求的過程，就是分析以滿足利益相關者需求為目的，系統應該提供什么功能需求。

（4）建立系統需求。從如何實現、滿足利益相關者需求的角度，結合用例的活動場景分析，抽出系統需求條目。系統需求是否是可行的、充分的，也是需要在后面的架構設計過程中不斷完善。在整個模型中，需求應該和滿足需求的設計要素一一對應。

（5）建立滿足系統需求的架構模型。

（6）提取進行機械結構、電子電路、工藝或嵌入式軟件設計的物理需求。

從利益相關者需求到建立系統需求、物理需求，整個系統建模過程都是一個需求不斷更具體、更細化的過程。通過系統架構的設計分析，系統性能參數的分配和分析，逐步生成子系統的需求，以及開展機械結構設計、電子電路設計的物理需求。

需求跟蹤和需求覆蓋分析

在整個系統建模過程中，通過建立需求和需求、需求和其它設計元素之間的關系，可以跟蹤需求變動對設計的影響，統計建模工作的完成度。

例如利益相關者需求到功能分析的關系，通過一個需求改善關系矩陣，設置用例行為分析中的“活動”對利益相關者需求中“功能需求”改善關系，如下圖所示：

利益相關者需求改善關系的覆蓋分析，按組統計，結果是 66.66% ，如下所示：

查看沒有被改善的需求項，可以看到，是“自主行走”需求沒有進行用例及功能分析，沒有改善關系。因為是“按組”統計，“總需求”下面如果有一個子需求沒有被改善，就認為它也沒有被改善。需求數量的統計，是包括最上層的“總需求”，所以總數是6個，2個沒有改善，總的改善率是“66.66%”。

文章來源：智睿思維MBSE