敏捷需求建模

1、敏捷需求建模來源：LinuxA 作者：axing  版權申明：本文的翻譯沒有獲得作者的授權，所以這篇譯文僅作為學習使用。禁止任何人轉載此文獲作為商業(yè)用途，如果有任何人認為這篇文章侵犯了你的權利，請來信告訴我們。Table of Contents· Where do requirements come from?· Some philosophy· Types of requirements· Potential requirements artifacts· A usage-centered approach· Initia

2、l requirements up front (IRUF)· Detailed requirements modeling· Overcoming common requirements modeling challenges· Tips· References and Suggested Reading· Footnotes  Where Do Requirements Come From?    你的項目涉眾（直接或非直接用戶、經理、高級經理、操作人員、輔助人員、測試員、開發(fā)人員

3、）是最正式的需求來源。事實上，項目涉眾有義務提供、闡明、詳細說明需求并劃分優(yōu)先級。同時，項目涉眾有權利要求開發(fā)人員確認、理解這些需求。這個概念是你采用敏捷方法建模成功的關鍵：項目涉眾提供需求，開發(fā)人員理解并實現需求。    那這是不是意味著你只要呆呆的坐著等你的項目涉眾把需求送上門來呢？當然不是。你可以就他們告訴的事項不斷的提問，組織一次分析活動來論證這些事項，激發(fā)他們說出大量的細節(jié)，有時候，他們會從你的問題中得到啟示，回過頭去思考自己原先提出的需求。你也可以給他們推薦新的功能，注意，這只是建議，他們可以接受（可能有部分修改）或是拒絕這種需求。為了鑒別出

4、潛在的需求，你通常需要涉眾的幫助，閱讀現有的文檔（如公司政策手冊），分析現有的系統(tǒng)，查看一些公開資源（網站、書刊、雜志文章，甚至你的競爭者的產品和服務）。再一次申明，你的項目涉眾是最終的需求來源，是他們！而不是你來決定該做些什么。這一點非常重要！切記！    可是你的項目涉眾的靈感又源自何處呢？他們通常都會堆現在的環(huán)境有著這樣或那樣的抱怨?？吹接行┦虑楦偁帉κ帜茏龆麄儾荒茏?，他們會說，“我真希望我能夠那樣做。”；他們希望不要再遇到另一個系統(tǒng)中遇到的老問題；他們可能僅僅只是對未來有一個美好的愿景。對某一些涉眾來說，特別是操作人員高級IT經理，希望能夠整合

5、現有的系統(tǒng)，希望能夠由組織的IT策略來推動需求，例如在組織中削減原來的數目眾多的各類操作系統(tǒng)。你的項目涉眾需要在一個大范圍的輸入的基礎上來提出正式的需求，這通常會發(fā)生在提問的時候。    我還發(fā)現，如果讓一些相關專家對目前正在構建的系統(tǒng)提供一些專家意見有助于發(fā)掘出一些潛在需求。例如，在一個電子商務系統(tǒng)的案例中，我就曾引入國際性組織設計專家、稅務法律專家以及物流專家。當你的組織構建的系統(tǒng)包含了很多你不熟悉的方方面面的時候例如你的電子商務系統(tǒng)是你希望進軍國際客戶的第一次嘗試這種方法就特別的有效。我也常常邀請外部的專家花上一兩天的時間來我們的項目中做咨詢。這樣

6、，我們的項目涉眾的頭腦就會被“激活”，這就避免了一些因為我們的不專業(yè)而造成的惡果。這是個非常好的辦法，它使得我們能夠超越基礎，特別是我們在定義項目得初期范圍的時候，它還能使得我們的項目涉眾跳出現有環(huán)境的框框去思考。 不過，我們也要認識到這種方法存在風險：一個外部專家提供的建議雖然悅耳但現在可能并不合適，換句話說，工作還是要自己做，外部專家的意見只是你參考的依據罷了。 Some Philosophy    當你在做需求建模的時候，最關鍵的實踐就是“涉眾的積極參與”。為了保證這項實踐的進行，有兩點是非常重要的：你的涉眾提供需求的有效性以及他們參與建

7、模的積極性。我的經驗是你的項目團隊對你的項目涉眾一定要有足夠的權限。這可能需要你的項目涉眾提供現場指導，還有你的用戶、潛在用戶（如果你是在開發(fā)一個面向公眾的產品的話）也一樣，你必須要能夠很清楚的和他們談論。是的，找到這些人可能很難，想想辦法。在Overcoming Common Requirements Challenges一文中我談到了一些開發(fā)團隊經常面對的普遍問題，包括對項目涉眾沒有足夠的控制權限。我的哲學觀就是如果項目涉眾不能或是不愿參與的話，這就暗示著你的項目缺乏成功的內部支持，你要么解決這個問題，要么就結束這個項目以使損失達到最小。缺乏上述這些策略的任何一個，你就不用在這里空談說要采

