張 昱

(中國科學(xué)院空天信息創(chuàng)新研究院 北京 100190)

0 引 言

需求來源于用戶。用戶包括系統(tǒng)/軟件的使用人員和將系統(tǒng)需求分解為軟件需求的系統(tǒng)總體人員。本文中的“用戶需求”泛指上述兩類用戶對軟件研發(fā)項目組提出的軟件需求。用戶需求是軟件研發(fā)工作的輸入,也是驗收軟件研發(fā)成果的依據(jù)。軟件研發(fā)的最終目的是交付與用戶需求一致的工作產(chǎn)品。為了確保最終工作產(chǎn)品與用戶需求一致,中間工作產(chǎn)品以及過程活動也要與用戶需求一致。按計劃交付了與用戶需求一致的工作產(chǎn)品,意味著成功地完成了研發(fā)工作。如果工作產(chǎn)品與用戶需求出現(xiàn)了不一致,那么一定會降低用戶的滿意度,影響用戶和管理人員對項目的評價。工作產(chǎn)品與用戶需求的一致性程度,是評價項目成效的重要指標(biāo)。

如下兩個主要原因?qū)е鹿こ袒顒雍凸ぷ鳟a(chǎn)品偏離用戶需求:第一,用戶需求源于期望和愿景。隨著工作開展,用戶對需求的認(rèn)識也在不斷地深入和細(xì)化。軟件研制方如果不能適應(yīng)和管理用戶需求的變化,工作就會逐漸偏離用戶的需求。第二,在需求分析、軟件設(shè)計、編碼、測試等多個概念轉(zhuǎn)換及衍生產(chǎn)品的形成過程中,軟件研發(fā)人員對用戶需求的理解和再理解可能出現(xiàn)偏差,工作產(chǎn)品之間可能出現(xiàn)不一致,這些理解偏差和不一致很容易累積起來,影響相關(guān)和后續(xù)的工作產(chǎn)品,導(dǎo)致交付的工作產(chǎn)品與用戶需求不一致。

軟件工程引入了需求開發(fā)和需求管理的概念。前者關(guān)注需求建立的過程;后者管理需求開發(fā)形成的工作產(chǎn)品,確保研發(fā)人員始終在理解和承諾用戶需求的基礎(chǔ)上產(chǎn)出與用戶需求一致的工作產(chǎn)品。有時,將需求開發(fā)和需求管理統(tǒng)稱為需求工程。本文側(cè)重研究需求管理。

1 需求管理的目的

GJB5000A-2008《軍用軟件研制能力成熟度模型》提出,需求管理的目的是“管理項目的產(chǎn)品和產(chǎn)品部件的需求,并標(biāo)識這些需求與項目的計劃和工作產(chǎn)品之間的不一致性”。CMMI 1.3提出,需求管理的目的是“管理項目產(chǎn)品及產(chǎn)品組件的需求,并使需求與項目計劃及工作產(chǎn)品之間保持一致”。

總之,需求管理的目的是通過一組工程實踐確保需求的一致性。需求一致性包括三個內(nèi)容:用戶需求和用戶需求之間一致;最終工作產(chǎn)品、中間工作產(chǎn)品與用戶需求一致;工程活動保障上述一致性的達(dá)成。其中,第1條主要由需求開發(fā)相關(guān)活動實現(xiàn),第2條和第3條主要由需求管理相關(guān)活動實現(xiàn)。

從理解用戶需要到交付最終軟件產(chǎn)品,通常經(jīng)歷了需求分析、軟件設(shè)計、編碼和測試等軟件研發(fā)階段,每個階段都產(chǎn)生了不同的概念模型和工作產(chǎn)品。用戶需求使用文字和圖表記錄,軟件設(shè)計使用模型和算法表達(dá),軟件代碼是一系列計算機(jī)語言描述的運行邏輯,軟件代碼被編譯為可執(zhí)行程序。通常,可執(zhí)行文件和配套文檔是最終軟件產(chǎn)品。在軟件研發(fā)過程中,確保每個人對概念模型的理解一致,各種概念模型和衍生工作產(chǎn)品不偏離用戶需求,是軟件研發(fā)人員期待達(dá)成卻又困難重重的事情。需求管理希望通過一組工程實踐,達(dá)成各種概念的理解一致、各種中間工作產(chǎn)品和最終工作產(chǎn)品一致,并且所有一致都基于用戶需求。

2 需求管理的工程活動

通過理解和承諾需求、建立需求追蹤關(guān)系、發(fā)現(xiàn)和解決不一致、管理需求變更四組工程活動達(dá)成需求管理的一致性管理目標(biāo)。

