基于敏捷建模的形式化需求分析方法

摘要：軟件需求分析是軟件生命周期中最關鍵的一步。傳統的需求建模方法主要有兩個重大的缺陷：1) 非形式化的需求描述常常導致需求的歧義性和不一致性，因而難以確認和驗證；2) 易變性，需求變更及其連鎖反應是對項目質量、進度乃至合同履行影響最大的風險因素。本文針對軟件需求分析階段的難點，通過將形式化方法和敏捷建模理論相結合，提出一套基于敏捷建模的形式化需求分析方法。

關鍵詞：敏捷建模；形式化方法；需求分析；需求工程；VDM語言

中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2008)34-1680-03

Formal Requirement Analysis Method Based on Agile Modeling

ZHANG Yu1，2， PING Long-mei1，3

(1.Faculty of Computer Science and Technology of Suzhou University， Suzhou 215000， China; 2.ShangHai Ronsing Investment CO.， LTD， Shanghai 200127， China; 3.ShouZhou Hospital of Traditional Chinese Medicine， Suzhou 215021， China)

Abstract: Software requirement analysis is the most important step in software life cycle. However there are two major defects of traditional requirement modeling methods. One is frequent requirement ambiguity and discord caused by informal requirement description. Therefore it is hard for identification and confirmation. The other is changeability. Requirement change and its chain reactions are the most influential risk factor for the project quality， process and contract performance. This essay focuses on dealing with the difficulties of software requirement analysis. It put forwards a set of formal requirement analysis methods on the basis of agile modeling through the combination of formal method and agile modeling theory.

Key words: agile modeling; formal method; requirement analysis; requirement engineering; VDM Language

1 引言

需求分析是指理解用戶需求，就軟件功能與客戶達成一致，估計軟件風險和評估項目代價，最終形成開發計劃的一個復雜過程。面對千差萬別的用戶要求，如何能夠快捷、準確的獲取系統的需求并建立起無歧義的、完整的需求模型已成為軟件開發中的核心問題。敏捷建模（AM）是針對基于軟件系統的有效建模和編寫文檔的一個混亂而有序的、基于實踐的方法。形式化需求模型采用形式化規格說明語言(最好采用廣譜的形式語言，以利于實現需求模型向設計階段的演化)進行描述，目的是為了對用戶的需求進行精確的定義，有利于今后對模型的驗證及自動生成設計階段的程序。形式化方法（Formal Methods）是全面系統地使用基于數學的語言、技術和工具精確地說明、開發和驗證軟件系統，使用形式化方法描述的規約具有規范性和無二義性。而且形式化語言是一種機器可處理的描述語言，可以保證軟件復用自動化成為可能。

2 理論模型的框架

Alistair Cockburn指出，“不同的項目需要不同的方法論，一個項目的最佳過程是這個項目所能負擔的最小過程”。因此，基于敏捷建模的形式化需求分析方法（如圖1 理論模型框架）將主要適用于以下情況：

1) 開發規模﹤50人；

2) 需求不肯定或變化太大的場合；

3)客戶理解和能參與的場合；

4) 有嚴格安全性要求的場合；

5) 重視需求分析和文檔編寫的場合。

基于敏捷建模的形式化需求分析方法理論模型框架如圖1所示。

基于敏捷建模的形式化需求分析方法的軟件需求工程的流程特點如下：

1) 運用敏捷需求會議獲取需求；

2) 使用敏捷方法建立模型；

3) 對生成的非形式化需求模型進行確認，若用戶對模型不滿意或模型存在問題，則返回前面的模塊重新進行需求分析；

4) 對生成的非形式化需求模型中的各個構件進行演化轉換，即將需求模型中對構件的非形式化描述轉換為嚴格的形式化描述，得到形式化需求模型；

5) 根據形式化需求規格說明模板，對確定下來的形式化需求分析模型進行細化和求精，得到完整的形式化需求模型；

6) 在進入設計階段之前，對生成的形式化需求模型還需通過嚴格的一階謂詞邏輯推理進行正確性驗證；

7) 在需求分析的整個過程中應通過建立需求基線庫對需求模型的變化軌跡進行記錄，使需求變更能沿著受控的方向進行。

2.1 需求獲取

常見的需求收集方法包括：客戶訪談、客戶交流、市場調研、技術支持、高層拜訪、競爭對手分析、查閱媒體信息、需求專題分析討論會。可遵循以下步驟：

1) 把用戶群進行分類并分析各自特征及職責；

2) 選擇用戶代表并和開發人員組成核心隊伍；

3) 開展敏捷需求分析會議獲取用例；

4) 獲取非功能需求。

2.2 基于敏捷方法的需求建模

2.2.1 建立用例模型

在捕捉用例時需要注意的一點是，不要在一開始就竭力捕捉所有的細節，這是在細化階段要進一步做的工作。一個敏捷用例模型的確定應該遵循以下步驟:

1) 分析研究上一步得到的系統的需求，找出系統外部的活動者和外部系統，確定系統的邊界和范圍；

2) 確定每一個活動者所期望的系統行為；

3) 把這些系統行為命名為用例；

4) 把一些公共的系統行為分解為一批新的用例，供其它的用例引用。把一些變更的行為分解為擴展用例；

5) 編制每一個用例的說明；

6) 繪制用例圖；

7) 區分主業務流和例外(異常)情況的事件流。可以把表達例外(異常)情況的事件流的用例畫成一個單獨的子用例圖；

8) 精化用例圖。解決用例間的重復與沖突問題，簡化用例中的對話序列。用例圖可以有不同的層次，高層系統的用例可以分解為若干個下屬子系統中的子用例。

2.2.2 抽象設計類

在繪制完用例圖后，就需要對用例中的對象抽象出類。建立類圖的一般步驟如下:

