來自于項目甲方，還是直接或間接的用戶、經理、高級經理、操作人員、支持人員、測試人員，與你的系統有聯系的其它系統的開發人員，或是維護人員？這是所有的正式需求的來源嗎？事實上，提供需求、解釋需求、指定需求和排列需求優先級是項目甲方的職責所在。此外，項目甲方有權利要求開發隊伍投入時間去辨別和理解這些需求。要想以這種輕巧建模的方式獲得成功，理解這個概念是非常重要的。項目甲方負責提供需求，開發組負責理解和實施。
這是否就意味著你可以坐等你的項目甲方來告訴你他們需要什么呢？當然不是。針對他們所告訴你的內容，你可以提出問題，進行分析，促使他們給出更具體的內容，甚而至于可以提出你自己的見解使之改變初衷。你可以建議增加一些新的需求，請注意你所提出的僅是建議，他們可以考慮作為正式的需求加以接受（可能會作出修改）或拒絕。為了找出潛在的需求，你應該經常與甲方保持聯系，并借助于一些已有的文檔，比如公司政策法規、以前的系統，或者公開的可用資源，比如web上的信息、書籍、雜志或你競爭對手的產品和服務。再次聲明，你的項目甲方是需求的最終決定者，而不是你。我不能不強調這一點。
那么項目甲方又從哪里知道他們的需求呢？“我真希望我能這樣做”，他們經常會這樣抱怨現有的系統，因為他們的競爭對手能做到，但他們卻不能；或者想避免過去所出現的問題；或者僅僅是想多增加一個新的功能。一些甲方，尤其是操作人員和高級IT部門經理，可能需要集成現有或即將上馬的系統；或者由于某項（象必須削減計算機數量）政策而帶來的需求。值得注意的是你的項目甲方應該基于大量的依據明確地闡明需求，而這些依據是應該存在的，你可以通過與之交流確定這一點。
我的經驗告訴我在項目中邀請相關方面的專家的加入對找出潛在的需求是很有價值的。例如構建一個電子商務系統，我會邀請有國際化軟件設計經驗的人員、稅法專家或者供應專家的加入。當你對系統中的某些方面不熟悉時（有可能這是你首次構造面向世界各地用戶的電子商務系統），這個方法尤其有效。我經常會邀請一些外部的專家和幾個甲方在一起交流一兩天，來幫助我們檢查是否由于我們的經驗欠缺而遺漏了什么。這對于確保我們的系統是否完整是一個很重要的方式，特別是在最初定義項目所應包括的范圍。這同樣也能夠幫助甲方進一步的思考。但是，你意識到其中存在危險嗎？你所邀請的外部專家提出一些建議可能聽上去是非常好的，但目前根本就用不上的。換句話說，你依然得從這些專家意見中精挑細選。
一些基本原理項目甲方的積極參與對構造需求是非常關鍵的。實際操作中要做到這點存在著兩個問題：第一，甲方自身的提供需求的能力以及他們（或者你）是否愿意積極地參與進來。從我的經驗來看，一些項目組并沒有足夠的途徑與甲方聯系（或不知道甲方在哪），這完全是項目組自身的問題。你的項目肯定有資金，不是嗎？這些資金一定是來自于以某種形式存在的項目甲方，所以他們是確實存在的。同樣，用戶也是肯定存在的。即使你的系統是面向大眾，也至少存在著潛在的用戶，你可以找到他們，同他們交談。所以一定存在著你可以向之詢問的人。你可能會說，“有時要找出這些人有一定困難”，“要讓他們參與進來不是很好辦”。是的，確實存在這樣的難處，想辦法克服它。在“解決需求分析建模中的常見難題”一節中我談到了一些解決辦法，包括沒有足夠的途徑與甲方聯系的問題。我的原則是，如果你的項目甲方不能或不愿意參與，這就意味著你的項目失去了內部支持這條成功的條件，因此你要么解決這個問題要么干脆取消這個項目，以減少損失。如果你聽之任之，至少你不能宣稱使用的是靈巧建模（Agile Modeling）的開發方法（甲方的積極參與是其中的一項核心內容，在AM的開發方法中必須實施）。
那怎么才算項目甲方積極地參與進來了呢？圖1使用UML活動圖（UML activity diagram）大體上描述了需求階段的流程，標示出開發人員與甲方各自應承擔的任務。圖中的虛線把這兩部分任務分開來。從圖中可以看出有一些任務是共同承擔的，如想法或建議的確定（identifying ideas or suggestions）、潛在需求的討論（discussing a potential requirement）、建模（modeling），可能還有文檔的開發（potentially documenting）。項目甲方單獨負責指定需求的優先級，系統是為他們開發的，這當然是他們的責權所在。同樣的，開發人員負責估計實現這個需求所需的資源，因為他們是實際工作人員。如果自己不作估計而采用來自于項目組外部的估計，這是不合理的也是不可取的。雖然需求的優先級確定和估算超出了AM的討論范圍，但是你可以在如XP和UP這樣的軟件流程（Software Process）中找到它，理解它們對于整個需求分析是很重要的。AM并不是一個軟件流程，它只是應用于這些軟件流程中的一種建模方法。
我的觀點是：項目甲方應該加入需求的建模和文檔開發中來，積極地參與，而不僅僅是提供信息。為達到這點，肯定需要開發人員對甲方進行培訓、導引和指導，這是完全可能做到的。我曾經見過一些剛起步的小公司、大企業和政府機構中的甲方能夠以非常高的效率建造需求模型以及將這些需求文檔化。在電信業，在金融業，在制造業，在軍隊里我都看見這樣的人存在。為什么這點這么重要？因為你的項目甲方才是需求的真正專家。他們知道他們想要的是什么（參見“解決需求分析建模中的常見難題”，如果他們不知道)。而且只要你愿意，他們是能夠學會如何建造需求模型和將它們寫下來（譯注，這樣你們之間就可以同一種語言進行溝通）。從輕巧的觀點看，這是很有意義的，因為有更多的人將會分擔需求建模的工作。
為了讓項目甲方更容易地參與進來，消除行業術語方面的障礙，你應該遵循使用最簡單的工具這一做法。表1列出了許多需求階段的artifact，他們都可以用簡單或復雜的工具得到。對于每一種artifact，表中都給出了對應的簡單工具。圖2和圖3是使用簡單工具的兩個例子。圖2表示的用粘貼紙針模擬出一個顯示界面。圖3是使用索引卡片建立概念模型的例子。當你在需求分析階段引入新的技術時，比如一些可以制作很好的使用案例圖的繪制工具或有強大功能的CASE工具，這就會使得你的項目甲方很難加入進來。因為他們不但要學習建模的技術，而且還要學習如何使用這些工具。使用越簡單的工具，進入的門檻也就越低，由此你才有更多的機會去增進相互之間的有效協作。
3 兩個CRC卡片
我堅信需求的建立是獨立于技術的。面向對象的需求、結構化的需求、基于組件的需求，這些都屬于實現技術的范疇。雖然你可以選擇某種技術來分析需求建立需求，但必須牢記你所真正關心的是需求本身。下面所講的所有技術，你可以選擇其中一種或幾種來進行需求建模的工作。
但有時你又不得不拋開“建立與技術無關需求”的想法。比如一個很普遍的限制就是大多數的項目可以從已有的基礎技術上獲益。在這個層次上，需求仍然是獨立于技術的。但如果你仍執著要拋開已有的一些基礎技術，比如某個版本的Sybase數據庫或要與SAP R/3給出的模塊集成，而非得從最底層開始，那就過頭了。只要你知道你在做的是什么就可以了，但不要經常性地這樣干。
記住從小事做起。越小的需求（象特性(features)或者用戶故事(user stories)），相對于越大的需求（象使用案例(use case)）就越易于估計和實現。平均的來說，一個使用案例涵蓋的功能要多于一個使用情景，這就是“大”的含義。
對于需求跟蹤表（requirements tracebility matrix）的使用也需要三思而后行。跟蹤能力是指能夠由項目進行中所生產的某個artifact的某一方面追蹤到另一個與其相關的artifact，而需求跟蹤表就是用來記錄這些關聯關系的。它從每個需求為起點，可以追溯到所有與之相關的分析模型、架構模型、設計模型、源代碼或者測試用例。使用跟蹤表的組織為了保證各個階段artifact（包括跟蹤表本身）的一致性，必須要經常進行更新工作，而不是僅在受到影響時才改動。使用它的好處是你可以很容易地分析出系統中的哪些部分將會受到該需求改變的影響。但是，如果你有一兩個熟悉系統的人（譯注：當然你得留住他們），當系統需要改變時，通過他們來進行評估影響會更容易而且費用也會更低。在我看來，給予跟蹤表的評價過高了，因為維護它所帶來的開銷遠大于所得到的好處，即便你有特殊的工具去做這件事情。讓你項目的管理層認識到它真正的價值和代價所在，讓他們來作決定是否使用它。畢竟，跟蹤表是一份有效的文檔。他們可以據此做出決定。
需求的類型我認為需求可以分為兩類：行為類型的（behavioral）和非行為類型的（non-behavioral）。行為類型的需求描述的是用戶如何與系統交互（用戶界面）、如何使用該系統（用法）、或者是系統如何實現一個業務功能（業務規則）。非行為類型的需求描述的是系統的技術方面，典型的如可用性、安全性、性能、互用性、可信度和可靠性。要注意的是這兩類需求有時并不一定能夠完全分開來。對存取數據速度的性能要求明顯是技術方面的需求，但它也會反映為用戶 界面的響應時間，從而影響到可用性和某些用法。訪問權限管理，比如誰能夠獲取特定的信息，這明顯是一個行為類型的需求。但它也同樣涉及到安全性這個非行為類型的需求。別緊張，不要死揪住這類問題。關鍵的是能夠確定和理解所給出的需求。如果你把一個需求分錯了類，誰又會真的去關心呢？
可能的需求分析的artifact由于存在幾種類型的需求，有可能其中一些或全部適合于你的項目；又因為每種模型都有長處和缺點，你應該綜合利用這些模型，取長補短，以發揮最好的效率。表1列出了一些常用的需求分析建模的artifact，更詳細的描述可見Artifacts for Agile Modeling 一文。表中的“簡單工具”一欄指出生成相應artifact所常用的簡單工具（使用簡單工具的重要性在“一些基本原理”一節中討論過）。
artifact
類型
簡單工具
描述
業務規則定義Business rule definition
行為類型
索引卡片（Index card）
業務規則是軟件必須滿足的一條有效的原則或政策。
變化案例
change case
兩者之一
索引卡片（Index card）
變化案例常用來描述新的潛在的需求，或對已有需求的修改。
CRC模型
CRC model
兩者之一，通常是行為類型
索引卡片（Index card）
CRC模型是一組標準的索引卡片。每一張卡片被分為三個部分，分別是類的名稱，類的職責，以及該類的合作者。類是一類相似對象的抽象，職責是該類所知道的或要去做的，合作者是另外一個與該類有交互的類。在需求建模過程中，CRC模型用在概念建模中，用來揭示某一領域內的概念和它們之間高層的關系。
約束定義Constraint definition
兩者之一
索引卡片（Index card）
約束是對你提供解決方案的自由度的限制。把約束作為全局的需求對你的項目來說是很有效的。
數據流圖
Data flow diagram（DFD）
行為類型
白板
數據流圖展現系統中數據在處理過程間、實體間、以及數據存儲站間的流動情況。它常用來描述系統的環境，指出與你的系統相交互的主要外部實體。
基本用戶界面原型Essential UI prototype
兩者之一
粘貼紙
基本用戶界面原型是低精度的。它表現的是界面背后的大致想法，而非細節。
基本使用案例Essential use case
行為類型
紙張
一個使用案例（use case）就是針對一個參與者（actor）的一連串動作，通過使用案例可對該參與者的價值進行測量�；臼褂冒咐且粋�簡化了的、抽象的、一般化的用案例。它以與特定技術和實現無關的方式攫取一個使用者的意圖。
特性
Feature
兩者之一，常用于行為類型
索引卡片（Index card）
從用戶的角度來看，特性是一個小的、有用的結果。一個特性是可以用于計劃、報告和跟蹤的一個計量單位。它是可理解的和可衡量的，可以在兩個星期內完成（同其它幾個特性一起)（Coad, Lefebvre, &Deluca, 1999）。（譯注：一個特性在大多數情況下等同于一個功能）
技術方面的要求
Technical requirement
非行為類型
索引卡片（Index card）
技術上的要求是屬于系統中非功能性的部分，比如性能上的問題、可靠性的問題或者技術環境方面的問題。
使用情景
Usage scenario
行為類型
索引卡片（Index card）
一個使用情景通過一個或多個的使用案例或用戶故事描繪一條單一的邏輯路徑。一個使用情景可以表示一個使用案例中的基本路線，即愉快路徑；或者該使用案例中的其它路徑；或者一條跨越幾個使用案例或用戶故事的路徑。
使用案例圖
Use case diagram
行為類型
白板
使用案例圖由一些使用案例、參與者和它們之間的關系組成�；蛘哌�會有一個系統邊界盒。建模時，數據流圖用來描述系統的環境，指出與系統相關的主要外部實體。
用戶故事
User story
兩者之一
索引卡片（Index card）
一個用戶故事就是你與項目甲方進行的一次談話的備忘錄。它是高層次的需求，包括行為需求、業務規則、約束和技術要求。
表 1 可選的需求建模artifact
應該注意的是，并不意味著你需要將所有上面所列出的都用在任何一個項目中。熟悉你的模型這條原則（見The Principles of Agile Modeling一文）說的就是你要知道每個artifact適合在什么時候用。你對模型了解得越多，就越能夠根據實際情況運用正確的artifact。
artifact的選擇往往被所采用的底層軟件開發流程所左右。在主頁上，我簡要地說明了AM與其它有著完整生命周期的軟件開發流程一起使用的情況，比如XP或UP。通常不同的底層軟件開發流程對需求分析artifact有著不同偏好，象XP使用用戶故事而UP用使用案例。這也是你在為需求建模時應該考慮的問題。詳細內容請參見AM and XP和AM and UP。
以使用為中心的方法如何在一個商業應用中以靈巧的方式為需求建模呢？讓我們來看下面的例子。在這個例子中，我們要為一個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個月
影響：
§ 不能與實際產品的運輸流程混在一起。
§ 我們可能需要對某些產品支持數字許可。
§ 個別產品的銷售可能有某種限制（有效時間、拷貝數量）
圖 8 SWA Online 的兩個變化案例
那么你需要多少文檔來記錄項目的范圍，初始的、高層次的需求呢？就象我在Agile Documentation一文中所建議的“剛好夠用就行”。對于SWA Online這個項目，我們也許建立一個HTML頁含圖6的環境圖，圖7的使用案例圖，和一個簡短的指出范圍的列表就夠了。為建立高層次需求文檔，我會嘗試將使用案例轉寫在一個單獨的能進行文字處理的文檔上，或者就是一個簡單的文本文件。之所以這樣做，是因為在詳細建模階段我們要細化它們。有這樣一份電子文檔使得共享和處理更容易。至于那些記錄了業務規則、約束、技術需求和變化案例的索引卡片，讓它們保持原樣，因為它們會在詳細建模階段得到進一步的細化。我會讓我的項目甲方相信，如果我們發現它們確實是需要的，我們會處理的，因為我們那時需要它們。這樣由于避免了一些有可能不必要的在文檔上的工作（有些業務規則是不合邏輯的，因此在你知道它們的真正價值前所投入在文檔上的工作都是浪費），就可以使得開發組能夠很快地進入詳細建模階段，然后進入實施階段。
詳細需求建模階段一旦系統的范圍和高層需求得到認同，基于該階段的成果，你就可以開始為你的開發工作制定進度，將這些需求帶進一個迭代過程（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”） 系統給出一張該定單匯總收據。
圖 9 下定單的行為基本路線
文章來源于領測軟件測試網 http://www.kjueaiud.com/
