軟件需求管理思考

尹治華

摘 要：針對(duì)需求評(píng)審過程中存在的不容易記錄和跟蹤評(píng)審問題、需求的變更申請(qǐng)不能很好與需求條款相對(duì)應(yīng)問題、需求管理工具中管理的需求文檔不能直接進(jìn)入軟件配置管理系統(tǒng)導(dǎo)致需求文檔的源頭不唯一問題以及通過手工方式進(jìn)行需求追蹤的問題等，考慮到需求管理活動(dòng)包含的需求變更管理與版本控制屬于軟件配置管理需要控制的核心要素，從理論上將需求管理與軟件配置管理有機(jī)融合，以兩者融合解決需求管理過程中存在的問題為出發(fā)點(diǎn)，在此基礎(chǔ)上提出了一種新的需求管理模式，并將該模式通過嵌入式軟件產(chǎn)品平臺(tái)來實(shí)現(xiàn)，以有效解決需求管理過程中存在的問題。

關(guān)鍵詞：需求管理；需求評(píng)審；需求變更；版本控制；需求跟蹤

0 引言

Standish Group從1994年到2001年的CHAOS Reports證實(shí)導(dǎo)致項(xiàng)目失敗的最多的原因就是“變更用戶需求”[1]。因此避免失敗和提高項(xiàng)目的成功率需要進(jìn)行需求管理。

目前對(duì)需求進(jìn)行管理主要是使用IBM Rational RequisitePro、IBM Rational Doors等工具或使用excel進(jìn)行人工管理， 但對(duì)需求的變更管理和版本管理往往借助第三方工具（如IBM Rational ClearCase、IBM Rational ClearQuest），不能在同一個(gè)平臺(tái)中對(duì)需求進(jìn)行有效管理，導(dǎo)致相關(guān)技術(shù)文檔的源頭不唯一，需求追溯性變差，同時(shí)增加了管理成本。

1 需求管理過程概述

需求管理的主要活動(dòng)包括需求確認(rèn)（主要由用戶和項(xiàng)目組共同對(duì)軟件研制任務(wù)書和需求規(guī)格說明進(jìn)行評(píng)審）、需求變更（包括需求更改和版本控制）和需求跟蹤控制。

2 需求管理存在的問題

2.1 需求評(píng)審的問題

當(dāng)前對(duì)需求的評(píng)審一般都是基于文檔化的文件進(jìn)行評(píng)審，評(píng)審的時(shí)候不容易記錄問題對(duì)應(yīng)的需求項(xiàng)，問題的提出人等信息。這帶來的問題為：給手工記錄帶來了很大的壓力；評(píng)審結(jié)束之后，很多問題不知下文；不能充分統(tǒng)計(jì)需求評(píng)審問題以便跟蹤問題并作為組織改進(jìn)的依據(jù)。

2.2 需求變更控制問題

當(dāng)基于問題、客戶新需求等對(duì)需求進(jìn)行變更時(shí)，目前國(guó)內(nèi)相關(guān)單位基本上都參考[2]提交更改申請(qǐng)，但更改申請(qǐng)往往是紙質(zhì)的或是基于變更管理系統(tǒng)的，沒有與需求管理工具進(jìn)行集成（IBM Rational Doors除外），且對(duì)需求變更的描述一般比較粗，不能有效記錄需求變更歷史（如需求項(xiàng)、問題提交人、需求修改時(shí)間等信息）。

2.3 需求版本控制問題

目前業(yè)界內(nèi)相關(guān)商業(yè)需求管理工具[3]（如IBM Rational Doors等）基本不具備或不能與版本管理工具進(jìn)行集成，從而使得相關(guān)技術(shù)文檔不能直接進(jìn)入版本管理系統(tǒng)中，使得技術(shù)文檔管理源頭不唯一，可能導(dǎo)致各個(gè)系統(tǒng)中軟件技術(shù)狀態(tài)不唯一，增加了管理的難度。

