一、需求矛盾
根據(jù)CHAO的權(quán)威統(tǒng)計，雖然自"軟件危機(jī)"提出以來，軟件工程方法得到了長足的發(fā)展與進(jìn)步，但在去年的軟件項目成功率仍然不足30％，絕大多數(shù)的軟件項目仍然超進(jìn)度、超成本。而在這些不成功的項目中，由于需求不清晰、需求不完整等方面的因素，占到了60％左右。
根據(jù)筆者多年來從事軟件需求捕獲、分析工作的實踐經(jīng)驗，認(rèn)為造成這一現(xiàn)象的根本原因在于客戶與開發(fā)人員之間的溝通存在障礙，雙方都以自己的角度、自己的專業(yè)術(shù)語進(jìn)行溝通，這使得大家并不能夠很好地就軟件需求達(dá)成共識。
由于幫助客戶更好地利用信息化工具提高工作效率，是我們軟件開發(fā)團(tuán)隊的責(zé)任，因此我們沒有權(quán)利讓用戶理解我們所用的語言，而是反過來，我們有義務(wù)去理解用戶的語言，站在用戶的角度看問題。
而事實上，許多開發(fā)團(tuán)隊經(jīng)常抱怨"我們的客戶連需求都說不清楚"、"我們的客戶對計算機(jī)了解太少了".多年以來，大家都習(xí)慣從自己的角度來定義、分析問題，這也就造成了軟件行業(yè)成為了一個最缺乏信任的行業(yè)，我們需要改一下習(xí)慣了。
二、現(xiàn)代需求
實踐針對這些現(xiàn)象，許多先賢們開始了實踐，并且總結(jié)出了一系列優(yōu)秀的需求實踐：
1）Use case：用例分析技術(shù)鼎鼎大名的RUP是這樣總結(jié)自己的：用例驅(qū)動，以體系結(jié)構(gòu)為中心，迭代、增量的開發(fā)過程。Use case也伴隨著RUP、UML一起名揚(yáng)天下。
用例用來描繪一個系統(tǒng)外在可見的需求情況，是代表系統(tǒng)中各個項目相關(guān)人員（風(fēng)險承擔(dān)人，Stakeholder）之間就系統(tǒng)的行為所達(dá)成的契約。
2）User Story：用戶故事、用戶素材用戶故事是Kent Beck在極限編程（XP）方法論中推薦的最佳實踐之一。它由客戶參與編寫，說明他們需要系統(tǒng)為他們做什么，一般用客戶的術(shù)語寫就，三句話左右。
3）Feature：特征這是特征驅(qū)動開發(fā)（FDD）方法論的核心實踐之一。一個特征就是一個小的，具有客戶價值的功能，通常表示為<action><result><object>。
從上面的定義來看，這三種現(xiàn)代軟件工程需求實踐無一例外地遵從兩個原則：一是站在用戶的角度看待系統(tǒng)、定義系統(tǒng)；二是用用戶看得懂的語言表達(dá)。而在筆者的實踐中，鑒于以下兩點考慮還是先在團(tuán)隊中應(yīng)用了"用例分析技術(shù)"：1）用戶故事略顯粗糙，掌握起來需要經(jīng)驗，沒有詳細(xì)的規(guī)則用于按部就班，一開始采用容易迷失方向；而用例相對來說更加形式化，易于上手；2）特征看上去很有吸引力，但畢竟相關(guān)的理論還未完整，引入團(tuán)隊實踐有些困難。
三、用例分析技術(shù)簡介
用例分析技術(shù)是Rational三友之一Ivar Jacobson先生于1967年在愛立信公司開發(fā)AXE交換機(jī)時開始研究，并于1986年總結(jié)、發(fā)布的一項源于實踐的需求分析技術(shù)。Ivar先生在加盟Rational之后，與三友合作提出了UML、完善了RUP，用例分析技術(shù)也因此被人廣泛了解和關(guān)注。
用例分析技術(shù)為軟件需求規(guī)格化提供了一個基本的元素，而且該元素是可驗證、可度量的。用例可以作為項目計劃、進(jìn)度控制、測試等環(huán)節(jié)的基礎(chǔ)。而且用例還可以使開發(fā)團(tuán)隊與客戶之間的交流更加順暢。
許多人是在學(xué)習(xí)UML的時候接觸到Use case，所以許多人都誤解其為一種圖表，把用例圖當(dāng)作用例分析的全部，其實這是錯誤的，用例描述才是用例分析技術(shù)的核心。下面是一個簡單的例子：
3.1 參與者，Actor
參與者，定義了用戶在系統(tǒng)交互過程中扮演的角色，其可以是一個人，也可以是另一個相關(guān)的系統(tǒng)。
3.2 用例，Use case
用例實例（場景）是在系統(tǒng)中執(zhí)行的一系列動作