詳細需求建模階段
一旦系統的范圍和高層需求得到認同，基于該階段的成果，你就可以開始為你的開發工作制定進度，將這些需求帶進一個迭代過程（iteration）。該計劃隨著你對需求的理解的不斷發展而演化，由此你就開始了真正的開發。
迭代過程的開始
在這個過程的開始階段，這些需求會分發到各個開發者手中。在一個實施XP開發流程的項目組中，開發人員會結成對子，自愿地對給定的用戶故事進行處理。每個用戶故事都以相同流程得以處理，這個過程不斷反復直到處理完所有的用戶故事。實施UP的項目組或者以類似的方式運行，或者由項目經理將需求分配給某個開發者或一個小組。無論以何種方式，開發小組/對子都處于實現這些需求的狀態。第一步就是要詳細了解你的項目甲方想要得到是什么東西，這可能需要進行一些需求建模分析。
在這個迭代過程的開始階段有兩種方式進行建模工作：
集中所有需求在一起進行建模。采用這種方法，整個項目組以及能到的項目甲方會在一起探討詳細的需求，分析這些需求，對已有的系統設計提出修改建議以支持這些需求。假設這整個迭代過程是兩個星期，我希望這個會議的持續時間一個小時到半天。如果這個過程更長，假設四到六周，你可能需要花一整天的時間在這上面。這個時間不希望超過一天，因為你不會收到具體的反饋，具體的反饋只有當你用代碼驗證它時才會得到的。這個方法的優點是可以對所要進行的工作和打算如何去做有一個具體視圖，而且可以得到所有項目成員的想法，因此增大了確立一個良好開端的機會。它的缺點就是只適用小項目組，一般少于十個人。而且也比較浪費時間，因為不是與會的每個人以后都要參與各個方面的工作。注意一旦完成了這個初期階段的工作，每個開發小組仍然需要對它們所負責的部分進行詳細的建模。
各個開發小組對它們所負責的需求直接進行建模。有些開發組會在迭代過程的開始階段放棄以上做法，而簡單地就直接讓各小組進入到其所負責的部分。這種方式的成功需要有這樣的前提：需求間沒有聯系，或至少聯系不是太多；開發人員遵循集體所有制這個做法；基于共有的代碼之上。它的優點就是能夠使得項目組在迭代過程開始的第一天就進入詳細分析建模。但它有幾個缺點：第一，當需求映射到設計上有交叉時，可能有兩個小組都在處理有關定單計算的問題（比如一個小組負責計算稅款，而另一個小組負責折扣的計算），這就會有兩個小組工作重疊的風險。但這不算一個嚴重的問題，因為每個小組都應該知道其它小組正在做什么，當需要時可共同工作。第二，這會經過較長的時間后項目的整個實現視圖才會明了。第三，在開始會引起對項目甲方的爭奪，因為每個小組工作的開展都需要從他們那里得到輸入。
迭代過程中
一旦結束了開始階段的工作后，項目組很快就進入到持續的迭代過程中，建模、編碼、測試、編譯，或者進行軟件配置。你和項目甲方的大部分需求建模的工作會在這段時期中體現，這個過程的目的就是探究、細化這些需求。實際上，更準確地說這些工作就是一些建模會議，因為你可能會不斷地重復著需求、分析和設計。這些會議一般是由一小組人即席召開的，一般包括開發小組成員和由一個或幾個項目甲方提供輸入。這類會議一般討論某一類別的問題，如“莎利，你能花幾分鐘時間講一下客戶是如何搜索一個定單的嗎?”。
那么我在SWA Online這個項目中是如何進行詳細需求建模的呢？首先，假設我們有兩個人結成對子。在這個迭代過程中，我們要實現定單的定義和使用案例中“下定單”（Place Order）這個行為的基本路線（basic course of action）中的定購部分。在這里，我們不去實現查找功能，任何類型錯誤和異常的處理，稅金計算和折扣計算[1]。一個行為的基本路線常稱為“愉快路徑”（happy path），因為沿著這個基本路線所有操作都是正常的、愉快的。行為的備用路線（alternate course of action）是描述當有不正常的操作時所走的路線，這里比如一個用戶向一個缺少存貨的產品下定單的情況。我們現在僅關心“愉快路徑”，其它的需求會由其它的小組或者我們在以后處理。
我們要做的第一件事是充實這條基本路線的邏輯過程，如圖9所示。同時也進行關于這個使用案例的基本用戶界面原型的工作，如前面的圖2所示。之所以我們要并行地進行這兩部分工作，是因為它們從兩個不同方面來解決這個問題。使用案例描述的是用戶在下一個定單時要做什么，基本用戶界面原型則是構造一個支持該行為的用戶界面。請注意使用案例“Place Order”利用構造型(stereotype)<<Include>>調用了另一個使用案例“Search for Item(s)”，見圖7。雖然這個功能是該使用案例中的一部分，但我們并不在這里實現它，因為它超出了范圍。我們會采用另一種方式來替代，有可能就是直接給出一個假設的查詢結果的頁面。這個查詢功能會在稍后恰當的時候實現（記住，我們使用的是增量的方式）。同樣現在也沒有考慮任何類型的技術問題，我們會在以后的分析中或設計中決定這些問題�，F在我們只是想了解這個下定單的基本過程，稍后（可能就幾分鐘后）我們才關心實施的細節。對那些我們不會在這個迭代過程中實現的邏輯步驟，比如稅款和折扣計算，當我們在編碼時會留下接口。
這個使用案例從一個用戶選擇下一個定單開始。
用戶通過另一個使用案例“Search for Item(s)?”來搜索物品。
用戶選擇一個物品并加入到他/她的定單中。
用戶指定他們想購買該物品的數量。
系統通過該物品的單價和購買數量計算出總價。
用戶重復第2步到第5步繼續訂購其它物品。
用戶結束向他們的定單加入物品。
用戶提供送貨信息和付款信息，包括他們的名字、電話號碼和郵寄地址。
系統計算定單中所有物品的總價。
系統按照“Calculate Taxes for an Order”這條規則計算適用于該定單的稅款。
系統按照“Calculate Discount for an Order”這條規則計算適用于該定單的折扣。
系統顯示稅款和折扣。
系統加上稅款和減去折扣，得出最后的總價。
系統顯示該定單的匯總表。
用戶驗證該定單是否正確。
系統為該定單下計劃（參見使用案例“Fulfill Order”）
系統給出一張該定單匯總收據。
雖然我們知道該系統使用瀏覽器進行操作，但我們不會現在就用一個HTML的編輯器進行用戶界面的設計，而是仍舊使用粘貼紙。因為在用戶界面設計的初期，我們會經常地很頻繁地增減控件、改變布局，我們希望用一種工具來支持，而粘貼紙所具有的靈活性和彈性正是我們所需要的。當這個頁面的布局穩定下來后，我們會轉到HTML編輯器上，因為我們此時想生成一個更加具體的界面可以讓甲方進行評估。眼下，我們就簡易行事。
在這個階段，我們遵循了靈巧建模的幾個做法。明顯的有并行建立多個模型（Create Several Models in Parallel）這一條，因為我們同時進行了使用案例和基本用戶界面的工作；有同他人一起建模（Models With Others）這一條，因為包括了兩個我們的開發人員和至少一個負責提供需求的甲方；有簡單地建模（Depict Models Simply）這一條，通過圖2中的這個簡單模型我們可以看到這點；有創建簡單內容（Create Simple Content）這一條，圖9所示就是一個很好的例子，它剛剛好足夠詳細地描述了使用案例的業務邏輯；有使用恰當Artifact(s)（Apply The Right Artifact(s)）這一條，業務規則不在使用案例中體現而在另外單獨的業務規則artifact中，雖然你可能會提出異議“計算定單的總價就是一條簡單的業務規則”（此時，對于計算定單的稅款和計算定單的折扣這兩個業務規則，你可能會在文檔或所引卡片這類用于業務規則的artifact中預留下位置）。此外，用戶界面的需求使用的也是另外一個artifact，即基本用戶界面原型。如果我們還有數據方面的需求的話，它將會使用概念模型；有切換到另外的Artifact( Iterate To Another Artifact)這一條，當我們在用戶界面原型上增加了一項時，會發現在使用案例中缺少相應的邏輯，反之亦然，這時我們就會在使用案例和基本用戶界面原型間來回修改；最后，也用到了使用最簡單工具（Use The Simplest Tool）這一條，用戶界面原型用的是紙張，使用案例邏輯寫在白板上。
一般我們花費在上面建模的時間是三十至六十分鐘。假設我們對建模的結果感到滿意，要么就會繼續進行分析和設計工作直至編碼，要么會先花上幾分鐘時間用剛才所學到的去更新一下項目組的概念模型。我建議使用盡可能簡單的概念模型，就像圖3所示的CRC卡片，因為它們易于使用而且非常容易被項目甲方理解。它們不僅用來表示系統中主要的實體，而且可以表示出這些實體的職責（包括數據和行為）。對于概念建模，你下一個最好的選擇就是采用UML的類圖（class diagram）。它的優點在于能夠表示出類或實體間的關系，例如多重性（multiplicity）和角色（roles）。CRC模型中的類合作者就隱含地表示了類之間的關系。問題是對于你的項目甲方來講，類圖不如CRC卡片那么容易理解，即便他們努力地積極參與，但類圖還是過于復雜了。傳統上數據模型用于概念建模，經實踐驗證即使當使用結構化的技術進行實現時也是可行的，但UML的類圖卻難以做到。
盡管我在這里所講述的建模工作很有可能花不了一個小時，但你可以很容易地組織你的建模工作，更好地進行劃分�；蛟S首先集中解決前幾層的使用案例及其相應的用戶界面，實現這部分的功能，然后再回過頭來解決下幾層的使用案例。這種方法在兩層的時候工作得很好，你應該采用最適合你自己的方法。
認識到在這個迭代過程中需要不斷地反復是很重要的，當需要時就要回到需求建模的工作上。當你開始實現下定單這個功能時，有可能會發現你對其工作的細節并不清楚，比如對某類物品可能有購買數量的限制。如果發生這樣的情況，你就會有新的功能需要進行評估、要指定優先級和將其帶入以后的迭代過程中。有可能你的邏輯順序顛倒了 – 客戶可能應該首先提供送貨和支付信息；還有可能應該提供一種能讓客戶一次性地建立他們送貨和支付信息的途徑�？偠灾�，新的需求必須要在新一輪的迭代過程中加以處理。
解決需求建模中的常見難題
為了能以靈巧的方式進行需求建模，需要具備一定的條件。但不幸的是，很多項目組并不具備。需求建模工作常常被你所處的環境所影響和破壞，一般是組織所奉行的文化不利于有效的軟件開發或者項目甲方不清楚他們的決定所帶來的影響。在這一節中，我列出了一些在需求建模中多數項目組經常碰到的問題，并討論了可能的解決方案。這些常見的難題如下：
難于接近項目甲方 （Limited access to project stakeholders）
項目甲方分散在各處 （Geographically dispersed project stakeholders）
項目甲方不知道他們想要得到的是什么（Project stakeholders do not know what they want）
項目甲方改變主意（Project stakeholders change their minds）
優先級沖突（Conflicting priorities）
過多的項目甲方想參與進來（Too many project stakeholders want to participate）
項目甲方指定了技術方案（Project stakeholders prescribe technology solutions）
項目甲方墨守成規（Project stakeholders are unable to see beyond the current situation）
項目甲方含糊其詞（Project stakeholders are afraid to be pinned down）
項目甲方不懂建模artifacts（Project stakeholders don’t understand modeling artifacts）
開發人員不懂業務（Developers don’t understand the problem domain）
項目甲方過于集中于某一類需求（Project stakeholders are overly focused on one type of requirement）
項目甲方對于需求的確定有許多繁文縟節（Project stakeholders require significant formality regarding requirements）
開發人員不懂需求（Developers don’t understand the requirement）
難題 #1 難于接近項目甲方
這是一個經常發生的問題。由于某些原因，高層管理部門有時愿意投資數百萬美金進行一項系統的開發，但卻不愿意或不能指派一些合適的人選來告訴你這個系統需要干什么�！盀榱隧椖康某晒�，開發人員需要得到項目甲方的積極支持”，項目甲方常常嚴重缺乏對這一點的認識，他們不清楚軟件是如何開發的；或者他們一直以來都是以這種方式工作（譯者：即不委派人員協助開發），而不知道有更好的方法。
要解決這個問題，首先你需要與項目甲方進行溝通，告訴他們你需要同他們緊密地協作，他們必須投入寶貴的時間與你一起工作。有時可能沒有可以確認的用戶，這種情況通常是當你在開發一個零售產品或一個供你（潛在）客戶使用的基于web的新系統時出現，在這種情況下你需要找一些人來代替。一個較好的方法是選擇你的市場人員或銷售人員，因為他們熟悉客戶，他們腦中對你的系統會有一個大致的輪廓�；蛘咧苯诱乙恍┛赡艿挠脩簦憧梢宰约簭挠脩舻慕嵌热ハ脒@個系統應該提供什么；或者從外面聘請一些人，他們應該是你的產品所面向的用戶）。根據我的經驗你肯定可以找到能為你的系統提供需求的人，曾經有好幾次我都被告之不可能提供人員與我一起工作（但最終都找到了[譯注]）。記住你的項目甲方不僅僅是系統的直接使用者，你應該認識到你是在冒風險如果沒有任何直接使用者參與到你的軟件開發中。
難題 #2 項目甲方分散在各處
對于上一個問題，還有一個原因就是你的項目甲方與你的開發組不在同一個地點，使得你沒辦法與他們很好協作。這種情況常發生在比較大的組織內，一些項目外包給其他組織；或者在一個由多個組織合作開發的項目也會出現這個問題。解決的辦法有幾種。一是，想辦法將開發小組和項目甲方集中到一個地方。正如我在《交流》一文中所提到的，面對面的交流是最直接有效的方式。如果做不到這一點，下一個最好的做法就是讓項目甲方和開發人員在一段時間內在一起，另外的時間通過其它手段進行交流（在《交流》一文中，我提出了幾種可選擇的方式，如電子郵件，視頻會議，和一些支持協作建模的工具）。我曾經參加一個由300人組成的項目組，項目甲方在每三個星期中用一個星期同我們的開發人員一起工作，而其它兩個星期通過電子郵件和電話聯系，這種方式運行得相當好。如果上兩種方法都不適用，那下一種較好的方法就是讓開發人員到項目甲方所在的地，與之共同工作。我在好幾個項目中成功地使用了這種方法。但要注意這對那些出差的人來說非常艱苦的（我就經常出差，幸運的是我喜歡旅行）。還有一種方式就是讓業務分析師先到項目甲方那里去了解他們的需求，然后再讓他們回來與開發人員定義需求。當然，你可以根據你的情況組合使用這幾種方法。
難題 #3 項目甲方不知道他們想要得到的是什么
這就是你什么要花時間進行建模的原因。通過建模來探尋他們想得到什么以及哪些對他們而言是重要的�，F今的商業非常復雜，甲方經常意識到有問題需要解決或存在著改進的機會，但他們不知道如何去做。這是十分正常的。你曾經重新裝修過房間，或者重新布置過家具嗎？你知道你想有一個更好的居住環境，但卻常常措手無策�？赡苣銜ゲ殚喴幌码s志上的圖片，參觀一個家具店，或者去朋友家看看他們是如何擺設的。如果你對構想一個居室的布置感到困難，可想而知，你的項目甲方要確定一個什么樣系統是多么的不容易。
這是一個正常的現象，我們從接受這個觀點開始。如果你的用戶不能確切地告訴你他們想得到的是一個什么樣的東西，告訴他們這沒有關系。他們現在所需要做的僅是告訴你他們想讓你干什么。同重新裝修房間類似，可能你現在還沒有一個整體的布局構想，但你可以從著重于安裝一個書架開始。著眼于他們對系統中有最清楚想法的一個方面，對這個小部分建模，然后實現一個可運作的系統（遵循用代碼進行驗證這一做法）。他們就可以實地操作，向你提供反饋。如果他們甚至連一小點的需求都提不出來，就好像你完全不確定是否會有書在房間中，那么就從調查他們現在的工作方式開始。通過對現有工作流程的建模，你會進一步了解他們的工作，從中看到他們可能需要的改進以及最差的環節在哪，由此就可以向他們建議。
難題 #4 項目甲方改變主意
項目甲方也是人，是人就會改變主意。你把家具按想象中的位置擺好，但當你回過頭來端詳一番，可能覺得這樣并沒有達到想象中的效果。象布置家具這樣簡單的事你都會改變主意，何況那復雜的系統呢。項目甲方百分之百會改變主意。
要解決這個問題，你首先得接受這個事實，擁抱變化。不管發生了什么變化，都是與建模有關的，因為你會發現要么是他們開始時不清楚他們自己的需求（參見上一個討論），要么就是你沒有弄明白他們所想要的。當你同項目甲方一同討論時，你應該從他們的角度以他們的語言達成一致的認識，這會確保你沒有作出另外的假設，而且會提高談話的質量。我曾經參加過為一個電子商務系統開發管理系統的項目，在這個項目中我們得出了一個公正而準確的需求。第一個星期，我們提供了兩個網頁：一個是主頁，上面包含了關鍵功能的菜單項；另一個實現了一個高優先級的功能。我們完全按照他們所要求的來做。當我們想他們演示以后，他們意識到最初的想法不好，然后要求我們重新構造。變化來了。最后，當用戶對系統中某一部分的想法發生改變時，你會發現實際上是由于他們沒有弄清楚需要解決的問題，這意味著需要同他們開一個關于構想的會議（參見需求建模會議的相關內容）；或者是由于某個有不同構想的甲方的意見沒有被正確處理。
難題 #5 優先級沖突
你所建造的系統必須反映多方面的需要，包括直接使用者，高級管理層，你的實施人員，支持人員，以及維護人員。各方面都有不同的優先級要求和目標，即使是同一類中的不同個體也是如此。這就會出現沖突，有沖突就必須進行處理。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