2.4 需求跟蹤問題

目前業(yè)界內(nèi)很多相關(guān)單位通過手工方式使用excel進(jìn)行需求追蹤管理，導(dǎo)致需要額外存儲(chǔ)需求跟蹤矩陣，且記錄不方便。 3 解決問題的方法

因此，需求管理的理想模式（見附圖）是：在需求評(píng)審的過程中能夠通過一個(gè)工具自動(dòng)記錄需求評(píng)審的問題，自動(dòng)記錄需求變更的歷史并做好需求追蹤、在時(shí)機(jī)成熟時(shí)將需求文檔提交到開發(fā)庫、受控庫或產(chǎn)品庫。為了實(shí)現(xiàn)該模式，在嵌入式軟件產(chǎn)品平臺(tái)中借助配置管理手段輔助需求管理，確保需求的變更控制、版本管理與配置管理融合的同時(shí)，解決2.1、2.2、2.3、2.4的問題。

3.1 有效的評(píng)審

針對(duì)2.1中存在的不能有效記錄評(píng)審人、評(píng)審問題、問題落實(shí)情況、問題對(duì)應(yīng)的需求項(xiàng)、分析統(tǒng)計(jì)問題等問題，在軟件需求管理的過程中，相關(guān)人員在嵌入式軟件產(chǎn)品平臺(tái)上按附圖對(duì)需求管理范疇內(nèi)所有文檔（軟件研制任務(wù)書、需求規(guī)格說明、軟件設(shè)計(jì)說明、軟件代碼、單元測(cè)試用例、部件測(cè)試用例、配置項(xiàng)/系統(tǒng)測(cè)試用例）進(jìn)行項(xiàng)目級(jí)評(píng)審，對(duì)軟件研制任務(wù)書、需求規(guī)格說明、配置項(xiàng)/系統(tǒng)級(jí)測(cè)試用例及項(xiàng)目級(jí)評(píng)審達(dá)不成一致意見的問題進(jìn)行院級(jí)評(píng)審。在需求評(píng)審的過程中設(shè)置一名精通軟件工程過程改進(jìn)并從事過軟件研發(fā)與管理的人員擔(dān)任項(xiàng)目管理秘書，負(fù)責(zé)跟蹤、協(xié)調(diào)評(píng)審過程中問題，并從評(píng)審問題中提煉相關(guān)內(nèi)容納入到組織的評(píng)審檢查單中。

首先進(jìn)行項(xiàng)目級(jí)評(píng)審。軟件研制任務(wù)書、軟件需求規(guī)格說明等需求文檔（一個(gè)需求文檔包含若干個(gè)需求項(xiàng)）的編制人首先按照[4]格式要求在嵌入式軟件產(chǎn)品平臺(tái)中進(jìn)行需求定義（需求定義內(nèi)容主要包括需求項(xiàng)名稱、需求項(xiàng)內(nèi)容），然后提交需求定義內(nèi)容，使其轉(zhuǎn)換為需求項(xiàng)列表（需求項(xiàng)列表主要內(nèi)容包括每一個(gè)需求項(xiàng)唯一編號(hào)、需求項(xiàng)名稱、需求項(xiàng)內(nèi)容、版本（初始版本為1）、審查列表等信息）在評(píng)審人員的審查界面中顯示。評(píng)審人員參考組織的評(píng)審檢查單在審查列表中填寫評(píng)審問題，并給出評(píng)審結(jié)論（通過或不通過）。對(duì)每一需求項(xiàng)，如果有一個(gè)人的結(jié)論為不通過，則該需求項(xiàng)評(píng)審的結(jié)論為不通過（其中初始結(jié)論為待審狀態(tài)），否則為通過。對(duì)于不通過的需求項(xiàng)，如果編制人接受修改意見，則修改完成之后，所有評(píng)審人員對(duì)修改的需求項(xiàng)重新進(jìn)行項(xiàng)目級(jí)評(píng)審直至問題關(guān)閉。對(duì)于編制人和評(píng)審人員達(dá)不成一致意見的需求項(xiàng)，則由項(xiàng)目管理秘書提交院級(jí)評(píng)審進(jìn)行決策。

