需求一致性的軟件工程方法

張 昱

(中國科學院空天信息創新研究院 北京 100190)

0 引 言

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

如下兩個主要原因導致工程活動和工作產品偏離用戶需求:第一,用戶需求源于期望和愿景。隨著工作開展,用戶對需求的認識也在不斷地深入和細化。軟件研制方如果不能適應和管理用戶需求的變化,工作就會逐漸偏離用戶的需求。第二,在需求分析、軟件設計、編碼、測試等多個概念轉換及衍生產品的形成過程中,軟件研發人員對用戶需求的理解和再理解可能出現偏差,工作產品之間可能出現不一致,這些理解偏差和不一致很容易累積起來,影響相關和后續的工作產品,導致交付的工作產品與用戶需求不一致。

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

1 需求管理的目的

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

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

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

2 需求管理的工程活動

通過理解和承諾需求、建立需求追蹤關系、發現和解決不一致、管理需求變更四組工程活動達成需求管理的一致性管理目標。

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

規范需求提供渠道、建立需求溝通機制、明確需求接收準則和做出需求實現承諾是理解和承諾需求的主要活動內容。

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

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

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

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

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

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

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

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

2) 以追蹤關系為線索,進一步識別關聯條目之間的不一致。

3) 標識并糾正不一致。

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

解釋幾個關于需求跟蹤矩陣的常見問題:

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

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

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

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

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

2.3 發現和解決不一致是需求一致性管理的重點

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

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

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

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

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

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

2) 解決需求不一致。項目管理人員應該認識到,所有涉及“需求不一致”的問題都是影響產品交付和項目成敗的嚴重問題。個人、小組、質量保證人員、用戶代表、同行專家在任何場合發現的需求不一致都應轉成問題,由軟件項目負責人組織解決,由質量保證人員監督解決。不一致的解決策略有三種:

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

(2) 變更用戶需求。

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

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

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

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

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

1) 理解變更需求。

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

3) 重新承諾需求。

4) 待變更工作產品出庫。

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

6) 對變更進行確認。

7) 變更工作產品入庫,變更基線。

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

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

3 需求管理的軟件工具

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

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

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

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

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

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

在商業競爭和開源社區的推動下,需求管理工具推陳出新。一些需求管理工具是項目管理套件的一部分,另一些工具支持擴展,能夠與其他管理軟件協同實現需求到任務計劃、需求到測試、需求到缺陷的跟蹤管理功能。一些工具向云端應用和移動端應用延伸。一些工具是DevOps工具鏈的組成部分。很多工具采用Web架構從而支持異地多團隊協作開發。企業和組織可以根據自身需要,選擇合適的需求管理工具。

4 結 語

需求管理人員要有足夠廣闊的視角,面向軟件研制全生命周期的工作產品和主要活動,實施基于用戶需求的一致性管理。在用戶需求規模不斷增長的同時,對需求管理的要求也越來越精細和精準,恰當選擇和有效使用工具,能夠對需求管理工作有所助益。