一、需求矛盾
根據CHAO的權威統計，雖然自"軟件危機"提出以來(lái)，軟件工程方法得到了長(cháng)足的發(fā)展與進(jìn)步，但在去年的軟件項目成功率仍然不足30％，絕大多數的軟件項目仍然超進(jìn)度、超成本。而在這些不成功的項目中，由于需求不清晰、需求不完整等方面的因素，占到了60％左右。
下面的這幅漫畫(huà)雖然不乏夸張，但卻是能夠激起我們的深思：
根據筆者多年來(lái)從事軟件需求捕獲、分析工作的實(shí)踐經(jīng)驗，認為造成這一現象的根本原因在于客戶(hù)與開(kāi)發(fā)人員之間的溝通存在障礙，雙方都以自己的角度、自己的專(zhuān)業(yè)術(shù)語(yǔ)進(jìn)行溝通，這使得大家并不能夠很好地就軟件需求達成共識。
由于幫助客戶(hù)更好地利用信息化工具提高工作效率，是我們軟件開(kāi)發(fā)團隊的責任，因此我們沒(méi)有權利讓用戶(hù)理解我們所用的語(yǔ)言，而是反過(guò)來(lái)，我們有義務(wù)去理解用戶(hù)的語(yǔ)言，站在用戶(hù)的角度看問(wèn)題。
而事實(shí)上，許多開(kāi)發(fā)團隊經(jīng)常抱怨"我們的客戶(hù)連需求都說(shuō)不清楚"、"我們的客戶(hù)對計算機了解太少了"。多年以來(lái)，大家都習慣從自己的角度來(lái)定義、分析問(wèn)題，這也就造成了軟件行業(yè)成為了一個(gè)最缺乏信任的行業(yè)，我們需要改一下習慣了。
二、現代需求實(shí)踐
針對這些現象，許多先賢們開(kāi)始了實(shí)踐，并且總結出了一系列優(yōu)秀的需求實(shí)踐：
1）Use case：用例分析技術(shù)
鼎鼎大名的RUP是這樣總結自己的：用例驅動(dòng)，以體系結構為中心，迭代、增量的開(kāi)發(fā)過(guò)程。Use case也伴隨著(zhù)RUP、UML一起名揚天下。
用例用來(lái)描繪一個(gè)系統外在可見(jiàn)的需求情況，是代表系統中各個(gè)項目相關(guān)人員（風(fēng)險承擔人，Stakeholder）之間就系統的行為所達成的契約。
2）User Story：用戶(hù)故事、用戶(hù)素材
用戶(hù)故事是Kent Beck在極限編程（XP）方法論中推薦的最佳實(shí)踐之一。它由客戶(hù)參與編寫(xiě)，說(shuō)明他們需要系統為他們做什么，一般用客戶(hù)的術(shù)語(yǔ)寫(xiě)就，三句話(huà)左右。
3）Feature：特征
這是特征驅動(dòng)開(kāi)發(fā)（FDD）方法論的核心實(shí)踐之一。一個(gè)特征就是一個(gè)小的，具有客戶(hù)價(jià)值的功能，通常表示為<action><result><object>。
從上面的定義來(lái)看，這三種現代軟件工程需求實(shí)踐無(wú)一例外地遵從兩個(gè)原則：一是站在用戶(hù)的角度看待系統、定義系統；二是用用戶(hù)看得懂的語(yǔ)言表達。而在筆者的實(shí)踐中，鑒于以下兩點(diǎn)考慮還是先在團隊中應用了"用例分析技術(shù)"：
1）用戶(hù)故事略顯粗糙，掌握起來(lái)需要經(jīng)驗，沒(méi)有詳細的規則用于按部就班，一開(kāi)始采用容易迷失方向；而用例相對來(lái)說(shuō)更加形式化，易于上手；
2）特征看上去很有吸引力，但畢竟相關(guān)的理論還未完整，引入團隊實(shí)踐有些困難。
三、用例分析技術(shù)簡(jiǎn)介
用例分析技術(shù)是Rational三友之一Ivar Jacobson先生于1967年在愛(ài)立信公司開(kāi)發(fā)AXE交換機時(shí)開(kāi)始研究，并于1986年總結、發(fā)布的一項源于實(shí)踐的需求分析技術(shù)。Ivar先生在加盟Rational之后，與三友合作提出了UML、完善了RUP，用例分析技術(shù)也因此被人廣泛了解和關(guān)注。
用例分析技術(shù)為軟件需求規格化提供了一個(gè)基本的元素，而且該元素是可驗證、可度量的。用例可以作為項目計劃、進(jìn)度控制、測試等環(huán)節的基礎。而且用例還可以使開(kāi)發(fā)團隊與客戶(hù)之間的交流更加順暢。
許多人是在學(xué)習UML的時(shí)候接觸到Use case，所以許多人都誤解其為一種圖表，把用例圖當作用例分析的全部，其實(shí)這是錯誤的，用例描述才是用例分析技術(shù)的核心。下面是一個(gè)簡(jiǎn)單的例子：
3.1 參與者，Actor
參與者，定義了用戶(hù)在系統交互過(guò)程中扮演的角色，其可以是一個(gè)人，也可以是另一個(gè)相關(guān)的系統。
3.2 用例，Use case
用例實(shí)例（場(chǎng)景）是在系統中執行的一系列動(dòng)作，這些動(dòng)作將生成特定參與者可見(jiàn)的價(jià)值結果，一個(gè)用例定義一組用例實(shí)例（場(chǎng)景）。
一個(gè)用例應為參與者提供（實(shí)現）一個(gè)價(jià)值。
3.3 事件流
就像類(lèi)對應于對象一樣，一個(gè)用例的實(shí)例就是使用場(chǎng)景，用例就是對使用場(chǎng)景進(jìn)行抽象的總結：
1）前置條件：指在用例啟動(dòng)時(shí)，參與者（Actor）與系統應置于什么狀態(tài)，這個(gè)狀態(tài)應該是系統能夠檢測到的、可觀(guān)測的；
2）后置條件：用例結束時(shí)，系統應置于什么狀態(tài)，這個(gè)狀態(tài)也應該是系統能夠檢測得到的、可觀(guān)測的；
3）基本事件流：基本事件流是對用例中常規、預期路徑的描述，也被稱(chēng)為Happy day場(chǎng)景，這時(shí)大部分時(shí)間所遇到的場(chǎng)景；它將體現系統的核心價(jià)值；
4）擴展事件流：主要是對一些異常情況、選擇分支進(jìn)行描述。
建議大家在編寫(xiě)事件流時(shí)，注意以下幾點(diǎn)：
1）使用簡(jiǎn)單的語(yǔ)法：主語(yǔ)明確，語(yǔ)義易于理解；
2）明確寫(xiě)出"誰(shuí)控制球"：也就是在事件流描述中，讓讀者直觀(guān)地了解是參與者在控制還是系統在控制；
3）從俯視的角度來(lái)編寫(xiě)：指出參與者的動(dòng)作，以及系統的響應，也就是第三者的角度；
4）顯示過(guò)程向前推移：也就是第一步都有前進(jìn)的感（例如，用戶(hù)按下tab鍵做為一個(gè)事件就是不合適的）；
5）顯示參與者的意圖而非動(dòng)作（光有動(dòng)作，讓人不容易直接從事件流中理解用例）；
6）包括"合理的活動(dòng)集"（帶數據的請求、系統確認、更改內部、返回結果）；
7）用"確認"而非"檢查是否"：（如系統確認用戶(hù)密碼正確，而非系統檢查用戶(hù)密碼是否正確）；
8）可選擇地提及時(shí)間限制；
9）采用"用戶(hù)讓系統A與系統B交互"的習慣用語(yǔ)；
10）采用"循環(huán)執行步驟x到y，直到條件滿(mǎn)足"的習慣用語(yǔ)。
四、Alistair Cockburn眼中的用例分析技術(shù)
在使用用例分析技術(shù)時(shí)，很多人都覺(jué)得如何確定用例的粒度是一個(gè)難點(diǎn)，而且感覺(jué)到用例沒(méi)有什么規則遵從，甚至有無(wú)所適從的感覺(jué)。正如Cockburn先生提出的學(xué)習用例分析技術(shù)的"守、破、離"的三個(gè)階段：
1）守：練習基本功夫，遵循規則，照章行事；
2）破：能突破傳統，因地制宜地靈活應用； 3）離：超脫任何招式與規則，達到無(wú)招勝有招的境界。
但用例分析技術(shù)卻讓第一階段的初學(xué)者感到無(wú)法很快地掌握。而其所著(zhù)"編寫(xiě)有效用例"則想為用例分析技術(shù)補充規則，讓大家能夠更好地掌握。
Cockburn先生在Ivar Jacobson的基礎上，做了一些補充：
1）用例是契約，是系統與涉眾之間達成的契約。也就是將用例朝著(zhù)形式化的方向發(fā)展；
2） 將用例分成三級：
◆ 概要級：包括多個(gè)用戶(hù)目標（顯示用戶(hù)目標運行的語(yǔ)境，顯示相關(guān)目標的生命周期、為低層用例提供一個(gè)目錄表）；
◆ 用戶(hù)目標級
◆ 子功能級
不過(guò)，對于Cockburn先生的貢獻，用例始祖Ivar大師并未做出任何反應。本人在實(shí)踐中認為，Cockburn先生的思路與理念對于初學(xué)用例分析技術(shù)的人來(lái)說(shuō)，十分有價(jià)值，使得用例分析技術(shù)更具操作性，當其同時(shí)也有點(diǎn)畫(huà)地為牢的感覺(jué)，也許Cockburn先生也意識到這點(diǎn)，因此第三階段就是"離"，沒(méi)有規則，按需靈活使用。
五、如何在開(kāi)發(fā)過(guò)程中應用用例分析技術(shù)
用例分析技術(shù)在需求過(guò)程中的地位如下圖所示：
對于用例分析技術(shù)理解上的兩個(gè)最大的誤區是：
1）用例分析技術(shù)包括了整個(gè)需求過(guò)程：它只是一個(gè)需求分析技術(shù)，是在傳統的需求捕獲技術(shù)的基礎上使用的，并無(wú)法替代這些技術(shù)；
2）用例分析技術(shù)是分解技術(shù)：其實(shí)用例分析技術(shù)是一種合成技術(shù)，將在需求捕獲中收集而來(lái)的零散的特性合成為用例：
5.1 用例分析前的工作
在用例分析之前，應該完成以下工作：
1）確定涉眾（Stakeholder）和用戶(hù)類(lèi)型（命名、簡(jiǎn)要描述、涉眾代表、特征、能力）；
2）確定涉眾代表（命名、簡(jiǎn)要描述、責任、參與）；
3）在項目中加入涉眾代表（訪(fǎng)談、問(wèn)卷、顧問(wèn)、評審、角色扮演）；
4）創(chuàng )建共同的構想（問(wèn)題定義、系統范圍、用戶(hù)目標、非功能需求à前景文檔）；
5）采用傳統的需求捕獲技術(shù)捕獲需求；
6）組建用例分析隊伍（少量、有問(wèn)題域知識）。
5.2 用例分析過(guò)程中的注意事項
用例分析的過(guò)程如下圖所示：
在使用中要注意：
1）用例源于涉眾，請不要自己杜撰出用例；
2）用例的事件流的編寫(xiě)過(guò)程中，應充分加入團隊的參與；
3）雖然用例源于涉眾，但不要企圖向他們直接問(wèn)"你還有什么用例?這樣的問(wèn)題。
聯(lián)系客服