8、用AM方法從事開發(fā)了（涉眾的積極參與是一項核心實踐，因此你必須采用，這樣才能確保你確實在做AM）。    對于一個項目涉眾來說，何謂“積極參與”？圖1表述了一個需求過程的高階視圖，使用UML活動圖的符號來表示開發(fā)人員和項目涉眾的任務。虛線把圖分為兩個泳道，表示過程中的每個角色所負責的不同事務。在這個案例中你就可以看到所有的注意和建議都是項目涉眾和開發(fā)人員一起處理的，他們共同討論潛在需求，然后為需求建模的編制文檔。項目涉眾單獨負責為需求排出優(yōu)先級，因為系統(tǒng)是為他們而構建的，所以他們是有權利排出優(yōu)先級的唯一人選。同樣，開發(fā)人員負責評估實現一個需求的成本，因為

9、他們是真正做這件事情的人。把別人的估計強加于開發(fā)人員頭上既不公平也不合理。盡管排定優(yōu)先級和估算需求工作量并不在AM的范圍之內，但是這是屬于你的AM應用的更底層、更實質的過程（如XP、UP）的范圍之內。所以了解這些任務是你的需求工程的及其關鍵的方面是非常重要的。圖1.需求工程過程概覽圖（以UML活動圖描述）我的哲學觀認為項目涉眾應該參與需求的建模和文檔化，不是僅僅停留在提供信息的階段，而是應該參與到工作中來。是的，這要求開發(fā)人員的一些培訓、指導、訓練，但這并非是不可實現的。我就見過項目涉眾的建模和文檔做的非常好的，而且這種項目遍布在不同規(guī)模的組織中：小型的剛起步的公司、大型企業(yè)、政府機構中；跨越

10、多個行業(yè)：電信、金融、制造、軍事。為什么這一點特別重要呢？因為只有你的項目涉眾才是需求的“專家”。他們清除他們想要什么？而且只有你試過，他們是可以學會如何為需求建模和編制文檔的。這從敏捷的觀點上來看也是有道理的：它把建模的努力、成就分到了更多人的頭上。為了使項目涉眾更容易的、更積極的加入到需求建模和需求文檔化的活動中來，為了減少商業(yè)術語形成的隔閡，你需要進行一項實踐：使用簡單工具。在表格1中列出的很多需求工件的建模可以使用簡單的工具，也可以使用復雜的工具有一欄列舉出了每一個工件的簡單工具。圖2和圖3就向我們展示了兩個使用簡單工具建立的模型。圖2中使用了使用了即時貼和活動掛圖來建立需求模型，而圖

11、3使用索引卡片來進行概念建模。只要你在需求建模中使用了新的技術例如使用畫圖工具來創(chuàng)建用例圖的各個版本，或是使用功能多多的CASE工具你就會在無形中將你的項目涉眾排斥在外，因為他們不僅要學習建模技術還要學習建模工具?！氨３趾唵巍?，這樣你就鼓勵了大家的參與，也增加了有效合作的機會。圖2.基本用戶界面原型圖3.兩張CRC卡片    我素來堅信需求是和技術無關的。當聽到諸如面向對象需求，結構化需求，甚至是基于組件需求之類的術語的時候，我困惑不已。這些術語，面向對象，結構化，基于組件，都是實現技術的分類。雖然你可以從這些類別中選取一個來實現，這可能也會限制你，但是

12、至少，你必須要關心需求。所以，只有需求。我下面所描述的所有的技術都是用來為這些類別的系統(tǒng)建立需求模型的。有時候你可能沒有辦法做到技術無關的需求。例如，大多數的項目來都有一個普遍的限制，就是不論可能與否，都必須利用現有的技術構架。其實，在這個層次上，需求仍是技術無關的，但是如果你要深究下去，開始列出一張現有構架的組件清單的時候例如，你的your Sybase vX.Y.Z 數據庫或是你必須整合一個現有的SAP R/3模塊你就過線了。只要你懂得該做什么和不該做什么就OK了。    始終牢記，“片狀思考”。小片的需求例如功能（features）和素材（user

