基于模型的需求建模與管理系統(tǒng)前端設(shè)計及實現(xiàn)

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

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

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

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

圖1 需求工程的結(jié)構(gòu)組成

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

為此，我們提出以基于模型的需求工程思想為基礎(chǔ)，重點探索基于模型的需求建模與管理系統(tǒng)前端設(shè)計方法，并探索基于Web 的圖形化需求建模與管理實現(xiàn)方法。

1 圖形化需求管理系統(tǒng)設(shè)計和實現(xiàn)

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

1.1 系統(tǒng)架構(gòu)設(shè)計

系統(tǒng)的架構(gòu)設(shè)計是系統(tǒng)成功實現(xiàn)的重要依據(jù)。主要過程包括設(shè)計系統(tǒng)的各個重要組件以及組件間通信，界定系統(tǒng)功能，規(guī)劃系統(tǒng)特征，規(guī)劃并設(shè)計實現(xiàn)各項指標(biāo)的方案，利用多學(xué)科、多維度構(gòu)建生成子系統(tǒng)。

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

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

圖2 整體架構(gòu)圖

1.2 功能模塊設(shè)計

根據(jù)需求管理系統(tǒng)流程分析，經(jīng)過細化、分類、整合后，最終可以分為基礎(chǔ)功能模塊及需求開發(fā)、追蹤、變更、版本管理等模塊。

基礎(chǔ)功能模塊是系統(tǒng)有序執(zhí)行和復(fù)雜功能實現(xiàn)的基礎(chǔ)，包括了個人模塊、基礎(chǔ)管理模塊、通知模塊。個人模塊主要涉及個人信息以及系統(tǒng)安全?；A(chǔ)管理模塊，負(fù)責(zé)管理系統(tǒng)用戶、單位、權(quán)限，系統(tǒng)預(yù)置功能自定義配置。通知模塊，記錄操作日志，發(fā)送變更通知。

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

1.3 功能模塊前端實現(xiàn)

基礎(chǔ)功能部分與常見系統(tǒng)前端實現(xiàn)方式基本一致，本文不進行闡述。本節(jié)主要剖析需求開發(fā)、變更、版本管理部分的前端實現(xiàn)。需求追蹤將在下一章進行詳細介紹。

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

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

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

圖3 處于評審狀態(tài)時的需求表

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

2 圖形化建模的前端設(shè)計與實現(xiàn)

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

2.1 圖形化需求建模的設(shè)計

標(biāo)準(zhǔn)系統(tǒng)建模語言SysML 是MBSE 的圖形化建模的關(guān)鍵與基礎(chǔ)，其中的需求圖（Requirement Diagram）是用來對需求進行圖形化展示的，其表示的需求間可追蹤性是需求分析后的產(chǎn)物。需求圖使得需求追蹤多了一種圖形化的實現(xiàn)方式。需求與需求之間的關(guān)系構(gòu)成需求圖。需求圖建模包括對需求和需求間關(guān)系實現(xiàn)圖形化。

2.1.1 需求條目的表示

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

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

圖4 需求模型示例

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

2.1.2 需求關(guān)系的表示

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

根據(jù)SysML 需求關(guān)系展示方法，需求關(guān)系可使用關(guān)系標(biāo)識法展示。關(guān)系標(biāo)識法包括：直接標(biāo)識法、分隔框標(biāo)識法、插圖標(biāo)識法、關(guān)系矩陣、關(guān)系表格。

（1）直接標(biāo)識法。直接標(biāo)識法是最基礎(chǔ)的表示方法，是依賴關(guān)系表示法。箭頭端是提供方，直線末端是依賴方，在直線上標(biāo)記類型名稱區(qū)分關(guān)系類型。圖5 為直接標(biāo)識法示例。

圖5 直接標(biāo)識法示例

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

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

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

圖6 關(guān)系矩陣示例

（5）關(guān)系表格。關(guān)系表格，是將每一條關(guān)系列舉在表格中，一條關(guān)系占據(jù)一行。圖7 為關(guān)系表格示例。

圖7 關(guān)系表格示例

2.2 需求建模的前端實現(xiàn)

需求建模的前端實現(xiàn)，分為兩個部分：一是實現(xiàn)需求關(guān)系視圖，本系統(tǒng)選擇直接標(biāo)識法；其二是實現(xiàn)關(guān)系矩陣。

2.2.1 需求關(guān)系視圖實現(xiàn)

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

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

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

代碼1 改造節(jié)點的關(guān)鍵偽代碼

圖8 需求關(guān)系視圖效果圖

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

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

圖9 需求關(guān)系新增和詳情菜單圖

2.2.2 關(guān)系矩陣圖實現(xiàn)

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

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

圖10 表格模型的組成結(jié)構(gòu)

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

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

代碼2 橫線、豎線實現(xiàn)的CSS 代碼

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

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

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

（2）關(guān)系修改。點擊已存在需求關(guān)系的格子，選擇修改關(guān)系選項。當(dāng)前的格子及對應(yīng)的另一個格子將發(fā)生變化。

（3）關(guān)系刪除。點擊已存在關(guān)系的格子，選擇刪除選項。當(dāng)前格子箭頭消失，對應(yīng)的另一個格子也發(fā)生變化。

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

代碼3 格子坐標(biāo)處理的偽代碼

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

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

3 測 試

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

3.1 系統(tǒng)運行環(huán)境

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

表1 系統(tǒng)運行環(huán)境

3.2 兼容性測試

系統(tǒng)是基于Web 環(huán)境所開發(fā)的需求管理工具，用戶使用的瀏覽器引擎內(nèi)核存在不確定性，因此需要就各大瀏覽器的兼容性進行考慮。其結(jié)果如表2 所示。

表2 兼容性測試結(jié)果

3.3 功能性測試

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

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

表3 需求開發(fā)的測試結(jié)果

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

表4 需求變更的測試結(jié)果

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

表5 需求追蹤的信息準(zhǔn)確性測試結(jié)果

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

表6 需求版本管理的測試結(jié)果

3.4 性能測試

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

圖12 系統(tǒng)性能的測試結(jié)果

4 結(jié) 語

本文將普通的需求管理系統(tǒng)與基于模型的系統(tǒng)工程理論結(jié)合，通過迭代開發(fā)的模式，設(shè)計和實現(xiàn)了一個在Web 環(huán)境下可以進行需求追蹤建模和管理的系統(tǒng)。本系統(tǒng)在將需求條目化、層次化、結(jié)構(gòu)化管理的同時，還可對需求間的關(guān)系進行可視化建模追蹤，大大提升了產(chǎn)品開發(fā)過程的效率，為用戶提供了直觀的需求關(guān)系及分析需求追蹤工具等，在復(fù)雜工程中有良好的應(yīng)用前景。

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