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

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

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

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

圖 1 用例坐標圖

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

圖 2 排列優先級后的用例圖

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

圖 3 用例圖數列

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