13、 stories）要比大型的需求例如用例（use case）更容易預估。平均每一個用例描述的功能性要比素材多，所以我們認為用例要大型一些。    同樣，在你投資建立需求可跟蹤矩陣之前你也要考慮清楚?？筛櫺允歉鞣矫娴捻椖抗ぜ?lián)系在一起的一種能力，而需求可跟蹤矩陣就是一種被用來記錄這種聯(lián)系的工件它開始于你的獨立的需求，貫穿了你建立起來的那些分析模型，架構模型、設計模型、源代碼和測試用例。我的經驗是有跟蹤能力文化的組織常常是定期的更新這些工件，而不是當發(fā)生時才更新，這樣才能保持這些工件（包括矩陣）之間的一致性。擁有這樣一個矩陣的好處是但你在需求變化的時候能夠

14、較容易做影響分析，因為你知道這項變化會影響到系統(tǒng)的哪些方面。可是，如果你的系統(tǒng)只有幾個人熟悉，而你想要提高系統(tǒng)的效率，那么更簡單、更廉價的做法就是簡單的告訴你的開發(fā)人員預估這種變化的成本。以我的經驗，建立這么一種需求可跟蹤矩陣常常都是得不償失，即使你有專門的工具來實現，依然無法超過它所付出的代價。讓你的項目涉眾了解建立這種矩陣的成本和收益，由他們自己決定。畢竟，可跟蹤也屬于文檔，應此是一個業(yè)務決定，一個應該由涉眾做出的決定。 Types of Requirements    我相信需求可以分為兩類：功能性和非功能性。一個功能性（behavior

15、al）需求描述了用戶如何和系統(tǒng)交互（用戶界面 user interface issues），他們怎樣使用系統(tǒng)（用法 usage），系統(tǒng)怎樣完成一個系統(tǒng)功能（業(yè)務規(guī)則 business rules）。一個非功能性（non-behavioral）需求描述了系統(tǒng)中的某個技術特征，特別是那些和可用性、安全性、性能性、交互性、依賴性、可靠性有關的技術特征。有一點需要清楚，功能性和非功能性需求之間的界限有時候并不清楚。一個描述數據存儲速度期望值的性能需求看起來似乎很明顯是一個實質的技術指標，但是它又可以反映為用戶界面的響應時間，這就關系到可用性和潛在用法。訪問控制，例如允許誰訪問特定信息， 很明顯是一個非

16、功能性需求，但是它通常被認為是一個安全性問題而被歸入非功能性需求這一類中。不過，對這種問題沒有必要死扣，有大致的概念就好了。關鍵的還是你要鑒別和理解給定的需求，至于你將需求分錯了類，哼哼，Who Care？Potential Requirements Artifacts    由于這里有好幾種不同的需求類型，也許其中的一些（或全部）適合你的項目。另外，每一種建模工件都有它的長處和短處，你需要掌握好幾種需求建模工件來豐富你腦中的工具箱。表1總結了一些通用的需求建模工件，工件的細節(jié)是在另一篇論文Artifacts for Agile Modeling.中討論

17、的。你可以使用簡單的工具來創(chuàng)建各種不同類型的需求的模型。（關于使用簡單公交互的重要性可以參考前面的小節(jié)Some Philosophy）。記住重要的一點：雖然你可以使用各種各樣的工件來收集需求，但是這并不是意味著你在一個項目中要全部用上這些工件。原則“了解你的模型”建議你在合適的時候再去了解如何使用這些工件。關于這個方面，你可以按照實踐“運用合適的工件”所說的來。處于在需求工程下方的過程會影響工件的選擇。在我的主頁上我建議AM應該和其它的軟件過程配合使用，例如XP或是UP，這些都是完整的生命周期。下層的過程通常會偏向于使用某一種需求工件。例如XP的素材和UP的用例。這是你進行需求建模的時候必須要

18、考慮的一個問題。這方面的細節(jié)可以參考我的論文AM and XP 和 AM and UP。 A Usage-Centered Approach    究竟你應該怎樣用敏捷的辦法來建立需求模型呢？讓我們來看一個例子，在這個案例中你將通過SWA Online case study.學習如何為需求建模。在我們正式開始之前，有一些問題我們需要先了解。第一，因為這篇文章的焦點集中在需求建模上，所以其它的一些討論，如涉及到分析模型、架構模型、設計模型之類的都不在我們的討論之列，這種情況下，我們會適時的結束討論并回到我們的主題上來，同時會給出相關的文章的導引。