2.1 理解和承諾需求是需求一致性管理的前提

規(guī)范需求提供渠道、建立需求溝通機(jī)制、明確需求接收準(zhǔn)則和做出需求實現(xiàn)承諾是理解和承諾需求的主要活動內(nèi)容。

1) 規(guī)范需求提供渠道。通常由用戶方指定有效的需求提供者,從而建立規(guī)范的需求提供渠道。狹義的需求提供者是用戶方指定的用戶代表。廣義的需求提供者還可以是一個由用戶、同行專家和研制方代表組成的聯(lián)合工作組,也可以是一個定期召開的需求研討會。無論采用哪種形式,目的都是規(guī)范化用戶需求的提供渠道,從這一渠道提出正式的用戶需求。需求提供渠道應(yīng)在用戶方和研制方達(dá)成共識后,寫入項目計劃書或其他有效力的文件中。

2) 建立需求溝通機(jī)制。項目組相關(guān)人員與需求提供者建立常態(tài)化的溝通交流機(jī)制,共同理解需求。項目組的技術(shù)負(fù)責(zé)人、測試負(fù)責(zé)人和主要管理人員充分理解需求自不待言,用戶方的需求提供者也有必要在溝通交流中不斷加深對需求的理解,從而將“需要”轉(zhuǎn)變成清晰、合理的需求。溝通交流需求的主要形式是會議,當(dāng)然也可以是郵件、訪談等其他形式。研制方應(yīng)盡量使非正式的溝通內(nèi)容得到需求提供者的正式認(rèn)可,并保存和管理所有溝通記錄。

3) 明確需求接收準(zhǔn)則。需求提供者的出發(fā)點往往是用戶方的“需要”,還要經(jīng)過充分的分析和思考才能形成用戶需求。在用戶需求的形成過程中,研制方的觀點十分重要,因為研制方關(guān)注用戶需求的實現(xiàn)可行性、實現(xiàn)成本、驗證可行性和內(nèi)容一致性等要素,而這些要素恰恰是高質(zhì)量需求不可或缺的特征,也是后期需求一致性管理的前提保障。研制方應(yīng)將需求的接受準(zhǔn)則明確下來,并按照準(zhǔn)則討論和接受需求。研制方可以將疑似不滿足準(zhǔn)則但暫時無法拒絕的需求標(biāo)識出來,納入風(fēng)險管理。

4) 做出需求實現(xiàn)承諾。項目組成員在充分理解用戶需求的基礎(chǔ)上承諾其可實現(xiàn),從而建立并鞏固用戶方和研制方管理人員對實現(xiàn)需求的信心。承諾用戶需求的形式通常有兩個:研制方領(lǐng)導(dǎo)或項目組主要成員參與用戶需求評審會,在會議上做出正式承諾;在項目組會議上討論并承諾用戶需求。廣義的需求承諾是在項目研制過程中,始終確保所有工程活動都圍繞著實現(xiàn)用戶需求這一目標(biāo)開展、所有工作產(chǎn)品都與用戶需求保持一致,這是用戶和研發(fā)管理者最想得到的一條承諾。

2.2 建立需求追蹤關(guān)系是需求一致性管理的主要手段

如何在理解和承諾用戶需求的基礎(chǔ)上,通過管理手段保障需求分析、軟件設(shè)計、代碼、測試用例、計劃與用戶需求的一致性呢?業(yè)界的普遍做法是以工作產(chǎn)品和用戶需求之間的追蹤關(guān)系為手段。追蹤關(guān)系的建立可以使用軟件工具,也可使用電子表格,兩者的原理是一樣的。

一致是一種自洽和協(xié)調(diào)的關(guān)系,是矛盾的反面。如果工作產(chǎn)品與用戶需求一致,則一定具有可追蹤關(guān)系,反之則不成立。通過需求追蹤關(guān)系管理需求一致性的基本方法是:

1) 在工作產(chǎn)品與用戶需求之間建立追蹤關(guān)系,無法建立追蹤關(guān)系的條目一定不具有一致性。

2) 以追蹤關(guān)系為線索,進(jìn)一步識別關(guān)聯(lián)條目之間的不一致。

3) 標(biāo)識并糾正不一致。

