基于模型的需求建模與管理系統前端設計及實現

徐悅涵，錢祎凱，周晨初，劉玉生

（1.浙江大學CAD&CG 國家重點實驗室，浙江 杭州 310058；2．上海空間推進研究所，上海 201112；3．西安航天動力研究所，陜西 西安 710100）

需求是很多工作的基礎，隨著工作的復雜度越來越高，相應的需求數量和難易程度也隨之變得繁瑣復雜。國際電氣與電子工程師協會（IEEE）認為，需求是以下兩者所描述的條件和能力的文檔化表示[1]：（1）用戶解決某個問題或者達到某個目標所需要的條件或能力；（2）一個系統或系統組件為了實現某個契約、標準、規格說明（規約）或其他需要遵循的文件而必須滿足的條件或擁有的能力。

需求工程是指通過獲取利益相關者的需求后，以一種合適的方式記錄、確認和驗證需求，以及在系統的整個生命周期過程中管理好需求[2]。需求工程結構組成如圖1。其中需求獲取是指根據項目的特性選擇使用不同的合適的捕獲技術，從文檔和遺留系統以及最為主要的利益相關者中獲取需求，并且對需求信息進行完善，是需求工程的核心活動。需求定義是指定義獲取的需求，是為了更好地進行交流。需求分析是利用結構化方法對需求進行分析，目的是清楚地理解需要解決的問題，進行產品需求分析，分劃出產品的功能和性能，建立產品需要滿足的約束條件。實踐中，最為普遍的是使用自然語言進行需求文檔化。需求驗證是對需求的確認與協商，確保所記錄的需求能夠滿足預先定義的質量標準即質量檢查。需求管理是在整個生命周期里對記錄的需求進行維護以及確保相關信息的持續可用性，并且采用合理的方式對信息進行有效管理，確保可以選擇性地對信息進行訪問。它包括需求增刪、跟蹤、變更。

圖1 需求工程的結構組成

目前，國內外的需求管理工具已有較多，如國外的有IBM DOORS 與Rational RequisitePro、JIRA Software、3SL Cradle 等，國內的有杭州華望M-Require、飛書OK 等。但這些需求管理軟件主要是面向傳統的產品設計流程尤其是傳統的基于文檔的系統工程而研發的。近年來，基于模型的工程（Model based Engineering,MBE）以及基于模型的系統工程（Model based Systems Engineering, MBSE）得到了廣泛的重視及應用[3-7]，因此，對傳統的需求管理工具也提出了新的要求，如：需要更為清晰地描述需求間的各種關系如追溯、滿足、復印、分解等；更為強大的需求追蹤功能，以支持多維度、多層級、大深度的溯源分析；需要有需求管理流程功能等。

為此，我們提出以基于模型的需求工程思想為基礎，重點探索基于模型的需求建模與管理系統前端設計方法，并探索基于Web 的圖形化需求建模與管理實現方法。

1 圖形化需求管理系統設計和實現

圖形化需求建模和管理系統是復雜的系統，它高度集成了基于Web 的需求管理系統，以及基于系統工程的建模技術。為了提高復雜系統的開發效率和降低開發的風險和成本，本系統采用循序漸進、迭代的方式進行開發。因此，本系統主要分為兩個部分：第一部分是Web 環境下進行需求管理的設計與實現；第二部分是在需求管理系統的基礎上實現圖形化建模。

1.1 系統架構設計

系統的架構設計是系統成功實現的重要依據。主要過程包括設計系統的各個重要組件以及組件間通信，界定系統功能，規劃系統特征，規劃并設計實現各項指標的方案，利用多學科、多維度構建生成子系統。

Web 的應用架構常見模式有C/S（客戶/服務器）模式、B/S（瀏覽器/服務器）模式、單頁面應用模式。由于基于互聯網應用時存在面向用戶的不確定性、操作系統的差異性、高要求的體驗感等問題，因此單頁面應用模式是最佳選擇。

系統選擇Vue 開發框架，通過Element-UI 組件庫和自己封裝復用組件形成視圖層，通過Vue-Router 切換路由，利用Vuex 狀態管理工具管理數據。而數據的獲得與發送是通過Ajax 與服務端進行交互的。整體架構如圖2 所示。

圖2 整體架構圖

1.2 功能模塊設計

