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