張 昱

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

0 引 言

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

如下兩個(gè)主要原因?qū)е鹿こ袒顒?dòng)和工作產(chǎn)品偏離用戶需求:第一,用戶需求源于期望和愿景。隨著工作開展,用戶對需求的認(rèn)識也在不斷地深入和細(xì)化。軟件研制方如果不能適應(yīng)和管理用戶需求的變化,工作就會(huì)逐漸偏離用戶的需求。第二,在需求分析、軟件設(shè)計(jì)、編碼、測試等多個(gè)概念轉(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)品。有時(shí),將需求開發(fā)和需求管理統(tǒng)稱為需求工程。本文側(cè)重研究需求管理。

1 需求管理的目的

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

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

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

2 需求管理的工程活動(dòng)

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

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

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

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

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

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

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

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

如何在理解和承諾用戶需求的基礎(chǔ)上,通過管理手段保障需求分析、軟件設(shè)計(jì)、代碼、測試用例、計(jì)劃與用戶需求的一致性呢?業(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è)計(jì)、代碼、測試用例和任務(wù)計(jì)劃的編號,行是被追蹤的用戶需求條目。如果每行用戶需求都能分別對應(yīng)至少一條軟件需求分析、軟件設(shè)計(jì)、代碼、測試用例和任務(wù)計(jì)劃的編號,那么需求跟蹤矩陣滿足了縱向追蹤關(guān)系;如果標(biāo)識了用戶需求和依賴用戶需求之間的關(guān)聯(lián)關(guān)系,那么需求跟蹤矩陣滿足了橫向追蹤關(guān)系。當(dāng)存在較多的“一對多”或“多對多”的追蹤關(guān)系時(shí),這種簡單的二維需求跟蹤矩陣就難以維護(hù)和檢索了。此時(shí)可以把簡單需求跟蹤矩陣的一張二維表拆分成多張二維表,即拆分成:用戶需求依賴關(guān)系跟蹤關(guān)系表、用戶需求-軟件需求分析跟蹤關(guān)系表、軟件需求分析-軟件設(shè)計(jì)跟蹤關(guān)系表、軟件設(shè)計(jì)-代碼跟蹤關(guān)系表、代碼-單元測試跟蹤關(guān)系表、軟件設(shè)計(jì)-集成測試跟蹤關(guān)系表、軟件需求分析-出所/出廠測試跟蹤關(guān)系表、用戶需求-驗(yàn)收測試跟蹤關(guān)系表等,每張二維表的行和列分別是被追蹤元素和依賴元素,每個(gè)單元格可以寫入依賴/被依賴的雙向追蹤關(guān)系。使用一張二維表建立追蹤關(guān)系的方法也稱單矩陣追蹤,使用多張二維表建立追蹤關(guān)系的方法也稱多矩陣追蹤。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(2) 變更用戶需求。

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

2.4 管理需求變更是需求一致性管理的難點(diǎn)

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

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

完整的需求變更過程至少包括如下幾項(xiàng)活動(dòng):

1) 理解變更需求。

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

3) 重新承諾需求。

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

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

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

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

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

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

3 需求管理的軟件工具

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

(1) 對需求進(jìn)行結(jié)構(gòu)化管理。所謂需求的結(jié)構(gòu)化是指賦予需求必要的屬性,并按照結(jié)構(gòu)化數(shù)據(jù)的組織形式進(jìn)行存儲(chǔ)和管理。需求的結(jié)構(gòu)化屬性包括:標(biāo)識、標(biāo)題、版本號、接收時(shí)間、來源、類型、狀態(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)系會(huì)同步更新上級條目。

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

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

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

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

4 結(jié) 語

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