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