需求追蹤關(guān)系的表示方法可以是需求跟蹤圖、超鏈接,甚至文檔注釋,最常見的方法是需求跟蹤矩陣。簡單的需求跟蹤矩陣是一張二維表,列是用戶需求、依賴用戶需求、軟件需求分析、軟件設(shè)計、代碼、測試用例和任務(wù)計劃的編號,行是被追蹤的用戶需求條目。如果每行用戶需求都能分別對應(yīng)至少一條軟件需求分析、軟件設(shè)計、代碼、測試用例和任務(wù)計劃的編號,那么需求跟蹤矩陣滿足了縱向追蹤關(guān)系;如果標(biāo)識了用戶需求和依賴用戶需求之間的關(guān)聯(lián)關(guān)系,那么需求跟蹤矩陣滿足了橫向追蹤關(guān)系。當(dāng)存在較多的“一對多”或“多對多”的追蹤關(guān)系時,這種簡單的二維需求跟蹤矩陣就難以維護(hù)和檢索了。此時可以把簡單需求跟蹤矩陣的一張二維表拆分成多張二維表,即拆分成:用戶需求依賴關(guān)系跟蹤關(guān)系表、用戶需求-軟件需求分析跟蹤關(guān)系表、軟件需求分析-軟件設(shè)計跟蹤關(guān)系表、軟件設(shè)計-代碼跟蹤關(guān)系表、代碼-單元測試跟蹤關(guān)系表、軟件設(shè)計-集成測試跟蹤關(guān)系表、軟件需求分析-出所/出廠測試跟蹤關(guān)系表、用戶需求-驗收測試跟蹤關(guān)系表等,每張二維表的行和列分別是被追蹤元素和依賴元素,每個單元格可以寫入依賴/被依賴的雙向追蹤關(guān)系。使用一張二維表建立追蹤關(guān)系的方法也稱單矩陣追蹤,使用多張二維表建立追蹤關(guān)系的方法也稱多矩陣追蹤。

解釋幾個關(guān)于需求跟蹤矩陣的常見問題:

1) 在需求跟蹤矩陣中,對用戶需求和工作產(chǎn)品的內(nèi)容要分解到什么粒度?泛泛而談,分解到辨識度高、追蹤效果好的粒度就可以了。如果進(jìn)一步追求管理的績效,那么至少要把關(guān)鍵、易變的需求重點管理起來。關(guān)鍵的需求是影響用戶目標(biāo)達(dá)成的高優(yōu)先級需求,易變的需求是預(yù)計可能出現(xiàn)變更的需求。

2) 需求跟蹤矩陣的作用是什么?需求跟蹤矩陣管理橫向和縱向追蹤關(guān)系?？v向追蹤是用戶需求與需求分析、軟件設(shè)計、代碼、測試用例等工作產(chǎn)品及計劃之間的追蹤關(guān)系;橫向追蹤是用戶需求和用戶需求之間的關(guān)聯(lián)關(guān)系?？v向追蹤可以發(fā)現(xiàn)工作產(chǎn)品是否覆蓋了全部用戶需求,以及幫助識別是否存在不一致。橫向追蹤可以在需求發(fā)生變更時,與縱向追蹤關(guān)系一起評估需求變更的影響范圍。此外,還可以通過需求追蹤關(guān)系識別復(fù)用程度高的需求和模塊,并在項目監(jiān)控時通過需求的狀態(tài)掌握項目進(jìn)展。

3) 橫向追蹤是不是必須的?縱向追蹤關(guān)系是需求一致性的必要條件,橫向追蹤關(guān)系既不是需求一致性的充分條件,也不是必要條件。業(yè)界對需求縱向追蹤的必要性是毫無異議的,對橫向追蹤的必要性則有不同意見。筆者認(rèn)為,是否有必要進(jìn)行橫向追蹤,要看需求橫向追蹤的作用——橫向追蹤關(guān)系主要用于需求變更時評估變更的影響范圍。如果研發(fā)人員在需求分析時充分分析了需求之間的接口關(guān)系并記錄在需求分析文檔中,那么即使沒有在需求跟蹤矩陣中進(jìn)行橫向追蹤,也不會妨礙需求變更時的影響分析。

4) 什么時候更新需求跟蹤矩陣?一種觀點是在策劃、需求分析、軟件設(shè)計、編碼、測試等活動完成時更新需求跟蹤矩陣,另一種觀點是隨時更新需求跟蹤矩陣。筆者建議項目管理人員、需求分析人員、軟件設(shè)計人員、軟件實現(xiàn)人員、軟件測試人員根據(jù)工作進(jìn)展及時更新需求跟蹤矩陣,在相關(guān)工作產(chǎn)品評審時一并評審需求跟蹤矩陣。

5) 使用單矩陣追蹤還是多矩陣追蹤?筆者建議使用多矩陣追蹤。通常,多條測試用例對應(yīng)一個功能模塊,一條用戶需求被分解為多個設(shè)計和實現(xiàn)模塊。需求跟蹤矩陣顯然是多對多的關(guān)系,對于多對多的關(guān)系應(yīng)使用多矩陣追蹤。此外,只有多矩陣追蹤才能真正實現(xiàn)正向和反向的雙向追蹤。

