·從抽象后的列表中很難看出它是否完全。它們往往忽視了許多細節。
·顧客和開發者對這個列表的理解往往完全不同。
·這樣的合同式的列表給顧客一個錯誤的安全的感覺，好像他們的要求都已列入了。但是由于這些列表本身對細節問題不能細述因此許多關鍵的細節問題實際上并未列出和解決。這些問題一直到后來軟件開發時才被發現。那時開發者一般要與顧客再次討論這些問題并試圖按他們的意愿和條件來解決這些問題。
·這個列表對此后的系統設計不提供任何幫助，它們的結構無法直接進入新軟件。
原型（Prototype）
從1980年代中開始，越來越多的人將作原型看作是解決需求分析的困難的辦法。原型模擬最終軟件的屏幕顯示，這樣用戶可以看到最終軟件將是什么樣，而實際上在這些屏幕顯示的背后還一切都空著呢。這樣顧客可以在系統還沒有建立之前就做出設計決定。當原型首次被使用的時候它們的效果被視為非常驚人。引入原型往往提高顧客與開發者之間的信息交換。原型的屏幕顯示后來往往很少被改變，因此可以大大地降低費用。
但此后十多年的實際應用證明雖然原型是一種有用的技術，但它也有它的缺陷：
·經理人員在看到原型后往往不理解為什么到還要一段時間后最終設計才能完成。
·設計師往往將拼湊在一起的原型碼用到后來真正的系統中，因為他們怕在再次編碼時“浪費時間”。
·原型幫助解決設計決定和用戶界面的設計，但是它們并不提供任何關于需求的信息。
·設計師和顧客有可能花費太多的時間和精力來設計用戶界面，而忽視對作業過程的關心。
用例是一種紀錄新系統或軟件更換時的需求的技術。每個用例包含一個系統在作業時與用戶或與其它系統之間交換信息的場景。一般用例避免使用術語，而盡量使用顧客、用戶或他們的專家的語言。一般用例由軟件開發者和顧客一起寫成。
在1990年代中用例很快地成為了紀錄需求分析的最主要的方式。尤其在它的發源地，在面向對象的程序設計中它的普及性非常高。但用例不僅可以用在面向對象的程序設計系統中，實際上用例本身并非面向對象的。
每個用例集中于描寫如何來完成一個作業目標或任務。對傳統的軟件工程來說每個用例描寫系統的一個特點。對大多數軟件項目來說一個新的系統有多個（往往十幾個）用例。不同的軟件項目的格式或項目的進展都可能影響用例的細節性。
文章來源于領測軟件測試網 http://www.k11sc111.com/