19、敏捷軟件開發(fā)是以迭代為基礎的，結果是需求建模和其它的建?；顒娱g的界限非常模糊。第二，我們采用的方法只是眾多敏捷方法中的一種。記住，AM只是一種以實踐為基礎的方法，而不是那種定義了許多的細枝末節(jié)，告訴你這怎么做，那怎么做的方法。所以有許多方法能夠實現目的。不用擔心，我會給你指出一些備選的方法，但你自己需要保持一顆開放的心。第三，由于SWA Online團隊采用的過程主要是根據EUP（Enterprise Unified Process）制定的，所以工件也會以用例為主，在需求建模中會大量使用它。而在XP方法中，素材會反之占有絕對的優(yōu)勢。一樣的，對這點你也不用擔心，在AM and XP一文中，我們也

20、詳細討論了從XP的觀點來看待這種案例的學習。第四，在我寫這一節(jié)的時候，我發(fā)現它看起來是那么的真實，就像是發(fā)生在我們周圍的一個活生生的例子。不過，事實上，它只是根據我在構建電子商務系統(tǒng)中的經驗虛擬出來的。第五，我們最好把需求工程分成兩個部分來考慮：初始需求階段（IRUF initial requirements up front）和細節(jié)建模階段。  The Initial Requirements Up Front (IRUF) Phase    初始需求階段發(fā)生在你的項目的生命周期的開始階段，即在RUP（Rational Unifie

21、d Process）（Kruchten, 2000）中被稱為先啟的階段，XP中的第一次迭代之前。在IRUF階段有三個主要的目標：首先是在一個高層的層次上定義系統(tǒng)范圍，這樣你就可以找出系統(tǒng)的邊界其次是為系統(tǒng)定義高階的需求；最后是在你的涉眾和你的開發(fā)人員中取得一致意見，保證需求的順利進行。IRUF階段可能非常的短，也許只有幾個小時，特別是你的涉眾和你身處同一場所，而且涉眾對系統(tǒng)很快的達成了一致的意見。如果不是這么完美的化，這個階段也有可能會延展到幾天甚至幾個星期。特別是你需要召開大型的建模會議，集中討論IRUF階段的幾個目標。這種需求會議的特點包括：· 很長，一些大型的項目甚至可能會達到

22、幾天。· 需要很多的涉眾參與，以保證聽到的需求是最大范圍的。· 通常是比較正式的（常常是由于人數較多，或是項目涉眾間比較不熟悉的緣故）· 包括一些開發(fā)人員，特別是你希望你的團隊能夠理解你的系統(tǒng)的時候。    系統(tǒng)的范圍可以用一句簡單的語句來描述，在SWA Online的這個例子中我們就可以簡單的描述為“通過因特網向顧客銷售產品”或是更復雜一些的語句“把真實的而不是虛擬的產品銷售給美國的客戶，包括了舊客戶和新客戶”。系統(tǒng)范圍也可以使用一個上下文模型來描述。模型現實你的系統(tǒng)如何適應整體環(huán)境，可以使用用例圖來描述（如圖5），也可以

23、使用DFD圖來表示（如圖4）（這種的DFD圖通常被稱為0級DFD圖）。了解系統(tǒng)的范圍很重要，這樣你就不會做一些超出系統(tǒng)范圍的無用功。第一個敘述就顯得太含糊。我們可以認為比起美國本土的客戶，你的精力更多的放在因特網客戶身上，同樣，我們也可以認為你會銷售虛擬產品，例如在線音樂。這就要求你除了物理遞送網絡之外還需要一個在線的遞送網絡。你也可能會發(fā)現你的范圍時刻都在變化，所以你的項目涉眾需要做出決定，而且必須要做到擁抱變化。圖4.DFD圖：用以建立SWA Online的上下文模型圖5.用例圖：用以建立SWA Online的上下文模型    那什么是描述系統(tǒng)范圍的

24、最好的工件呢？陳述語句，DFD圖，還是用例圖？這取決于你的具體情況。陳述語句非常直接，但是不如圖那么清晰。圖4的DFD圖顯示，圖的正中是系統(tǒng)，旁邊是外部實體，如組織，人，其他系統(tǒng)。這些外部實體雖然不是系統(tǒng)的一部分，但是它們都和系統(tǒng)有關，各實體之間的線段表示它們之間的關系。這種方法的最大好處就是很清楚的顯示了系統(tǒng)和外部世界的信息的主要流動的細節(jié)。圖5的用例圖則是體現另一側面的系統(tǒng)，它同樣在正中描述系統(tǒng)，旁邊是和系統(tǒng)發(fā)生聯(lián)系的角色（組織。人）。這種方法的主要優(yōu)勢是同時描述；阿外部和內部的，和系統(tǒng)交互的角色。而不是象DFD圖那樣只能描述系統(tǒng)外部的方面。而它的主要缺點是它不能描述系統(tǒng)和角色的交互的細節(jié)