2.3 發(fā)現(xiàn)和解決不一致是需求一致性管理的重點

需求管理以理解和承諾為前提,以建立追蹤關(guān)系為主要手段,目的是發(fā)現(xiàn)和解決需求不一致,從而確保工作產(chǎn)品和活動始終不偏離用戶需求。

1) 發(fā)現(xiàn)需求不一致。發(fā)現(xiàn)不一致不僅要建立需求追蹤關(guān)系,還要主動基于追蹤關(guān)系進(jìn)行識別和判斷。發(fā)現(xiàn)不一致并不局限在需求追蹤關(guān)系建立和維護(hù)時,還應(yīng)該在平時、例會、評審活動時注意捕捉需求不一致的各種跡象。不一致的表現(xiàn)主要包括:矛盾、不完整、冗余、不可追蹤。針對不同工作產(chǎn)品又有不同的表現(xiàn)特點:

(1) 軟件需求分析和用戶需求之間的不一致主要出現(xiàn)在理解和表達(dá)上,表現(xiàn)為軟件需求分析文檔沒有完整地描述用戶需求或者描述有歧義。

(2) 軟件設(shè)計和軟件需求分析之間不一致的情形主要表現(xiàn)為功能需求過度設(shè)計、技術(shù)方案不合理、接口設(shè)計不完備、非功能需求設(shè)計不充分等。軟件設(shè)計與軟件需求分析之間的不一致情形較多,也較難發(fā)現(xiàn),需要引起特別的重視。

(3) 軟件代碼和軟件設(shè)計之間的不一致通常要延遲到測試階段才能被發(fā)現(xiàn)。但是,如果測試用例的設(shè)計工作和需求分析、軟件設(shè)計同步開展,那么編碼人員憑借對測試用例的了解,可能主動規(guī)避一些不一致的問題。

(4) 不同級別的測試用例與軟件需求分析、軟件設(shè)計、代碼的不一致主要表現(xiàn)為未按運行場景組織測試、測試用例的覆蓋性和有效性不足等。測試人員對需求的理解程度會影響測試的有效性。很多組織要求測試人員積極參與需求溝通和理解,同時鼓勵用戶代表參與測試設(shè)計和測試活動,采取這些措施的目的是“加固”需求一致性管理的最后一道防線,在測試階段盡量多地發(fā)現(xiàn)需求不一致這類深層次的問題。

2) 解決需求不一致。項目管理人員應(yīng)該認(rèn)識到,所有涉及“需求不一致”的問題都是影響產(chǎn)品交付和項目成敗的嚴(yán)重問題。個人、小組、質(zhì)量保證人員、用戶代表、同行專家在任何場合發(fā)現(xiàn)的需求不一致都應(yīng)轉(zhuǎn)成問題,由軟件項目負(fù)責(zé)人組織解決,由質(zhì)量保證人員監(jiān)督解決。不一致的解決策略有三種:

(1) 變更工作產(chǎn)品或計劃。

(2) 變更用戶需求。

(3) 在用戶、利益相關(guān)方知悉和認(rèn)可的前提下,暫時擱置不一致。

2.4 管理需求變更是需求一致性管理的難點

在研制的整個生命周期——包括運行維護(hù)階段——都可能發(fā)生需求變更。隨著研制工作的深入開展,用戶方和研制方都可能在概念上“重塑”早期形成的需求。經(jīng)驗表明,在需求發(fā)生變更時,更容易出現(xiàn)不一致的情形。這些不一致情形發(fā)生的原因,除了工程水平之外,主要是需求管理的變更影響分析出現(xiàn)了問題。

從配置管理的角度看,需求變更是納入功能基線后的變更。功能基線形成后,工程活動繼續(xù)推進(jìn),需求變更不僅影響到相關(guān)需求的變更,而且涉及到后續(xù)相關(guān)工作產(chǎn)品的變更。因此,評估需求變更的影響范圍,既要橫向評估受影響的其他需求,也要縱向評估與變更需求相關(guān)的工作產(chǎn)品與計劃。需求變更的影響范圍評估直接影響到需求變更的有效性,也是進(jìn)一步開展變更活動的工作量估算、計劃變更、管理控制和變更確認(rèn)等活動的依據(jù)。

完整的需求變更過程至少包括如下幾項活動:

1) 理解變更需求。

2) 評估需求變更的影響范圍。

3) 重新承諾需求。