根據需求管理系統流程分析，經過細化、分類、整合后，最終可以分為基礎功能模塊及需求開發、追蹤、變更、版本管理等模塊。

基礎功能模塊是系統有序執行和復雜功能實現的基礎，包括了個人模塊、基礎管理模塊、通知模塊。個人模塊主要涉及個人信息以及系統安全。基礎管理模塊，負責管理系統用戶、單位、權限，系統預置功能自定義配置。通知模塊，記錄操作日志，發送變更通知。

在需求開發、需求追蹤、需求變更與需求版本管理的眾多功能中，需求的版本管理最為復雜，需要在需求狀態發生變更后通過唯一的版本號進行標記。本文提出基于特殊標記的需求版本管理方法。用戶選擇某一版本，系統需要將所有與此版本相關的需求都呈現出來。

1.3 功能模塊前端實現

基礎功能部分與常見系統前端實現方式基本一致，本文不進行闡述。本節主要剖析需求開發、變更、版本管理部分的前端實現。需求追蹤將在下一章進行詳細介紹。

（1）需求開發前端實現：需求可以以文檔的方式或者以條目化的方式錄入系統。前者最終可轉換成條目化的方式。一條需求往往可以被分解為多個子需求，子需求還可繼續被分解。如此往復，需求就形成了層次結構。條目化的需求既可完整記錄需求信息，又能展示其層次化結構。條目化的需求符合對象管理組織的規范[8]，含有Id、名稱和描述屬性、擴展屬性、需求間的關系等信息。一條需求對應一個條目，占據需求文檔的一行。

（2）需求新增和需求表前端實現。新增需求使用彈窗和Form 表單組件，并基于規則進行檢驗，合法后新增成功。本文提出基于前端規則的校驗方法，除了可以減輕服務器負擔外，還可以優化瀏覽器性能，減少數據傳輸，加快頁面渲染。為了便于查閱，需求以表的形式羅列在頁面中，使用表格組件（Table）進行展示。為了便于需求變更和管理，Table 組件還拓展了操作欄。

（3）需求變更前端實現。在進行評審流程前，需要需求編輯，其可復用新增需求的組件實現，并通過update()接口向服務器傳數據。提交評審申請后，評審小組成員從需求表的界面進入評審狀態。此時需求表出現評審欄，可選擇通過、不通過。前端實現這個流程，依然要利用需求表（Table）組件。新增評審列，列中有radio 單選按鈕。不通過則出現不通過原因輸入彈窗。處于評審狀態時的需求表如圖3 所示。

圖3 處于評審狀態時的需求表

（4）需求版本管理前端實現。對于前端而言主要是版本列表的展示和版本信息的填寫彈窗。列表展示使用卡片的形式展示，版本信息填寫也是由Form 表單組件實現。

2 圖形化建模的前端設計與實現

在整個基于模型的需求建模功能中，需求追蹤建模是最為重要與復雜的，它是管理需求變更和驗證需求是否得到實現的有效途徑，可以用來跟蹤每個需求的狀態[9]。需求追蹤圖形化建模，為用戶提供了直觀、清晰觀察需求間關系的工具和需求變更發生時分析互相影響的依據。

2.1 圖形化需求建模的設計

標準系統建模語言SysML 是MBSE 的圖形化建模的關鍵與基礎，其中的需求圖（Requirement Diagram）是用來對需求進行圖形化展示的，其表示的需求間可追蹤性是需求分析后的產物。需求圖使得需求追蹤多了一種圖形化的實現方式。需求與需求之間的關系構成需求圖。需求圖建模包括對需求和需求間關系實現圖形化。

2.1.1 需求條目的表示

MBSE 是利用SysML 語言對需求進行圖形化建模。條目化的方式側重于需求信息的完整性，無法簡單描述需求關系，圖形化的方式可更直觀快速地展示需求的可追蹤性。

SysML 需求圖用“requirement”類型表示單一需求，包括3 個元素：Name、Id、Text。Name 是需求的命名，Id 是需求的唯一標識符，Text 是需求的描述。需求模型示例如圖4。

圖4 需求模型示例

數據在需求創建之初就以條目化的形式存儲在數據庫中。其中條目化的需求包括：Id、Name、Text、起止日期、優先級等屬性。因此數據庫中的數據滿足SysML 需求模型所需要的Id、Name、Text的三要素，即條目化的需求可以直接轉換成圖形化的需求。