25、。那我們該采用哪種圖示呢？既然有優(yōu)點又有缺點，我們是不是應該兩者都采用呢？Hmmmm這不過是中庸的想法罷了。一個比較好的辦法是只畫一張圖，打破規(guī)則，把兩張圖好的地方拿出來合成一張圖，就像我在圖6中的那樣。注意到了嗎，我在屬于內部實體的兩個實體的左上方做了一個“I”的標記，這是我自己的風格。另外，我還是用數字來標記每個實體。不過，數字標記手工并不好處理，我寧可額外加一個規(guī)則，每個實體姓名都是唯一的，這樣的化，它就能夠起到數字標記的作用了。我也可以很容易的在DFD圖中使用用例圖的符號。我使用用例圖的規(guī)則來表示DFD圖的數據流。因為我的項目涉眾比較偏愛DFD圖，所以我也尊重他們的偏好。記住這個原則：

26、“建模要帶有目的性”，它建議你了解你的聽眾，選擇一個最適合他們的工件。    不要懼怕打破規(guī)則。盡管一般實踐告訴我們在0級的DFD圖中不要包含內部實體，但是在這個例子中，你開始挖掘細節(jié)的時候，你就必需要介紹內部實體。我在圖6中這樣做，就避免了再畫一張圖。再說了，沒有采用嚴格的建模策略，地球也不會消失啊。是的，這種觀點和我的另一個原則“運用標準的建模準則”相矛盾，但是這樣做，我可以同時降低開發(fā)和維護的費用。所以標準成為一個大問題的話，我的組織中就要重新考慮這些標準了。圖6.SWA Online 模型的DFD圖，包括了內部的實體  

27、60; 為了能夠確定系統(tǒng)的高階需求，我比較傾向于采用一個“以用法為基礎”的方法。你的主要注意力都要集中在你的用戶如何使用你的系統(tǒng)工作上。我的經驗告訴我，這對于軟件開發(fā)來說是一個非常有效的方法。想想看，如果你連用戶如何使用你的系統(tǒng)工作都不了解，那你聲稱說你的系統(tǒng)能夠改進他們的工作方式，不斥于是天方夜譚。這種方法可以適用于你組織內部使用的商業(yè)應用，適用于你組織的客戶使用的商業(yè)軟件，適用于包裝銷售的軟件（如CASE工具和文字處理器），適用于數據倉庫的開發(fā)，適用于COTS（commercial off the shelf）的系統(tǒng)集成（如SAP的R/3系統(tǒng)、Oracle的金融系統(tǒng)）。在一個數據

28、倉庫的案例中，最常犯的一個問題是收集“數據需求”，列出人們需要在數據倉庫中存儲的data element和data entity。這種方法表面上似乎并沒有什么不妥，但是如果你不知道這些數據是用來做什么的，你就很難對你的努力排出優(yōu)先級，你也無法了解你的項目涉眾到底需要些什么。在COTS系統(tǒng)的案例中，你也同樣需要這樣的需求來評估你需要使用的軟件包。表1中列出的那些工件，功能、使用情節(jié)、用例、素材，都是非常好的選擇。根據實踐“使用最合適的工件”，我會選擇用例來描述SWA Online系統(tǒng)，因為SWA公司是使用EUP作為軟件過程的首要基礎，所以我選擇用例正好適應于這種狀況。如果他們選擇XP作為首要基礎

29、，那素材就成為最合適的工件。同樣，如果首要基礎是FDD（Feature Driven Development）(Coad, Lefebvre, DeLuca, 1999) ，功能也會是最佳選擇。    圖7就是我和我的項目涉眾一起創(chuàng)建的高階用例圖，是在白板上畫的，然后用數字處理的。這是個基本用例圖，因為它和技術無關，這意味著它可以手工實現，也可以自動化實現。是的，用例“登記產品復核”這個名稱似乎換成“記載產品符合”更好一些。但是我的項目涉眾認為這個詞對他們更加貼切。我總是努力的做到需求和技術無關，但是現實是許多的系統(tǒng)都被限制在某一種架構中，如SWA On