4) 待變更工作產(chǎn)品出庫。

5) 一致性地變更工作產(chǎn)品(包括需求跟蹤矩陣)。

6) 對變更進(jìn)行確認(rèn)。

7) 變更工作產(chǎn)品入庫,變更基線。

很多組織把需求變更管理納入配置管理的基線變更管理規(guī)程。無論是將需求變更單獨管理,還是納入配置管理一并管理,都應(yīng)該認(rèn)識到變更管理的共同之處:所有的變更都強調(diào)一致性,否則就是無效的變更。一致性的變更,狹義的理解是所有的變更都與變更的初衷并行不悖,廣義的理解是所有的變更都要與用戶需求保持一致。如果統(tǒng)一到這個認(rèn)識上來,那么完全可以將需求變更管理作為變更管理的一項特例。

迭代開發(fā)可以降低需求變更的影響。迭代開發(fā)分批投入研發(fā)成本,每次研發(fā)成本投入時都實現(xiàn)當(dāng)時最明確的一部分需求。迭代開發(fā)雖然沒有減少需求變更,但是能夠降低需求變更對研發(fā)成本的影響。

3 需求管理的軟件工具

使用Word和Excel管理需求的好處是簡單,弊端是效率提升不顯著,并且不便于在多人和多團(tuán)隊之間協(xié)作。目前國內(nèi)外流行的商業(yè)和開源需求管理工具有數(shù)十種之多,通常它們具有如下功能:

(1) 對需求進(jìn)行結(jié)構(gòu)化管理。所謂需求的結(jié)構(gòu)化是指賦予需求必要的屬性,并按照結(jié)構(gòu)化數(shù)據(jù)的組織形式進(jìn)行存儲和管理。需求的結(jié)構(gòu)化屬性包括:標(biāo)識、標(biāo)題、版本號、接收時間、來源、類型、狀態(tài)、優(yōu)先級、內(nèi)容、變更履歷等。需求條目結(jié)構(gòu)化以后,可以根據(jù)屬性對需求進(jìn)行分類、檢索和分析。

(2) 對需求進(jìn)行層次化管理。所謂需求的層次化是將需求分解為更細(xì)粒度的條目,形成層次化的結(jié)構(gòu)關(guān)系。例如,可以將需求分解為史詩、故事、子故事或者系統(tǒng)需求、軟件需求、部件需求、模塊需求等。底層需求條目默認(rèn)繼承上級條目的依賴關(guān)系,修改下級條目的依賴關(guān)系會同步更新上級條目。

(3) 建立和顯示需求追蹤關(guān)系。工具能夠存儲和維護(hù)需求追蹤關(guān)系,并用多種視圖直觀地顯示局部或整體的關(guān)聯(lián)關(guān)系。某些工具還具有變更建議功能,當(dāng)某一個條目被更改后,能夠根據(jù)追蹤關(guān)系自動地搜索關(guān)聯(lián)條目,提示或通知用戶。

(4) 管理變更。工具能夠在不同角色之間定義流程和表單,實現(xiàn)完整的需求變更申請、審批和通知流程。某些工具還具有基線管理功能,能夠?qū)Ρ然€差異。

(5) 狀態(tài)統(tǒng)計。工具能夠跟蹤和統(tǒng)計需求的狀態(tài)(例如:已提出、已接受、已批準(zhǔn)、已實現(xiàn)、已驗證、已刪除、已否決等),生成統(tǒng)計圖表,便于管理人員從需求實現(xiàn)的角度掌握項目進(jìn)展。

在商業(yè)競爭和開源社區(qū)的推動下,需求管理工具推陳出新。一些需求管理工具是項目管理套件的一部分,另一些工具支持?jǐn)U展,能夠與其他管理軟件協(xié)同實現(xiàn)需求到任務(wù)計劃、需求到測試、需求到缺陷的跟蹤管理功能。一些工具向云端應(yīng)用和移動端應(yīng)用延伸。一些工具是DevOps工具鏈的組成部分。很多工具采用Web架構(gòu)從而支持異地多團(tuán)隊協(xié)作開發(fā)。企業(yè)和組織可以根據(jù)自身需要,選擇合適的需求管理工具。

4 結(jié) 語

需求管理人員要有足夠廣闊的視角,面向軟件研制全生命周期的工作產(chǎn)品和主要活動,實施基于用戶需求的一致性管理。在用戶需求規(guī)模不斷增長的同時,對需求管理的要求也越來越精細(xì)和精準(zhǔn),恰當(dāng)選擇和有效使用工具,能夠?qū)π枨蠊芾砉ぷ饔兴妗?/p>