院級(jí)評(píng)審時(shí)機(jī)為項(xiàng)目級(jí)評(píng)審結(jié)束（包含項(xiàng)目級(jí)評(píng)審?fù)ㄟ^、項(xiàng)目級(jí)評(píng)審未通過但需要項(xiàng)目管理秘書提交院級(jí)評(píng)審進(jìn)行決策）之后，對(duì)屬于院級(jí)評(píng)審范疇內(nèi)的內(nèi)容進(jìn)行評(píng)審。如果院級(jí)評(píng)審不通過，則按圖1反饋問題給修改人進(jìn)行修改，然后重新進(jìn)行項(xiàng)目級(jí)評(píng)審和院級(jí)評(píng)審，直到通過。與項(xiàng)目級(jí)評(píng)審相比，院級(jí)評(píng)審需要院級(jí)型號(hào)副總師和用戶參與評(píng)審。

在評(píng)審的過程中，通過在嵌入式軟件產(chǎn)品平臺(tái)中進(jìn)行問題記錄和跟蹤，確保了被評(píng)需求文檔的質(zhì)量，并有利于組織過程改進(jìn)。

3.2 需求與變更、版本緊密關(guān)聯(lián)

對(duì)2.2、2.3中存在的需求管理與變更管理、版本管理分離的問題，相關(guān)人員在嵌入式軟件產(chǎn)品平臺(tái)中按圖1對(duì)需求的變更與版本控制采取以下處理方式：

（1）對(duì)于提交項(xiàng)目級(jí)評(píng)審之前的需求項(xiàng)，文檔編制人員在嵌入式軟件產(chǎn)品平臺(tái)中可以任意對(duì)需求進(jìn)行修改，且不形成需求項(xiàng)版本；

（2）對(duì)于已提交項(xiàng)目級(jí)評(píng)審，未進(jìn)行院級(jí)評(píng)審的需求項(xiàng)，文檔編制人員可以對(duì)需求項(xiàng)進(jìn)行修改，但每修改1次都會(huì)記錄修改前后的狀態(tài)，且當(dāng)前需求項(xiàng)版本在原有版本上加1（如只修改了1次的需求項(xiàng)版本為2）。當(dāng)所有的需求項(xiàng)都通過項(xiàng)目級(jí)評(píng)審之后（即需求文檔具備提交開發(fā)庫條件），需求文檔編制人在嵌入式軟件產(chǎn)品平臺(tái)中提交入開發(fā)庫申請(qǐng)，開發(fā)庫配置管理員依據(jù)配置管理規(guī)定在嵌入式軟件產(chǎn)品平臺(tái)中對(duì)需求文檔給出開發(fā)庫配置標(biāo)識(shí)（以便凍結(jié)狀態(tài)，供軟件測(cè)試人員進(jìn)行單元測(cè)試、部件測(cè)試等）；

（3）對(duì)于項(xiàng)目級(jí)評(píng)審結(jié)束（包含項(xiàng)目級(jí)評(píng)審?fù)ㄟ^、項(xiàng)目級(jí)評(píng)審未通過但需要項(xiàng)目管理秘書提交院級(jí)評(píng)審進(jìn)行決策）之后提交院級(jí)評(píng)審的需求文檔，如果院級(jí)評(píng)審不通過，則文檔編制人員修改需求項(xiàng)，系統(tǒng)自動(dòng)記錄需求項(xiàng)修改歷史；如果院級(jí)評(píng)審?fù)ㄟ^（即需求文檔具備提交受控庫條件），需求文檔編制人在嵌入式軟件產(chǎn)品平臺(tái)中提交入受控庫申請(qǐng)，受控庫配置管理員依據(jù)配置管理規(guī)定在嵌入式軟件產(chǎn)品平臺(tái)中對(duì)需求文檔給出受控庫配置標(biāo)識(shí)（以便凍結(jié)狀態(tài)，供測(cè)試人員開展配置項(xiàng)/系統(tǒng)測(cè)試等）；