30、line就限制在一個基于因特網的解決方案。所以花時間把系統(tǒng)從這種限制中脫離出來抽象為一個真正的技術無關型的系統(tǒng)是沒有很大的價值的。記住這個原則“讓你的涉眾的投資最大化”，把你的需求建模的努力花在能夠提供真正價值的工作上。圖7.用例圖：SWA Online的高階用例圖    在IRUF 階段，用例應該描述的簡單一些，只要能夠描述出每個用例的邏輯要點就可以了。你不必要在這個時候描述出系統(tǒng)的所有細節(jié)，你緊緊需要了解系統(tǒng)應該完成的任務的一個基本認識，以及系統(tǒng)最初始的范圍和每個用例和角色的概要描述。如果你的項目涉眾允許你不需要在IRUF階段太過深入，你可能只需要識

31、別出3或4個用例就已經足夠了。這就是原則“目的建?！薄＝酉聛砟憔涂梢越Y束你的IRUF階段，將精力集中到細節(jié)建模，針對先前的識別的需求討論如何建模和實現。注意，相較采用UP的項目而言，這種做事的順序對于一個采用XP的項目會更加自然一些。    在圖7中，你可以看到我在需求建模圖中應用了UML的版型（stereotype）<<Include>>。然而在The Object Primer 2/e (Ambler, 2001a) 一書中，我推薦說這種版型最好是在分析這個層次上使用，尤其它被引用在系統(tǒng)用例圖中的時候。這是因為這種版型通常反映

32、出一種架構或是設計的問題，而這并不是需求階段的用例圖需要關心的。還是那句話，不嚴格的遵循開發(fā)策略，這個世界也不會因此而遭受滅頂之災。這個用例圖的有趣之處就在于我把其中的一些交叉引用的共通部分提取出來。這反映了我同時考慮了需求和分析兩方面的問題的事實。    在你的項目涉眾中達成一致的意見，這一點知易行難。這方面的具體信息可以參閱我的overcome the common challenges to requirements efforts。每個的項目涉眾都有不同的背景，不同的權限級別，不同的選擇。要想在不同的人之間達成一致性，每個人都要認識到差異性的事實

33、，交流他們對系統(tǒng)的需要，傾聽其他人的意見，準備好共同向一個目標努力。不論何時，我們在團隊合作的時候，總是會在一致性上遇到問題。這時候，我們會在白板上寫下每一個人的問題，所有人都可以看到這些問題，并討論這些問題。這樣就真實的再現了涉眾們的差別，并給他們提供一個集中討論的平臺。有時我會把一個問題從白板上去掉，因為問題的提出者意識到他的問題是不需要或是重要性不能夠和其它的問題并列的。我也喜歡在一些對立的問題之間畫上直線，這樣大家的注意力都會集中到這上面來。使用特別的顏色或標記也能夠達到這種效果。當小組在討論高階使用需求的時候，除了考慮系統(tǒng)的技術需求和業(yè)務需求，他們還要識別出相關的業(yè)務規(guī)則和限制。在I

34、RUF階段，你應該“存放”一些系統(tǒng)規(guī)則、限制和技術需求，通?？梢园阉麄冇涗浽诎装宓幕顒訏靾D上，獲取足夠的信息以供你在探索更多的細節(jié)的時候了解需求。目標是盡可能快的結束IRUF階段，這可以避免花費過多的時間追尋細節(jié)。如果你在初始需求階段就開始討論細節(jié)，你就會陷入分析麻痹的危機之中你的時間會浪費在分析細節(jié)上面。記住這個原則“軟件才是你的主要目標”，不要把你的精力都放在建立模型和文檔上面，不斷的描繪你的軟件會是一個什么樣子。舉個例子，在SWA Online這個項目的初始需求會議中，我的項目涉眾也會識別出一些和訂貨相關的業(yè)務規(guī)則和限制，如如何打包某種類型的貨物，有些貨物有它的限定的裝柜期限，還有裝船的

35、過程要求。不管在什么時候，我聽到這些需求就會讓人把它記錄下來，可以記在白板或索引卡片上，這樣大家都可以看到。    這引出了一個很重要的觀點：建模會議是交互式的。每個人都要參與。剛開始一個有經驗的建模者要做一些工作，解釋一些技術，“刺激”人們了解。這種“刺激”可能非常的容易，例如讓他們來到白板前解釋我們談論的內容，把業(yè)務規(guī)則的內容填寫進一個索引卡片，或在即時貼上記錄一張可能的報表所需要的數據。當人們熟悉了這種建?；顒拥捻樞?，在對AM的“涉眾積極參與”的實踐都有了一致的了解之后，你就會發(fā)現你不用需要“刺激”他們了。是啊，任何人一開始都會害羞，需要某種形式的