2.1.2 需求關系的表示

根據SysML 所定義的需求關系，建模過程中會涉及到6 種關系：包含、跟蹤、繼承、精化、滿足、驗證[10]。包含關系，描述了需求的層級結構。跟蹤關系，是一種依賴關系，“trace”。繼承關系，也是一種依賴關系，“deriveReqt”。精化關系，屬于依賴關系，關系中的子對象是比被精化方更為具化細致明確的描述，“refine”。滿足關系，同屬于依賴關系，“satisfy”。驗證關系，是依賴關系的一種，用于關聯提供方需求和驗證方的測試用例，“verify”。

根據SysML 需求關系展示方法，需求關系可使用關系標識法展示。關系標識法包括：直接標識法、分隔框標識法、插圖標識法、關系矩陣、關系表格。

（1）直接標識法。直接標識法是最基礎的表示方法，是依賴關系表示法。箭頭端是提供方，直線末端是依賴方，在直線上標記類型名稱區分關系類型。圖5 為直接標識法示例。

圖5 直接標識法示例

（2）分隔框標識法。該法在需求模型的基礎上，增加需求關系矩形框。關系矩形框有兩個屬性，關系類型的名稱和關系另一端元素的類型及名稱，可以是一個或者多個。

（3）插圖標識法。該法將注釋直接連接在需求矩形框上。關系表示與分隔框關系矩形框表示類似。

（4）關系矩陣。矩陣是系統工程中最為常用的記錄方式。SysML 建模語言沒有制定矩陣的明確標準格式。根據《SysML 精粹》一書提出的關系矩陣示例圖6 所示：行列舉關系提供方的類型和名稱，列列舉目標方的類型和名稱，相交的格子展示關系類型。除使用文字表述關系外還可以使用箭頭表示主被動關系，但箭頭形式的矩陣圖只能展示一種關系類型。

圖6 關系矩陣示例

（5）關系表格。關系表格，是將每一條關系列舉在表格中，一條關系占據一行。圖7 為關系表格示例。

圖7 關系表格示例

2.2 需求建模的前端實現

需求建模的前端實現，分為兩個部分：一是實現需求關系視圖，本系統選擇直接標識法；其二是實現關系矩陣。

2.2.1 需求關系視圖實現

根據上節的理論基礎，需求模型是一個矩形，矩形中除需求類型外還包括字段Id、Name、Text。本系統矩形使用開源可視化庫G6 卡片元素展示。G6 卡片中的元素屬于絕對定位，通過最外面矩形的位置來設置內部元素。通過G6 全局注冊節點，往節點中添加矩形框（rect）、文本框元素（text），并且設置元素的位置、樣式。最后通過graph.read()方法載入數據。

根據直接標識法的理論分析，需求關系視圖的組成除了上述的需求模型外還有需求關系。對于需求關系的可視化，關系圖本質是一個由主需求發散而成的網狀結構。G6 提供了一種緊湊樹的結構，其與網狀結構類似，但需要對節點和連線進行改造。節點改成需求模型的矩形，連線改成需求關系箭頭形式并在上面標示需求類型名稱。

注冊全局節點，使用G6.registerNode ()和G6.defaultEdge()，修改其中的傳參和設置連線箭頭類型、指向。節點修改偽代碼如代碼1 所示。最終需求關系視圖效果如圖8 所示。

代碼1 改造節點的關鍵偽代碼

圖8 需求關系視圖效果圖

至此實現基礎的需求關系視圖。但除展示需求關系外，無交互功能。本著滿足用戶高效需求管理、具有極強交互性的原則，提出增加新功能：（1）需求關系新增操作。新增對于前端展示只新增了新的需求模型和連線，因此可以在關系視圖上直接操作。（2）需求完整信息展示。為彌補直接標識法對需求信息展示不完整而設計。

功能拓展基于對需求模型的鼠標事件，發生交互。當鼠標移入需求模型時，關系變更菜單出現。用戶可選擇新建關系類型，新關系的提供方是當前需求，目標方是用戶選擇的需求。利用G6 中的node:mouseover()和node:mouseleave()方法監視鼠標移入移出。菜單彈窗是Element-UI 組件庫中的Dialog 對話框二次封裝成ContextMenu 組件。需求完整顯示功能如圖9 所示。