（4）當(dāng)需求文檔入受控庫或產(chǎn)品庫之后，如果需求需要變更（含測(cè)試發(fā)現(xiàn)問題等原因需要更改的非新增需求，新增需求等），則文檔編制人員必須提交需求變更申請(qǐng)并選擇需要修改的需求項(xiàng)（說明更改原因、進(jìn)行影響域分析等），并通過型號(hào)副總師審批之后，需要修改的需求項(xiàng)才處于可修改（對(duì)于非新增需求）或可評(píng)審（新增需求）狀態(tài)。然后相關(guān)人員重新進(jìn)行需求修改、進(jìn)行項(xiàng)目級(jí)評(píng)審、提交開發(fā)庫、進(jìn)行院級(jí)評(píng)審、提交受控庫、提交產(chǎn)品庫操作等。

在需求的變更與版本控制的過程中，通過在嵌入式軟件產(chǎn)品平臺(tái)中融合需求管理與配置管理，解決了需求變更歷史不能有效記錄，需求文檔不能直接進(jìn)入軟件版本管理系統(tǒng)導(dǎo)致源頭不唯一可能產(chǎn)生的技術(shù)狀態(tài)不唯一的問題。

3.3 基于平臺(tái)的需求跟蹤

對(duì)2.4中存在的用excel進(jìn)行需求跟蹤不利于記錄的維護(hù)和存儲(chǔ)的問題，通過在嵌入式軟件產(chǎn)品平臺(tái)中設(shè)置需求追蹤功能，相關(guān)文檔編制人只需在下游的需求項(xiàng)列表中選擇上游的需求項(xiàng)并進(jìn)行關(guān)聯(lián)，系統(tǒng)自動(dòng)建立任務(wù)書-需求規(guī)格說明-設(shè)計(jì)說明-代碼-測(cè)試用例之間的需求跟蹤矩陣并可隨時(shí)查詢。通過此方式解決了使用excel等進(jìn)行追蹤不方便管理的問題。

4 結(jié)語

本文針對(duì)業(yè)界內(nèi)需求評(píng)審、需求的變更與版本控制等過程中存在的問題，從理論上將需求管理與軟件配置管理（包括軟件變更管理和配置管理）有機(jī)融合，并在此基礎(chǔ)上創(chuàng)新性提出了一種新的需求管理模式，并將該模式通過工具來實(shí)現(xiàn)，確保了需求能夠有效評(píng)審與跟蹤，需求的變更和版本管理能夠與軟件配置管理業(yè)務(wù)有效融合， 使得企業(yè)能夠高效進(jìn)行需求管理，從而保證了軟件產(chǎn)品的質(zhì)量，并減少了管理成本。

參考文獻(xiàn)：

[1]需求管理： IBM Rational 技術(shù)白皮書 [EB/OL]. [2004-08-01].http：//www.ibm.com/developerworks/cn/rational/r-rm/index.html.

[2]中國(guó)人民解放軍總裝備部. GJB 5235-2004， 軍用軟件配置管理[S]. 北京：總裝備部軍標(biāo)出版發(fā)行部，2004.

[3]國(guó)內(nèi)外需求管理工具比較 [R/OL]. [2014-07-11].http：//download.csdn.net/detail/kingr2014/7620925.

[4]中國(guó)人民解放軍總裝備部. GJB 438B-2009 軍用軟件開發(fā)文檔通用要求[S].北京：總裝備部軍標(biāo)出版發(fā)行部，2009.