在臺灣，進行使用者需求訪談，就像在火車站把一個要趕著去搭車的人攔下來進行問卷.調查差不多。一開始，他可能還會基于禮貌，填寫問卷。當他需要第四次還是第五次回.答同一張問卷的話，他會覺得你是否聽不懂人類所說的語言，還是存心找他麻煩。如果.你開發一個系統，得要使用者評估個好幾回的話，God bless you。
就算使用者對你十分仁慈，沒有把你轟出去，采用iterative的做法會有的另外一個問題，.其實是在于你的系統是一個iteration，一個iteration慢慢調整，逐漸形成的。所以到底什.么算是在系統的范圍(scope)里面，其實很難界定。所以如果使用者覺得這個iteration的.成品，與他原始需求還有距離，你大概都會被迫再多幾個iteration。而這幾個iteration，.是收不到錢的。這跟以前的所謂螺線型的開發方式，在臺灣遇到的困難是一樣的�？蛻�.不會因為你多做了幾個循環(cycle)，而多給你錢。然而，你會因為多做了幾個cycle，投.入超出預期的人力與時間。
事情多做了，可是賺不到錢，這怎么劃算呢?要知道，開發項目跟開發產品是不同的。.開發項目，就是要在最少的資源之下，提供給客戶一個可以接受的爛貨�？梢曰�100萬.就讓客戶愿意結案，絕對不要花101萬，讓客戶擁有一個比較好用的系統。越好用的東.西越難做，出槌的機率也越高，為什么要這樣做呢?
除非今天客戶是人力外包，花錢買你的人月，去幫他開發。這個時候，當然是盡量選擇.可以做得長長久久的方式來開發啰。
所以我覺得應該要以項目的特性來選擇項目開發方式。大部分的項目，應該用傳統的軟.件生命周期開發方式來開發。- (待續)
**使用者或者是客戶的信息人員，看不懂相關的文件**
開發項目到底會遇到什么樣的客戶?其實就像是跟網友見面差不多，還沒有看到真人，你永遠不知道哪個每天跟你聊天分享心事的超級美女，其實是一個中年男子。就算你運氣好，以前已經跟這個使用者接觸過，彼此混的很熟，還是有可能會發生變化。
如果以前的項目做得好，這個人有可能升官，所以他就不會做這個專案了;如果以前的項目做得不好，有可能這個人就被列入下次裁員的黑名單里，所以他也不會做這個項目。更不要提有些時候，你是跟一些從來都沒有打過交道的人一起開始做一個新的項目。
既然我們在描述的對象是項目，大部分的項目，都是從需求分析開始。使用者便會提出他們的需求，系統分析師聽到使用者的需求以后，就會開始把他所收集到的需求寫成文件，接著會去跟使用者確認需求是否便是如此。
采用use case driven的OOA(object oriented analysis)，你會請使用者確認的文件，當然就是use case。
接著你會依據use case，開始進行OOD(object oriented design)。當你畫好sequence diagram, class diagram，你可能會希望客戶的信息人員，可以幫忙確認，這些文件所描述的系統，是否正確。
問題是，大部分的使用者，以及客戶的信息人員，其實并沒有足夠的能力，來確認這些文件的正確性與完整性。因為你所提供的文件，他們看不懂。通常需要你的帶領，才看得懂。當他們需要靠你解釋才看得懂時，這時候通常會有一些問題隨之產生。他們通�？梢蕴舫鰧I領域上的錯誤，可是他們通常會忽略掉整個系統的完整性。因為他們會覺得，你所沒有描述的東西，可能寫在另外的文件中。所以如果你提供的文件有錯，通常是你所提供的文件可能不完整，其實要到蠻后期的時候才會發現。這時候修改的成本就會變得非常高了。
為什么采用use case來描述一個系統，通常會發生遺漏呢?或許我們應該先看看use case是什么。
根據我的一知半解呢，use case就是嘗試著用文字來描述系統與外界之間的交互作用。對于沒有看過use case的人來說，我在此舉一個例子來說明。書上最�？吹降睦幽�，就是一個人用提款機在領錢。雖然我沒有寫過類似的程序，我可以想象一下，這個use case應該包含的內容。
1.Brief Description
這個use case說明，怎么樣透過提款機來領錢。
2.Flow of Events
文章來源于領測軟件測試網 http://www.kjueaiud.com/