圖9 需求關系新增和詳情菜單圖

2.2.2 關系矩陣圖實現

需求關系矩陣是一個可參與需求追蹤、展示需求關系和能很好控制需求變更的管理工具。考慮到箭頭表示法能直觀表示關系方向以及一張關系圖代表了一個類型的關系能對相同類型的關系進行歸類。本系統選擇關系矩陣的箭頭表示法。另外，和關系視圖類似，包含關系可以直接在條目化的需求中進行操作。滿足關系和驗證關系并非是需求與需求間的關系，不需要在關系矩陣中實現。所以關系矩陣的重點聚焦在SysML 的追蹤、精化、派生這三個關系上。

關系矩陣圖由項目中的需求作為行列舉、列列舉進行垂直交叉，對于前端展示而言其本質是表格。表格表頭部分的行表頭和列表頭用于展示需求的名稱和類型，表格的中間部分就是需求關系展示。所以將表格的展示等效分為2 個部分，一個是表頭部分，一個是中間行列垂直交叉形成的格子部分。表頭部分簡單通過元素div 直接渲染即可生成。格子部分的較為復雜。圖10 為表格模型的組成結構。

圖10 表格模型的組成結構

若當前項目中的需求有N個，則交叉形成N2個格子。除去需求無法與自己產生需求關系，整個需求矩陣中最多可以形成的關系有N2-N個，對于前端展示出于便利將N2都顯示，只是至少N個格子沒有箭頭關系。若N2個格子都用div 元素表示，當N是極大數字時頁面對于DOM 元素的渲染時間將過于冗長，性能極差。考慮到這些問題，將N2個格子等效成由N條橫線、N條豎線垂直交叉形成的表格。元素個數從N2降低至2N。從視覺效果上等效形成了N2個格子。

在具體實現時，將每個格子的尺寸設置成30 px×30 px。轉換成線條，線條自身有1px 的寬度，則橫線間距為29 px，豎線同理。由于瀏覽器默認為文檔流布局方式，塊級元素獨占一行，無法實現豎線展示在一行。因此需修改豎線div 的display：inline-block。每條橫線、豎線實現的CSS 代碼，如代碼2 所示。

代碼2 橫線、豎線實現的CSS 代碼

箭頭放置在格子中，只需對有關系的格子進行渲染，渲染該格子的div。每條需求關系都要兩個格子展示，表示提供方指向目標方，因為行需求和列需求中都同時包括提供方和目標方。利用瀏覽器設置當前格子position：absolute 和計算出格子的位置數值（設置格子的top 和left）。箭頭格子的位置計算過程如下，假設a、b 有需求關系，a 是該項目的第3 條需求、b 是該項目的第5 條需求，則兩個箭頭格子的坐標分別為（60px，120px）和（120px，60px）。

為豐富矩陣圖功能，本系統提出對矩陣圖交互功能進行拓展，增加需求關系新增、修改、刪除功能：

（1）關系新增。點擊沒有需求箭頭的空白格子，假定坐標為（a，b），出現交互菜單，選擇新增關系選項。新增關系有兩種，其一是行需求作為提供方，列需求作為目標方，其二是列需求作為提供方，行需求作為目標方。選擇結束后當前的格子將出現關系箭頭，同時對應的關系箭頭出現在（b，a），兩者箭頭的方向不同。

（2）關系修改。點擊已存在需求關系的格子，選擇修改關系選項。當前的格子及對應的另一個格子將發生變化。

（3）關系刪除。點擊已存在關系的格子，選擇刪除選項。當前格子箭頭消失，對應的另一個格子也發生變化。

（4）功能拓展，可以分解成基于對鼠標的點擊事件的監聽和點擊位置格子坐標的計算。在計算出坐標后進行當前格子的選擇渲染，若格子本身有需求關系則已經渲染過無需二次渲染，若格子本身沒有需求關系即原來是空白則需要渲染當前格子的div 元素。鼠標點擊事件的坐標，通過點擊事件獲得鼠標事件的對象，該對象有clientX 和clientY[10]兩個屬性，表示當前鼠標坐標距可視區域左上邊的長度。另外瀏覽器提供了DOM 元素getBoundingClientRect()方法，使用該方法可以獲得這個圖層相對于瀏覽器可視區域的距離left 和top[11]。兩者的差值還需進行整除處理，處理的核心偽代碼，如代碼3 所示。所以最后格子的坐標就是（xIndex×30px，yIndex×30px）。

