一位担任项目经理/架构师的朋友问我“我们已经为项目确定了用例，接下来该做些什么呢？”，我真的给不出一个确切的答案，他已经知道如何编写用例规范和如何绘制用例图，但当我们深入交谈后，他又问我“如果作为项目经理该怎么做呢？我们下一步该做什么呢？”他不知道如何使用用例。
用例不是神丹妙药，它只是一种用来组织系统需求的方式，它和传统的功能逐级分解有所不同，传统的方法是将功能不断拆分成小功能点，然后经过重新组装形成大的功能集，而用例是围绕各种用例流程组织需求的，它不具有典型的层次分解属性。
理解这一点后，我们就可以使用用例做与软件开发类似的其它开发了，例如，使用用例来评估软件功能的商业价值，商业利益既得人很难通过被分解的功能或子功能来评估其对整体业务的价值，因为用例是由特定参与者驱动的一个场景，商业利益既得人可以更容易与真实的商业活动进行对比，这样我们可以建立一个以商业价值为基础的开发计划。
这是规划用例开发最基础的方法，首先要识别你的候选用例，接下来为每个用例创建简短的描述信息，最后再粗糙地为所有用例排出优先级，在指定优先级时使用1-10的数字，1表示最不重要的用例，10表示最重要的用例。在提交给领导审核前先自审一遍，看能否从描述信息确定出一个合理的优先顺序，如果不行说明你的描述信息没有写清楚这些用例的用途。
此外，你还应该审视这些用例的实现难度和风险，因此可以再给每个用例加上这两个标记，仍然用1-10的数字来表示难易程度和风险，1表示非常容易/没有风险，而10表示非常困难/风险很大。下面用一个坐标图来表示每个用例的重要性和难度，可以让相关项目利益相关人更好地理解你的意图，Y轴表示项目利益相关人审核后的重要性排名，X轴表示技术难度排名，每个小椭圆代表一个用例。
图 1 用例坐标图
接下来将用例坐标图划分为四个象限，按逆时针方向进行计数，右上角的象限包括的是风险最高的用例（重要性最高，技术难度最大），左上角的象限包括的是重要性高，难度低的用例，左下角象限包括的用例最不重要，难度也最低，右下角象限包括的用例重要性不高，并且难度很大，如图2所示。
图 2 排列优先级后的用例图
从这个图可以粗略地排出用例的优先级，仍然按照逆时针方向介绍起走。右上角的用例优先级应该最高，在开始做其它事情之前应该先解决这些高风险用例，如果这些高风险不能得到解决，那么整个项目可能会面临被取消或重构；左上角的用例是开发任务的中流砥柱（重点内容），这些用例很重要，并且难度很很低，因此接下来就应该完成它们；如果你有充裕的时间或资源（你是不是在咯咯地笑？），可以考虑实现左下角的用例，因为它们难度不大，但也不是那么重要；而你可能最不想碰的就是右下角的用例，因为他们难度很大，而且项目利益相关人又不在乎它。
通过用例的方式，现在你对下一步要做的事情的顺序应该有点眉目了，在开发生命周期中它们应该有不同的等级，如图3所示。
图 3 用例图数列
警告：这只是一个简单的方法，但并不表示你应该在开发中使用串行的，瀑布式方法，这个技术可以用于增量增加，迭代或敏捷开发方法，它只给你提供了一个简化排列用例（或功能块，用户故事等）优先级的方法，当然并不是一次就可以排好的，在实际运用时，还需要结合各个用例和实际情况进行微调，但需要注意的是，如果调整的幅度很大，通常意味着用例设计得不好，也许需要重新定义用例。UML不仅是需求诱导，分析和设计的伟大工具，它还可以帮助项目经历制定有效的项目计划，提升项目管理水平。
