雖然我們知道該系統使用瀏覽器進行操作，但我們不會現在就用一個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 &nb, sp; 項目甲方改變主意
項目甲方也是人，是人就會改變主意。你把家具按想象中的位置擺好，但當你回過頭來端詳一番，可能覺得這樣并沒有達到想象中的效果。象布置家具這樣簡單的事你都會改變主意，何況那復雜的系統呢。項目甲方百分之百會改變主意。
要解決這個問題，你首先得接受這個事實，擁抱變化。不管發生了什么變化，都是與建模有關的，因為你會發現要么是他們開始時不清楚他們自己的需求（參見上一個討論），要么就是你沒有弄明白他們所想要的。當你同項目甲方一同討論時，你應該從他們的角度以他們的語言達成一致的認識，這會確保你沒有作出另外的假設，而且會提高談話的質量。我曾經參加過為一個電子商務系統開發管理系統的項目，在這個項目中我們得出了一個公正而準確的需求。第一個星期，我們提供了兩個網頁：一個是主頁，上面包含了關鍵功能的菜單項；另一個實現了一個高優先級的功能。我們完全按照他們所要求的來做。當我們想他們演示以后，他們意識到最初的想法不好，然后要求我們重新構造。變化來了。最后，當用戶對系統中某一部分的想法發生改變時，你會發現實際上是由于他們沒有弄清楚需要解決的問題，這意味著需要同他們開一個關于構想的會議（參見需求建模會議的相關內容）；或者是由于某個有不同構想的甲方的意見沒有被正確處理。
難題 #5 優先級沖突
你所建造的系統必須反映多方面的需要，包括直接使用者，高級管理層，你的實施人員，支持人員，以及維護人員。各方面都有不同的優先級要求和目標，即使是同一類中的不同個體也是如此。這就會出現沖突，有沖突就必須進行處理。
再一次，首先是接受這種現象。系統的優先級需要協商而定。注意到我所說的嗎？你需要定義你系統的優先級。每個項目甲方心目中都有一個自己的優先級，這很好，但你的目的是要決定整個系統的優先級，這往往不同于他們個人的想法。一種方法是實行代表制：指定一些代表，他們每人都能代表某一大組的項目甲方，讓他們來協商作出決定。你可能想自己來支持這個協商工作，但這項工作非常耗費時間，而且有可能其結果會導致項目甲方與你和你的項目組之間形成敵意（費力不討好）。我建議盡可能地讓別的人來做這個苦差事。如果協商沒有結果，你最后一招只有尋求金牌業主（就是付錢的人）的幫助，要求他們進行仲裁。在我曾經參與的一個面向國際的電子商務系統的開發中，有些甲方設想該系統一開始就能夠支持多種語言（美國英語、英國英語、西班牙語、德語、日語和粵語）。這樣，唯有我們能服務于每個主要的市場。另外一些甲方想讓這個系統運行迅速，而僅愿意支持美國英語，因為他們覺得這對于客戶來說是可以接受的（你的項目甲方也有笨的時候）。我們不能對此達成一致，于是我將這個問題向上反應。最后的決定是第一個版本僅支持美國英語，然后在確實需要其它語種時再進行需求評估。
難題 #6 過多的項目甲方想參與進來
有時你會發現想參與的人太多了。這種情況通常發生在項目的初期，大家都抱有濃厚的興趣，或者你的項目與個人的業績相關，很多人都想沾光。最好的辦法就是感謝每個人的熱情，讓他們明白你現在得到的幫助已經足夠了，而且你已經挑選了一部分人，告訴他們以后當你需要他們的幫助時會同他們聯系。當我處于這種境地時，我會盡量挑選最合適的人選，那些能提供最好的見解而且愿意花時間同我的開發組共同工作的人。同時，我不會疏遠那些現在沒有加入進來的人，有可能在某個時候他們某方面特殊的專長正是我們所需要的，或者可以通過他們來宣傳我們的工作。一般來說，一個積極參與的項目甲方會對這個系統越來越熟悉，但同時盲點也在增加，而越來越難發覺一些潛在的問題。因此保持對合格的外部人員的聯系是頗有價值的。
難題 #7 項目甲方指定了技術方案
我曾經遇到過這樣的情形，一個項目甲方人員說我們需要使用某種技術，比如某個版本的Oracle。而此時我真正需要的是從他們那里得到行為類型的需求，比如“客戶能夠將錢存入一個賬號中”。確實，技術方面的約束是肯定存在，也是開發組應該知道的，但此時有可能他們只是想告訴你Oracle是他們組織的數據庫標準這樣一個事實。很多時候，真正的問題在于你的項目甲方難于區分系統的需求和系統架構的選擇，有可能這個人是技術出身而喜歡討論技術方面的問題，或者只是由于他們剛好從最近 一期的商業周刊上讀到一則成功使用Oracle數據庫的文章。
最好的解決辦法是定義好項目甲方的權責，制定一個適當的工作框架，以使他們能將注意力集中在定義系統需要做什么這個問題上，而開發人員則集中精力在系統如何做這個問題上。另外一種策略就是問他們“如果你已經有了適當的技術，哪它還那么重要嗎？”或者“你想如何使用這項技術”這類問題來識別實際的需求。
難題 #8 項目甲方墨守成規
許多組織中，人們多年來使用同樣的工具以同樣的方式工作著。他們可能從來沒見過另外的方式或從來也沒想過。他們對改變懷有恐懼感，可能是他們害怕沒有所需的技能來適應新的系統，也可能是擔心會被新系統取代。出于這些擔憂，他們會按照適合他們的方式給出需求。 解決這個問題最好的辦法是同他們討論目前的情形，辨別哪種方式運作良好而哪種方式不好，以及向他們講明當前形勢正在如何地發生著變化。假設在SWA Online這個項目中，某個甲方人員在確定需求時告訴你任何一個定單最多只能訂購十樣物品。什么？明顯是因循守舊。如果你就此詳細地詢問，很快就會得知他們目前的運作流程是客戶郵寄或傳真他們的定單到公司，再由客戶服務代表進行定單信息的輸入。每張定單表格只有十行，而且得知以前的綠屏幕（譯注：即單顯）系統也被設計為每屏僅允許輸入十條信息。 其實不必問這么多，你應該指出填寫紙張表格的定單是造成這個限制的真正原因，因為紙張的大小是有限的，然后向他演示你可以很輕易地實現在一條定單訂購多于十樣物品。一會兒之后，他就會認識到這完全是可能的，特別是當你向他展示其競爭對手沒有這項限制時，就更會消除他的疑慮。
難題 #9 項目甲方含糊其詞
有時因為項目甲方不愿意做出具體的答復，給出的需求非常含糊。這主要是由于他們害怕犯錯誤。他們以前的經驗告訴他們重新實現一個改變的需求要付出昂貴的代價，需求事先都必須得弄正確。這基本上是做不到的，由此他們就選擇了含糊其詞，在某些問題上不表態。
“你已經做好準備迎接變化；你的開發方式是迭代式的、遞增式的，這樣能降低變化所帶來的開銷；你的目標是為他們提供最好的解決方案，而這意味著有些需求會隨時間的過去而演化的”，要解決這個問題你就應該給項目甲方留下這樣的印象。言行一致，在實施過程中能夠接受和支持變化。日久見人心，隨著時間的推移，你項目的甲方就會認識到他們可以現在做出決定，日后如果需要可以安全地改變。當你在每個迭代過程完后交付軟件，你的甲方看見軟件隨著他們對系統理解的不斷發展而發展時，害怕表態的疑慮很快就會消去。
難題 #10 項目甲方不懂建模artifacts
絕大多數的項目甲方，可能還有絕大多數的開發人員，都沒有正式地學習過建模。很有可能他們不知道如何去看一個UML活動圖、或一個數據模型、或一個UML使用案例，因為這不是他們的日常工作所需的技能。問題在于他們需要懂得你所作的這些artifacts，這樣才能明白你所表達的意思，才能積極地加入到建模得工作中來。
首先是確定你的項目甲方需要懂得哪些artifacts，這樣才能知道你應該集中精力在哪。對此使用最簡單的工具這個做法可以幫助你。如果你爭取采用諸如索引卡片、紙張和白板這類簡單的工具建模，你就降低了甲方的學習曲線。第二步就是教給他們這些技術，我傾向于Just In Time（JIT）這種方式。即當我們在一個建模會議中第一次需要某項技術時，我會先大致地講解一下，然后就我們所討論的問題深入討論如何應用該項技術。在一個項目的開始，我會概括地講一下一些常用的建模技術，使他們對將要進行得工作有個感覺。同時也會給他們提供一些讀物，一般是The Object Primer 2/e (Ambler, 2001a)，其中詳細地講述了這些技術（譯注：隨時不忘作廣告J）。使用這種方法，我教過那些從來沒有建過模的甲方，象CRC和基本用戶界面原型這兩種簡單工具，每個都用了不到十五分鐘。對于那些復雜一點的技術，如流程圖或類模型，需要一段時間來慢慢學習。第三步是盡可能快地基于模型生成可運行的軟件并得到具體的反饋。當這些模型變為現實時，你的項目甲方一下就能看到他們寫在粘貼紙上的基本用戶界面模型變為了一個HTML頁面，CRC卡片上描寫客戶的概念反應在軟件的功能中。
難題 #11 開發人員不懂業務
一個普遍的問題是在項目的開始階段開發人員不懂甲方的業務，使得與甲方人員交流起來比較困難。這是自然的，就像建模不是甲方人員的日常工作一樣，開發人員也不是一個熟悉甲方業務的專家。這就是為什么需要兩組的人都積極地參與需求建模工作，就如三人行必有我師這條原則指出的，每個人都能為之做出貢獻。開發人員需要花時間去學習相應的業務，雖然他們隨著項目的進展最終能學會，但我們常常發現這樣太慢，必須要通過某種方式來加快這個進程。多年以前，我工作過的一家公司，他們確實地理解到開發人員學懂業務的重要性。在前三天中，我和另外一個新來的員工都是由甲方的副總裁進行培訓。這是一個數十億美元的金融機構，他們向我們描述了他們各部門的基本情況。每個副總裁每次都要花幾個小時對兩個（是的，兩個）開發人員進行培訓。如果你的組織不是這樣的，你可以找幾本與該業務相關的書籍看一下，介紹性的大專院校的教程比較理想。我認為開發人員應該廣泛地閱讀。我經常閱讀財富雜志、經濟家、Utne Reader和國家地理雜志，而不僅僅局限于The Communications of The ACM和IEEE Software這類有關軟件開發的刊物。這使得我有廣闊的知識背景，對我在進入一個新的環境時幫助很大。
難題 #12 項目甲方過于集中于某一類需求
有時你會發現甲方雖然提供了一大堆的需求給你，可能以使用案例或使用情景的形式，但對于非行為類型（或行為類型）的需求來說還不足夠。這個跡象就說明沒有找對人，或者你遺漏了某個方面的人比如操作人員和支持人員。因此，需要重新考慮需求建模中甲方人員的組合。
難題 #13 項目甲方對于需求有許多繁文縟節
許多甲方認為正式（計劃好的會議、需要他們審查和簽字的正式需求文檔和正式的講演）就是職業化的表現。我認為這是我們的軟件產業在過去的兩個時代中所形成的軟件流程理念，我們的甲方不知道有另一條路可走。這同樣也是由于信息界與商業界間的緊張關系所造成的。我們的甲方不信任我們，他們堅持要履行這許多的繁文縟節，以此獲得對他們并不熟悉的開發流程的更多控制。
你需要同他們進行溝通，向他們講解有另外一種更靈巧的方式，讓他們明白現在這種方式所帶來的問題（開發進度緩慢、沒有足夠的機會去理解需求、超支的費用… …）。問問甲方，他們真正的目的是什么。是開發一個可運行的系統呢，還是開會和制造文檔？如果是前者，肯定是它，然后問他們為什么要堅持這些手續。不要接受他們的第一個回答，應該刨根問底，找出真正的原因。如我在Agile Documentation 一問所指出的，他們不相信我們，這是他們拴住我們手腳的一種方式。接下來就是要他們相信你，一般來說比較困難，這主要看他們在以前的軟件開發中經歷了什么樣痛苦。以及要求他們去掉一些手續。然后你就要以事實證明（即交付軟件），向他們展示沒有很多的手續一樣可以取得成功。通過循環的迭代過程減少手續，直到你的軟件能夠有效地工作時交付給用戶。
難題 #14 開發人員不懂需求
“開發人員弄不懂由業務分析師和用戶建立的需求artifacts”，在沒有采用靈巧建模的項目組中，時常聽到這樣抱怨。幸運的是，在采用了靈巧建模的項目組中你不會碰到這個問題。首先，熟悉你的模型和熟悉你的工具這兩條原則告訴你，開發人員應該對所使用的artifacts和常用的工具受過足夠的培訓和有足夠的經驗。如果沒有，那么他們就必須接受培訓和指導。第二，增量改變這條原則建議你將一個系統分為許多小部分，每次針對一小塊，一個一個地建立，這也反映在小增量建模這個做法中。這避免了開發人員一次需要理解太多的需求，陷入一個大的需求文檔之中。第三，項目甲方的積極參與這一做法和三人行必有我師這一原則保證了你的項目甲方能夠向開發人員解釋他們的需求，而開發人員愿意這樣做。第四，創建簡單內容和簡單地建模這兩條原則確保了你的需求模型做到盡可能的易于理解。
技巧以下所列出的技巧能夠幫助你提高為系統的需求建模的效率，它們也遵循靈巧建模的做法：
需求的收集貫穿于整個項目過程中。大部分項目均是如此。雖然大部分的需求工作是在項目的開始階段，但很有可能你仍需要回到需求上來，直到代碼完全凍結時。記住擁抱變化這條原則。 解釋技術。每個參與的人員，包括項目甲方，都應該對建模的技術有個基本的理解。如果他們從來沒聽說過CRC卡片？花幾分鐘解釋一下它們是什么，你為什么要用這項技術，以及建立它。如果你的項目甲方不能夠使用正確的建模技術，那么甲方的積極參與也就無從說起。 使用用戶的術語。不要強迫項目甲方使用你的軟件開發方面的術語。這個系統是為他們而建造的，因此應該是你使用他們的術語來為系統建模。 樂在其中。建�？梢圆皇且豁椘D澀的工作。事實上，你完全可以寓模于樂。講些笑話，輕松一下。人處于輕快的環境中，可以更加有效率。 取得管理層的支持。為需求模型投入時間，特別是本文所講的以使用為中心的設計技術，對于許多組織來說是一個新的概念。項目甲方積極地參與建模工作，這也許對大多數的組織來說是根本文化的改變。任何涉及到文化改變的事情，沒有高級管理層的支持是不可能取得成功的。你需要取得你的信息部門以及用戶那邊管理層的支持。 采取寬度優先的方法。我的經驗是最好在開始時勾勒出系統的輪廓，盡可能大地了解系統的面貌，然后再集中在某一個小的方面。這樣做，你很快會對系統的整體有個了解，選擇好切入點。 已有的文檔是需求的很好來源。象政策手冊、政府法律、甚至于學校的教科書這些已有的文檔都是很好的需求來源。在我曾經參與的一個電子商務系統中，我第一件事就是找到一本關于電子商務方面的書來確定一些基本的需求（比如支持信用卡的交易）。記住復用已有的資源這一做法。 記住今天的用戶就是明天的分析者和以后的開發者。三人行必有我師這條原則其實也就意味著你的項目甲方在參與軟件項目的同時也在學習軟件開發的基本技能。常常會看見一個用戶先成為一個業務分析者，而后通過學習更多的開發技能而成為一個真正的開發者。因為靈巧軟件開發比以往的軟件開發方法更加強調項目甲方的參與，這種現象會更經常地發生。注視這些愿意進行這種轉變的人，給予他們幫助。有可能以后有人幫助你建立業務方面的技能，而幫助你跳出技術的世界。文章來源于領測軟件測試網 http://www.kjueaiud.com/