36、“刺激”，這是人性。當你的團隊在為當前的版本識別需求的時候，他們可能還會識別出未來的版本中的一些需求和一些未來的一些潛在需求。不要放過這些信息，盡管你現在既不希望花過多的時間來探求，也不希望你的軟件為了去適應這些潛在需求而變得龐大。然而，這些信息對你的架構是有幫助的潛在需求有利于在不同的架構中選擇有益的架構。變更案例（Change cases，Bennett, 1997; Ambler, 2001a）是用來將潛在需求文檔化的簡單技術，你可以在圖8中見到SWA Online的兩個變更案例。你確定范圍的一個重點是識別出哪些在范圍之內，哪些在范圍之外。并且把潛在需求識別為一個變更案例，你就顯示的聲明

37、了他是屬于項目范圍之外的。變更案例在架構需求中的有效使用方面的討論可以參看我的Agile Architecture essay. 變更: 擴張進入北美市場可能性: 非?？赡茴A計時間: 12-18 個月影響:· 運輸需要支持加拿大和墨西哥的客戶。需要新的托運人關系· 需要計算相關的稅和關稅。· 由于法律問題和當地習俗，在這些市場上的產品銷售可能不一樣· 支持多種語言的站點（加拿大的官方語言是英語和法語，墨西哥的官方語言是西班牙語）變更: 銷售虛擬產品（在線音樂，視頻，書籍）可能性: 非?？赡茴A計時間: 6-12 個月影響:· 和物理運輸

38、過程不同· 需要支持一些產品的數字授權· 個別產品會有限制（有效期限、拷貝數量） 圖8. SWA Online的兩個變更案例.      那么你準備用多少的文檔來記錄你了解到的項目范圍和項目的高階需求呢？就像我在Agile Documentation中建議的那樣，夠用就行了。在SWA Online的案例中，我會建立一個HTML頁面，包含了圖6中的上下文圖，圖7中的用例圖，以及一個哪些在范圍之內，那些在范圍之外的列表。對于高階需求文檔，我會把用例描述轉錄為文字處理器格式，或簡單的text文件，因為我們在進行

39、模型細化的時候會繼續(xù)發(fā)展它們。把他們存放為電子文檔的形式便于共享和操作。至于我們?yōu)榱藰I(yè)務規(guī)則，限制，技術需求和變更案例創(chuàng)建的索引卡片，我希望它們能夠保持這種形式，因為我們在細節(jié)建模工作中還會精化它們。如果我們確實需要，我們可以隨時將之處理成為我們需要的格式。這樣，你的團隊就可以迅速的進入細節(jié)建模的階段，然后進入實現。因為他們避免了創(chuàng)建其實并不需要的文檔。（特別是有一些業(yè)務規(guī)則其實是錯的，這樣在你知道它們的真?zhèn)沃鞍阉鼈儗懭胛臋n的努力就都白費了。）Detailed Requirements Modeling    一旦IRUF階段的成果系統(tǒng)的范圍和高階需求

40、得到首肯，你就需要為你的需求排出各個迭代周期并安排開發(fā)任務。  Starting an Iteration    在迭代開始的時候，所有的需求都需要分配到每個開發(fā)人員頭上。在一個XP的項目中，開發(fā)人員會根據自愿性原則，簽署某個素材，并組對開發(fā)。這個過程不停的重復，直到本次迭代的所有素材都已經完成。而在一個UP項目中，團隊的工作方法可能和XP中的差不多，或是由項目經理把需求指派給個人或子團隊。先不考慮分派任務的具體情節(jié)，對于子團隊/組對開發(fā)者而言，他們現在的任務就是需要實現需求。而他們要做的的第一件事情就是了解項目涉眾需要的細節(jié)，其中有

41、些也需要做需求建模。這里有兩種基本可以適用于如何在迭代開始時建立開發(fā)團隊：1. 本次迭代需求群組建模. 采用這種方法，整個團隊，包括項目涉眾，共同工作探尋需求細節(jié)，分析需求，建議需求當前系統(tǒng)以支持這些需求?？紤]到你的迭代跨度約為2周，這種建模會議的長度保持在1個小時到半天的長度就可以了。如果你的迭代跨度較長，例如4到6周，你可能需要在一開始投入一整天的時間。不要想用超過一天的時間來做這項工作，那并沒有很實際的意義。這種方法的優(yōu)點就是在本次迭代中給團隊豎立起了一個具體的愿景，他們打算如何完成自己的工作，收集了所有團隊成員的意見。這樣，在初期確定一個良好方法的幾率就大大增加了。這種方法的缺點則是它

