為了解決前文所述的軟件需求困境，我們首先需要找到一種可以被各方真正理解和溝通、并可以被逐步精化的需求體系。我認為，這種體系應(yīng)該是基于用例（usecase）的。
首先，讓我們仔細研究一下用例的定義：
一個用例抽象了目標系統(tǒng)在現(xiàn)實中將執(zhí)行的一組場景（每個場景由一系列動作組成）；這些場景會產(chǎn)生一個對某個Actor有價值的、可觀測的結(jié)果;
在這個定義中，我們強調(diào)了兩件事情：一、用例是被從現(xiàn)實的場景中抽象出來的，而不是被隨便發(fā)明出來的；二、每個用例（場景）應(yīng)能提供完整的商業(yè)價值。在未來的博文里會介紹這兩條會如何幫助我們避免對用例的誤用。
用例的優(yōu)勢在于它天生是黑盒的，它用自然語言抽象了用戶和目標系統(tǒng)的交互，避免了混入分析、設(shè)計和實現(xiàn)細節(jié)，以保證用例可以被不懂具體技術(shù)的業(yè)務(wù)及測試人員所真正理解。同時，需求分析員又可以方便地通過用例分析（use case analysis）（即用分析類來試圖在理想方式下實現(xiàn)用例），將需求體系精華成分析模型。在這一過程中，需求分析員可以更進一步地完善基于用例的需求體系，而不必擔(dān)心分析模型會污染需求，從而實現(xiàn)需求與分析的分離及有效互動。
最后，我們必須指出，基于用例的需求管理體系中不僅僅包含用例，它還應(yīng)該包括涉眾請求，特性列表，前景文檔，補充規(guī)約，詞匯表等等。
用例其實是Ivar在許多年前發(fā)明的老技術(shù)了，現(xiàn)在被很多人所采用，而被更多人誤用，下面的文章讓我們看看一些對用例的典型的誤解和誤用。
項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~
http://opto-elec.com.cn/pmqhd/index.html
