徐悅涵，錢(qián)祎凱，周晨初，劉玉生

（1.浙江大學(xué)CAD&CG 國(guó)家重點(diǎn)實(shí)驗(yàn)室，浙江 杭州 310058；2．上?？臻g推進(jìn)研究所，上海 201112；3．西安航天動(dòng)力研究所，陜西 西安 710100）

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

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

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

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

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

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

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

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

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

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

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

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

1.2 功能模塊設(shè)計(jì)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1.1 需求條目的表示

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

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

圖4 需求模型示例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 測(cè) 試

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

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

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

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

3.2 兼容性測(cè)試

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

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

3.3 功能性測(cè)試

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

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

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

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

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

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

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

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

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

3.4 性能測(cè)試

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

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

4 結(jié) 語(yǔ)

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

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