代碼3 格子坐標處理的偽代碼

在得到當前格子后，再在格子中進行功能拓展。最終矩陣圖交互功能拓展的效果如圖11 所示。

圖11 矩陣圖交互功能拓展效果圖

3 測 試

軟件測試是系統開發生命周期的重要組成部分，測試的主要目的是驗證系統功能的完整性、可用性，修改缺陷，提高系統的質量，增強用戶交互體驗度。本系統的前端需要進行的測試包括：兼容性測試、功能性測試、性能測試。本節將從系統運行環境和上述3 種類型的測試方面展開介紹。

3.1 系統運行環境

系統采用Vue,js 作為前端框架，使用打包工具如Webpack 進行處理構建。在終端運行npm run build，項目經過編譯打包后會生成文件，再將文件部署至服務器，于是系統就可以通過瀏覽器進行訪問。系統運行環境如表1 所示。

表1 系統運行環境

3.2 兼容性測試

系統是基于Web 環境所開發的需求管理工具，用戶使用的瀏覽器引擎內核存在不確定性，因此需要就各大瀏覽器的兼容性進行考慮。其結果如表2 所示。

表2 兼容性測試結果

3.3 功能性測試

功能測試，旨在對系統集成過程中和集成后所進行的系統功能進行測試。針對主要模塊的功能是否滿足系統管理的工作流程進行測試。

（1）需求開發的測試內容主要包括對需求新增的規范性驗證、新增之后需求展示的及時性測試。其結果如表3 所示。測試結果表明，需求開發模塊功能正常，達到了預期結果。

表3 需求開發的測試結果

（2）需求變更的測試涉及需求信息的修改以及需求變更后評審流程的跟進，其結果如表4 所示。測試編輯和評審結果表明，需求變更功能達到預期。

表4 需求變更的測試結果

（3）需求追蹤（圖形化需求建模）的測試，是為了驗證需求關系視圖、關系矩陣以及需求模型信息的準確性。由表5 的測試結果可見，需求追蹤功能測試符合要求。

表5 需求追蹤的信息準確性測試結果

（4）需求版本管理涉及需求評審和版本發布。評審已在需求變更中進行測試。此處測試版本發布，其結果如表6 所示。需求版本管理的測試結果符合版本管理流程，測試成功。

表6 需求版本管理的測試結果

3.4 性能測試

性能測試的目標之一是為了提高性能。測試需要判斷出哪些模塊執行得最多或者最耗費機器時間[12]。首屏加載時間指的是瀏覽器從響應URL后到首屏渲染結束所耗費的時間。首屏加載時間若是超過10 s 基本上用戶會終止執行。Chrome 開發者工具提供的Performance 面板可記錄頁面運行過程中各部分活動耗時并分析。由于關系矩陣中需求的數量會很大，因此會有大量的DOM元素需要頁面去渲染。所以本文針對需求數量較大的情況進行了性能測試。測試結果如圖12 所示。整個首屏的渲染時間為2.678 s，符合預期。

圖12 系統性能的測試結果

4 結 語

本文將普通的需求管理系統與基于模型的系統工程理論結合，通過迭代開發的模式，設計和實現了一個在Web 環境下可以進行需求追蹤建模和管理的系統。本系統在將需求條目化、層次化、結構化管理的同時，還可對需求間的關系進行可視化建模追蹤，大大提升了產品開發過程的效率，為用戶提供了直觀的需求關系及分析需求追蹤工具等，在復雜工程中有良好的應用前景。

本系統已經滿足基礎的需求管理功能要求，并且拓展了可視化需求關系的功能。但是對于需求管理功能的深度開發稍顯不足; 系統在多任務、多分工的項目中協同工作的管理能力較弱；關系矩陣圖部分，目前只涉及一張需求表內的需求關系展示，但在實際工程中，關系往往還會在跨項目、跨學科中發生，因此關系矩陣圖的展示范圍需要拓展，即從一張需求表拓展到多張需求表。