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