1) 研究分析前面得到的用例圖；

2) 發現對象與類，明確它們的含義和責任，確定屬性和操作；

3) 發現類之間的靜態聯系；

4) 設計類與聯系。調整和精化己得到的類和類之間的聯系，解決諸如命名沖突、功能重復等問題；

5) 繪制類圖并編制相應的說明。

2.2.3 需求存檔

根據建立的用例與類模型再對系統的各個功能建立相應的動態模型，至此用戶的需求通過這種非形式化的描述形成了最初的需求定義文檔。最后，當完成需求的定義及分析后，需要將此過程書面化，要遵循既定的規范將需求形成書面的文檔，通常稱之為需求文檔。與此同時，每一個公布的需求文擋的版本應該包括一個修正版本的歷史情況，即己變更的內容、變更日期、變更人姓名以及變更的原因。

2.2.4 需求確認

需求確認簽訂的協議可以視為建立了基線，進一步的變更可在此基線上通過項目定義的變更過程來進行。變更可能會重新協商成本、資源和項目階段任務等事宜。對需求分析達成一定的共識會使雙方易于忍受將來的摩擦，這些摩擦來源于項目的改進和需求的誤差或市場和業務的新要求等。此外，可將用戶的需求轉化成以下幾種狀態：

1) 有可能要取消的；

2) 有的因為不明確而可以后延的，同時可能轉化為被取消的需求；

3) 與客戶經過溝通或確認的，此處有兩種情況，一類是確認雙方達成共識，另一種情況是還需要再進一步溝通的。

2.3 模型演化

對于生成的非形式化需求規格說明文檔，由用戶首先進行需求確認，審查是否需求說明中包含了用戶的所有功能要求并符合用戶對系統的預期目標。若生成的需求說明不符合用戶對實際系統的要求，則需要重新獲取用戶的需求信息并進行相應的分析:若用戶對需求說明表示贊同，則需要根據模型演化的策略，對實際系統構件語義網中的結點進行廣度優先搜索，將非形式化模型中各個構件的非形式化描述分別轉化為嚴格的形式化描述，生成簡單的形式化需求模型，并根據形式化需求說明模板進一步對生成形式化需求模型進行補充和完善，得到最終的系統形式化需求規格說明書。

2.4 形式化需求模型

本文中對需求規格說明書的形式化描述采用VDM語言實現。VDM語言是目前較為流行的形式化需求規格說明語言之一。其基本思想是運用抽象數據類型、數學概念和符號來規定運算或函數的功能，由狀態規定、類型不變式規定和運算功能規定三部分構成。例如：在需求規格說明書中對企業物流管理中的產品清單和產品銷售的形式化描述為：

產品清單的形式化描述:

String=Seq of Char

Goods=Compose Goods of

Bh: String

Name: String

Price: R

Stock_count: N

End

Goods_11st=seq of Goods of

Inv_goods≡△?坌mk_Goods(n，p，c)∈Goods.b≠’’=>n≠’’∧p>0.0

/*規定若產品清單中的產品編號不為空時，產品名稱也不為空且價格大于O*/

產品銷售的形式化描述

G00DS_SALE(g1:Goods_11st，req_num:String，req_count:N)g2:Goods_list

pre len g1>0

post len g2=len g1∧?坌i∈inds g2=>Bh(g1[i]>=Bh(g2[i])∧

Stock_count(g2[i])=Stock_count(91[i])-req_count

選擇VDM語言作為本理論形式化描述手段的主要原因有以下幾點：

1) VDM采用了結構化的過程用抽象數據類型、數學概念和符號來規定運算或函數的功能，可以簡短而明確地指出軟件系統需要完成的功能；

2) 由于VDM語言中采用了數學符號和抽象數據類型，從而可以使軟件系統的功能描述在抽象級上進行，完全擺脫了實現細節，為軟件實現者提供了很大的靈活性；

3) VDM語言為形式化需求說明的正確性證明提供了依據，可以采用一元謂詞邏輯推理技術驗證運算和函數的實現是否符合它的形式化說明。

2.5 模型驗證

為了保證需求分析結果的一致性和完整性，應對生成的形式化需求模型進行驗證.用于驗證的推理機制應借助于知識庫中存放的用于需求分析的專業知識，發現需求模型中的矛盾和不足，經補充、更新知識庫中的知識和規則，以及與系統分析員的不斷交互，得到完整的功能規范。由于證明工作還存在著一些內在困難，目前形式化規格說明的正確性證明還不能完全通過計算機自動實現，這將是本文繼續研究的一個方向。

3 結論

在軟件需求工程理論已經比較成熟的今天，如何更好的獲取需求和對用戶的需求進行分析建模仍然是令大多數系統分析員頭疼的事情，本文就是在這樣的環境下提出的理論模型—基于敏捷建模的形式化需求分析方法，旨在減少系統開發中需求分析所花費的時間，增加系統分析員與用戶對需求的理解，為項目的成功打下基礎。

參考文獻：

[1] Fowler M，Scott K.UML精粹—標準對象建模簡明指南[M].北京:清華大學出版社，2002.

[2] 劉麗，姜紅，李延霞，等.如何在軟件開發的需求管理中應用敏捷建模[J].福建電腦，2004(1).

[3] 陸汝鈐.計算機語言的形式語義[M].北京:科學出版社，1992.

[4] Ambler S W，Aglile.Modeling Effective Practices for extreme Programming and the Unified Process[M].北京:清華大學出版社，2002.

[5] 故天龍.軟件開發的形式化方法[M].北京:電子工業出版社，2005.

[6] Baugh J R.離散數學/國外計算機科學教材系列[M].6版.北京:電子工業出版社，2005.