42、只適用于較小的團隊，特別是少于10人的團隊，而且它對所有的個體來說實際上是浪費了時間，因為并不是所有人都會參與項目的各個方面。注意，一旦本次迭代的初始建模工作完成，各個子團隊仍然需要在適當時間建立和他們有關的細節(jié)模型，當然，這也是屬于本次迭代中的。2. 子團隊獨立需求建模Individual subteams model their requirement(s). 有一些開發(fā)團隊并不采用上述的群組建模，而是簡單讓各個子團隊來負責實現。這種情況適用于每個需求之間沒什么聯(lián)系，或是聯(lián)系不大。這時，開發(fā)人員遵循“集體所有制”（Collective Ownership）的實踐，共同在一個共享代碼庫上工作

43、。這種方法的優(yōu)點就是是你的團隊能夠在迭代一開始就迅速的進入細節(jié)問題中。然而，他也有一些缺點。首先，需求可能交迭，也許兩個子團隊都在做和計算訂單總量有關的事情（例如一個團隊計算稅率，一個團隊計算折扣），這樣你就可能冒重復工作的風險。這可能并不是一個很嚴重的問題，因為每個子團隊都應該要能夠了解其它子團隊的工作而根據需要共同工作。其次，你的團隊需要比較多的時間來固定實現愿景。再次，你一開始就要決定項目涉眾的“所有權”，因為所有的子團隊都需要項目涉眾的“米”來下鍋。During An Iteration    一旦你結束了迭代一開始的工作，你的團隊就開始一連串新

44、的工作，建模、編碼、測試、構建和部署。正是在這個階段，你需要和你的項目涉眾做大部分的需求建模的工作，探索這些需求的細節(jié)。實際上，這些工作的應該更精確的說是建模會議，在需求、分析、設計中都離開這種會議。這些會議通常是以一種“即興”的方式舉行的，參加的人數也不多，大多由負責這個需求的開發(fā)子團隊和一個或更多的項目涉眾組成。這種“即興”的會議的開始也往往是由于一些不正式的話，例如，“小強，能不能花一些時間解釋一下顧客是怎樣搜索訂單的？”    那我是怎樣在SWA Online項目中做這些細節(jié)需求建模的？首先，假設我們兩個人組對負責實現本次迭代中的“處理訂單”用例

45、，實現訂單定義和處理的最基本的動作流程，這是全過程的一部分。目前我們不用實現查找功能、錯誤和異常處理、稅率計算、折扣計算。這個最基本動作流程被我們稱為“理想之路”，因為它只是實現了最基本的動作流程。備選流程描述了當動作執(zhí)行時的非正常流程，例如在這個例子中，“客戶要求的貨物脫銷”就是個備選流程。然而我們本次迭代的目的只是要實現最基本的“理想之路”，其它的需求由其它的子團隊實現或是在以后的迭代中實現。    如圖9所示，我們做的第一件事情就是要使動作流程邏輯豐滿起來。同時我們還要建立和這個用例有關的UI原型（見圖2）。我們并行的進行這兩項工作，因為它們之間沒

46、有關系的，用例描述了用戶如何下訂單，而UI原型定義了SWA Online系統(tǒng)的用戶界面必須包含的行為。注意，用例在第二行調用了“查找商品”用例，這和圖7中的<<Include>> 版型的應用是一致的。盡管在我們正在實現的“處理訂單”用例中調用了這項功能，但是它并不在我們的范圍之內，所以我們不準備實現這項功能。為了不影響結果，我們可以直接使用一份查找的理論值清單。這項功能在項目的遲些時候會實現，但不是現在。（記住，我們是在增量開發(fā)。）另外，我們還要注意這個用例也沒有涉及任何的技術問題，這些問題我們會在分析和設計階段考慮?，F在我們只是想要了解訂貨的基本流程，遲些我們才會考慮實現（可能只是幾分鐘后。）用例還描述另一些本次迭代的邏輯流程，例如稅率和折扣的計算。  1. 當客戶下定單的時候，用例就開始。2. 客戶查找商品，使用用例“查找商品”3. 客戶選中商品后增加訂單項。4. 客戶填寫定購物品的數量。5. 系統(tǒng)自動計算每種商品的小計（單價×數量）。6. 客戶重復2到5步，直到完成訂單。7. 客戶完成訂單.8. 客戶提供他們的運送和付款信息，包括姓名、電話和地址.9. 系統(tǒng)加總每列商品小計，得到訂單總價。10. 系統(tǒng)根據計算訂單稅率的商業(yè)規(guī)則計算訂單的應付稅款。11. 系統(tǒng)根據計算折扣的商業(yè)規(guī)