一位擔(dān)任項目經(jīng)理/架構(gòu)師的朋友問我“我們已經(jīng)為項目確定了用例，接下來該做些什么呢？”，我真的給不出一個確切的答案，他已經(jīng)知道如何編寫用例規(guī)范和如何繪制用例圖，但當(dāng)我們深入交談后，他又問我“如果作為項目經(jīng)理該怎么做呢？我們下一步該做什么呢？”他不知道如何使用用例。
用例不是神丹妙藥，它只是一種用來組織系統(tǒng)需求的方式，它和傳統(tǒng)的功能逐級分解有所不同，傳統(tǒng)的方法是將功能不斷拆分成小功能點，然后經(jīng)過重新組裝形成大的功能集，而用例是圍繞各種用例流程組織需求的，它不具有典型的層次分解屬性。

理解這一點后，我們就可以使用用例做與軟件開發(fā)類似的其它開發(fā)了，例如，使用用例來評估軟件功能的商業(yè)價值，商業(yè)利益既得人很難通過被分解的功能或子功能來評估其對整體業(yè)務(wù)的價值，因為用例是由特定參與者驅(qū)動的一個場景，商業(yè)利益既得人可以更容易與真實的商業(yè)活動進行對比，這樣我們可以建立一個以商業(yè)價值為基礎(chǔ)的開發(fā)計劃。

這是規(guī)劃用例開發(fā)最基礎(chǔ)的方法，首先要識別你的候選用例，接下來為每個用例創(chuàng)建簡短的描述信息，最后再粗糙地為所有用例排出優(yōu)先級，在指定優(yōu)先級時使用1-10的數(shù)字，1表示最不重要的用例，10表示最重要的用例。在提交給領(lǐng)導(dǎo)審核前先自審一遍，看能否從描述信息確定出一個合理的優(yōu)先順序，如果不行說明你的描述信息沒有寫清楚這些用例的用途。

此外，你還應(yīng)該審視這些用例的實現(xiàn)難度和風(fēng)險，因此可以再給每個用例加上這兩個標(biāo)記，仍然用1-10的數(shù)字來表示難易程度和風(fēng)險，1表示非常容易/沒有風(fēng)險，而10表示非常困難/風(fēng)險很大。下面用一個坐標(biāo)圖來表示每個用例的重要性和難度，可以讓相關(guān)項目利益相關(guān)人更好地理解你的意圖，Y軸表示項目利益相關(guān)人審核后的重要性排名，X軸表示技術(shù)難度排名，每個小橢圓代表一個用例。

圖 1 用例坐標(biāo)圖

接下來將用例坐標(biāo)圖劃分為四個象限，按逆時針方向進行計數(shù)，右上角的象限包括的是風(fēng)險最高的用例（重要性最高，技術(shù)難度最大），左上角的象限包括的是重要性高，難度低的用例，左下角象限包括的用例最不重要，難度也最低，右下角象限包括的用例重要性不高，并且難度很大，如圖2所示。

圖 2 排列優(yōu)先級后的用例圖

從這個圖可以粗略地排出用例的優(yōu)先級，仍然按照逆時針方向介紹起走。右上角的用例優(yōu)先級應(yīng)該最高，在開始做其它事情之前應(yīng)該先解決這些高風(fēng)險用例，如果這些高風(fēng)險不能得到解決，那么整個項目可能會面臨被取消或重構(gòu)；左上角的用例是開發(fā)任務(wù)的中流砥柱（重點內(nèi)容），這些用例很重要，并且難度很很低，因此接下來就應(yīng)該完成它們；如果你有充裕的時間或資源（你是不是在咯咯地笑？），可以考慮實現(xiàn)左下角的用例，因為它們難度不大，但也不是那么重要；而你可能最不想碰的就是右下角的用例，因為他們難度很大，而且項目利益相關(guān)人又不在乎它。
通過用例的方式，現(xiàn)在你對下一步要做的事情的順序應(yīng)該有點眉目了，在開發(fā)生命周期中它們應(yīng)該有不同的等級，如圖3所示。

圖 3 用例圖數(shù)列

警告：這只是一個簡單的方法，但并不表示你應(yīng)該在開發(fā)中使用串行的，瀑布式方法，這個技術(shù)可以用于增量增加，迭代或敏捷開發(fā)方法，它只給你提供了一個簡化排列用例（或功能塊，用戶故事等）優(yōu)先級的方法，當(dāng)然并不是一次就可以排好的，在實際運用時，還需要結(jié)合各個用例和實際情況進行微調(diào)，但需要注意的是，如果調(diào)整的幅度很大，通常意味著用例設(shè)計得不好，也許需要重新定義用例。UML不僅是需求誘導(dǎo)，分析和設(shè)計的偉大工具，它還可以幫助項目經(jīng)歷制定有效的項目計劃，提升項目管理水平。