如何在一個商業應用中以靈巧的方式為需求建模呢？讓我們來看下面的例子。在這個例子中，我們要為一個SWA Online的系統建立需求模型。在開始之前，讀者必須認識到幾個問題。第一，因為本文主要集中在需求建模的討論上，如涉及到其它類型的建模，如分析建模、構架建�；蛟O計建模，我會就此打住并給出我所著的相關文章的連接。靈巧方式的軟件開發是高度反復的過程，由此實際上需求建模與其它類型建模的界線不是很明確的。第二，這里所講的只是許多可用方式的一種，其它的方式也可能是靈巧的。記住，AM是一套基于實踐的方法，它沒有定義特定的，規范的一種做法，因此可采取的方式是多樣的。不用擔心，我會在過程中給出我可能會采用的另外的方式，但這也不是所有的 -- 保持你開放的思維。第三，由于SWA Online的開發小組采用的是Enterprise Unified Process(EUP)(Ambler,2001b)開發流程，那么使用案例就會起主要的作用。反之，如果采用的是eXtreme Programming(XP)(Beck,2000)的話，用戶故事就會占主導地位。我在AM and XP一文中從XP的角度重新討論了這個例子。第四，這個例子雖然是基于我的實際經歷所虛構的，但我想這會使我們的討論更加形象而簡單。第五，最好將需求建�；譃閮蓚�不同的階段：需求初始階段（initial requirement up front(IRUF)）和詳細需求建模階段。
需求初始階段(IRUF)
需求初始階段(IRUF)發生在整個項目生命周期的開始，對應于Rational Unified Process(RUP)(Kruchten,2000)中的Inception phase和XP中的第一個迭代之前。它有三個主要的目的：第一，至少從高層次上確定系統的范圍，以明確你所要做的工作的范圍；第二，定義系統的高層需求；第三，對于需求的含義，在甲方和開發項目組間取得一致。如果你和項目甲方在同一個地點，而且他們能就該系統應該做什么達成比較一致的意見，這個階段可能只需要幾個小時；否則的話，有可能會延長至幾天或數周（參見“解決需求分析建模中的常見難題”一節）。你可能需要召開一個大的建模會議，主要是實現需求初始階段的這三個目的。這些會議有如下特點：
§ 時間長。對一個大的項目可能需要幾天。
§ 有許多項目甲方參加，以便廣泛地聽取他們的需求。
§ 趨向于比較正式的形式（主要由于參加會議的人數眾多，而且項目甲方對哪些靈巧的方式并不熟悉）。
§ 包括一些開發人員。尤其是當你開始想讓項目組理解該系統是完成什么樣的功能時。
系統范圍的定義可能用一句話就夠了，對SWA Online就可以簡而言之為“通過互聯網向客戶出售產品”或者詳細一點的如“在美國本土向新老客戶出售有形的而非虛擬的產品”。系統范圍同樣可使用環境模型（context model）來定義，該模型表示你的系統如何適應所有的環境。它經常使用使用案例圖進行表示，參見圖5；或用數據流圖（DFD），參見圖4（常叫做level-0 DFD）。搞清楚系統的范圍非常重要，只有這樣才能限定你的開發工作。上面的第一句話過于籠統，它可能意味著面向的是國際上的客戶，明顯這比僅針對美國本土客戶的工作量大很多。同樣，出售虛擬產品如在線音樂需要另外一套在線交付系統的支持。隨著時間的推移，這個范圍有可能由于甲方的決定的改變而變化，所以時刻準備好迎接變化。
那么哪一個最適合描述系統范圍呢？一句話，DFD，還是使用案例圖？根據你的情況而定。語句直接了當，但不如圖形的內涵豐富。圖4的DFD以所要建造的系統為中心，表述了其與其它外部實體（組織、人或其它系統）的關系，這些外部實體超出了你的系統的控制范圍但與你的系統有相互作用。這種方式的主要優點是它以合理的細節描繪了你的系統與外界間的主要信息流動。圖5的使用案例圖同樣以所要建造的系統為中心，以及與該系統有交互的參與者（組織或人）。它的主要優點是描繪出與系統有交互的外部的和內部的參與者，而DFD僅有外部的。主要的缺點就是它沒有給出任何一點系統與參與者交互的細節。你應該使用哪一個呢？他們都有各自的優缺點，你可能會考慮都使用。嗯… …？這對我而言不是很靈巧。一個較好的解決辦法就是稍稍違反一下規則，結合這兩種方式優點僅生成一個圖，就象我在圖6中所作的。注意一下我的風格：在兩個實體的左上角用“I”表示出這是內部實體；移去了DFD中的數字標識符（數字標識符難于人工維護），我寧愿遵循一定的規則以使實體的名稱唯一，在需要時這個唯一的名稱可以起到標識符的作用。雖然我選擇了顯示數據流而不得不打破一些使用案例圖的規則，但我仍然能夠輕易地使用使用案例圖的符號。幸運的是我的項目甲方喜歡DFD，我也就投其所好了。記住有目的地建模這條原則就是要你了解你的聽眾，選取最適合他們的artifact。
不要害怕打破規則。一般經驗告訴我們不要在level-0 DFD中包含內部實體，引入內部實體意味著你開始挖掘細節。但我之所以在這里卻選擇了這樣做，是因為它能讓我不用再畫第二張圖。我不會因此而死到臨頭，也不會招致建模警察的控訴。是的，我違反了應用建模標準這一條做法，但這樣做我減少了開發和維護的費用。當這對于某些人成為一個很大的問題時，我想我的組織可以重新考慮一下標準。
為了確定系統的高層需求，我推薦采取基于使用的方法， 即注意力集中在用戶如何利用該系統工作這一點上。根據我的經驗，這是一個對絕大多數的軟件開發都有效的方法。如果你對用戶如何使用系統沒有一點概念，很難想象你所生產的軟件能夠支持他們的工作和改善他們的工作方式。我會將這個方法用在建立組織內部使用的商業應用，由客戶所使用的商業軟件，包裝出售的軟件（如CASE工具或文字處理軟件），數據倉庫的開發，甚至于集成現有的商業系統（COTS）如SAP R/3或Oracle Financials。在數據倉庫系統的開發中，存在著一個普遍的錯誤，那就是首先收集“數據需求”。羅列出用戶想存儲在數據倉庫中的數據元素或數據實體。乍看上去，這是個好主意，但如果你不知道用戶如何使用這些數據，那么你很難定出優先級或者你根本就不清楚你所做的是否就是甲方所想得到的。對于COTS系統，你需要根據需求來選擇使用何種建模方式。如表1所列出的有特性（Feature）、使用情景（Usage Scenarios）、使用案例（Use Case）和用戶故事（User Stories），這都是比較好的方式。根據使用恰當artifact這一條，我會選擇使用案例，因為SWA采用EUP作為軟件開發的主要流程，而使用案例是最適合于這個流程的。如果他們選擇的是XP，則用用戶故事為佳。如果為Feature Driven Development(FDD)(Coad,Lefebvre,Deluca,1999)，那特性就是我的選擇。
圖7是一個高層的使用案例圖，它是一張數字照片，來自于我和我的項目甲方討論時在白板上所畫的圖。這是一個基本使用案例圖（Constantine & Lockwood, 1999; Ambler, 2001a），因為它以技術無關的觀點來顯示系統�；谶@張圖，你既可以全手工的方式來實現這個系統，也可以建造一個全自動的系統。其中的一個使用案例“Post Product Review”可以改名為“Write Product Review”以使之更趨于一般化，但我的項目甲方更偏愛前者。我一直在為盡可能地使需求無關于特定的技術而努力，但事實上許多系統已經局限于某個領域內。例如，SWA Online被限定為基于互聯網的解決方案之上，此時如花費精力去嘗試將其抽象出來，只會得不償失。記住保證甲方的投資獲得最大利益這條原則，將你的精力集中在能帶來效益的那些需求模型上。
使用案例應力求簡單，在初始階段(IRUF)對每個案例有一點提綱挈領式的邏輯描述就足夠了。你不必在此時進行細化，你僅需要對該系統的用途有個基本了解，確定初始的范圍，再對每個使用案例和參與者加一點提綱挈領式的描述。如果得到項目甲方的認可，你就不用花費更多的精力在初始階段�？赡苋剿膫�使用案例就足夠了。然后遵循有目的地建模這條原則，我們就可以終止初始階段的工作，進入到詳細建模階段去建立詳細的模型和實現你所確定的這些需求。注意這種方法更多地是運用在實行XP的項目中，而非實行UP的項目中。
你們可以看見在圖7所示的需求圖中我使用了UML的構造型（stereotype ）<<Include>>，然而在《The Object Primer 2/e》(Ambler, 2001a)一書中我曾建議在分析層次的使用案例圖中使用構造型（stereotype），典型的如系統使用案例圖，因為它們經常反映了架構和設計方面的問題，而需求層次的使用案例圖卻并非如此。同樣，我也不會因為如此而受到建模警察的控訴。這個圖是有意義的，因為它顯示出它對處于流程中不同階段的模型是公共的，在這里它表示我要考慮的包含需求和分析兩方面的問題。
要在項目甲方之間達成一致的意見，這說起來容易，作起來難，盡管你有了“解決需求建模中的常見難題”這幾招。每個甲方的背景、優先權和喜好都各不相同。為了達成一致意見，每個人都必須認識到這點，相互交流他們需要從該系統中得到什么，傾聽他人的意見，準備為了達到一個共同的目標而努力。在我所工作的組中，只要發生意見分歧，我們都會在屋內所有人都能看見的一塊白板前寫下每人的問題，再進行討論。這種方式將這些意見的不同之處可視化，可以集中討論的焦點。在某個問題的提出者認為它不再需要或至少相對于其它問題不那么重要后，我們會將它擦去。雖然有時它是一個較好的意見，但也簡單地將之擦去，因為通常我希望記錄的是最后的決定。對于兩個相互對立的問題，我喜歡在它們之間畫一條其它顏色的連線，以突出它們需要進行討論。
由于我們集中在高層次的使用需求上，相關的業務規則和約束常常也會被同時確定下來。同樣，一些技術需求和將來可能或不可能被實現的需求也會確定。在初始階段（IRUF）你應該將業務規則、約束和技術需求排列出來，常用的方法是將它們寫在粘貼紙上或白板上，找出你是否已具備了足夠的信息以進行后一階段的工作。盡快地結束初始階段的目的是防止你在這個階段就投入時間探究細節。當你在初始階段需求討論會上就進行細節的討論時，你就給你的項目帶來了風險，因為此時你不會收到對你工作的具體反饋，從而陷入分析的泥潭。記住這條原則你的主要目的是軟件，而不是那些設想你的軟件如何運作的模型和文檔。例如在SWA Online的初始需求建模會上，項目甲方提出了一些業務規則和執行順序的約束，象如何打包某類的貨物，某些產品具有一定的上架時間限制，以及分撿流程。當我聽到諸如此類的需求時，我就會叫某個人將其寫在白板上或索引卡片上，稍后再將這些索引卡片放在每人都能看到的公用桌上。
這里有一個重要的觀點：建模會議是交互的，每人都參與其中的。會議的開始需要一個有經驗的模型設計者來段開場白，解釋一些技術，推動與會者進入狀態。這可能就是簡單地叫某人走上臺來，解釋一下正在談論的內容，演示一下通過填寫一張索引卡來總結一條業務規則，或者為一個可能需要的報表在粘貼紙上記錄下數據的要求。當與會者熟悉了這種建模方式后，依照靈巧建模的甲方的積極參與這一做法，你會發現不用花太多的精力去鼓勵他們的參與。是的，有些人比較開始害羞而需要更多的鼓動，但那畢竟是人的本性（如果我能選擇的話，我更喜歡選擇那些外向甲方的加入，而非那些內向不愿開口講出他們意見的人）。
當你的開發組在確定目前版本的需求時，常常伴隨著一些后續版本的需求或一些你可能在某時需要實現的潛在需求。雖然此時你不想過多地深究，而且你也不想實現過多的功能去滿足這些潛在的需求，但你并不想就此丟棄它們。它們也是有價值的。這些潛在的需求可能會影響到你對系統架構的選擇。變化案例（change case）（Bennett, 1997; Ambler, 2001a）是一項用于記錄潛在需求的簡單技術，圖8是SWA Online中的兩個變化案例。在定義項目范圍時一項重要的工作就是指出哪些需求是現在應該實現的，哪些是超出范圍的。變換案例中的需求就是超出當前項目范圍的。如何有效地使用變化案例的詳細內容可參見Agile Architecture一文。
變化：擴展至北美地區
可能性：非�？赡�
期限：12-18個月
影響：
§ 必須支持向加拿大和墨西哥的用戶交貨。與新托運商的關系需要建立。
§ 需要計算相關的稅收和關稅。
§ 由于法律和當地風俗習慣，在這些市場出售的產品有可能會有所不同。
§ 多語言支持（英語和法語是加拿大的官方語言，墨西哥是西班牙語）。
變化：銷售虛擬產品（在線音樂、錄像、書籍… …）
可能性：非�？赡�
期限：6-12個月
影響：
§ 不能與實際產品的運輸流程混在一起。
§ 我們可能需要對某些產品支持數字許可。
§ 個別產品的銷售可能有某種限制（有效時間、拷貝數量）
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
