如何确定用例和场景的优先级

如何确定用例和场景的优先级

在做需求分析时，特别是在设计分析用例模型时，很多人可能碰到过这样的问题，如何准确划分优先级，根据我的经验，一般需求分析人员对用例的优先级划分上没有具体的原则和标准，往往跟着感觉走，要么是客户认为重要的，急着要实现的功能，优先级就高，当然也很重要。对于什么关键用例，什么重要用例，什么是辅助用例或一般用例，都没有具体分得很清楚，因为他们觉得优先的都重要，反正都是要开发的，客户说什么功能最急需要，那么就完成它，其余所有用例都为一般用例。
其实我也很赞成这部分人的观点，主要是结合实际项目，这种情况太普遍了，所以往往只区分重要和非重要来得更方便。不过既然RUP以及软件工程的需求分析阶段都有这么个概念，而且对用例（场景，类）都分为三个等级：关键（首要），重要（其次），辅助（不错）。那么为了准确理解，并在项目中应用，我个人认为理解清晰它，也还是有必要的。而最重要的是掌握其划分原则。最近参加了些需求分析方面的培训，也了解了一些不同人的观点，结合RUP给出的解释，我做了些总结。
下边说说我的理解。因为用例，场景，类都有这三个等级划分，所以为了解释方便，下边直接通过用例说明问题。
第一 关键（或首要）用例
RUP中解释是这样的：该等级的用例于系统的首要任务，基本功能以及待开发的功能有关。如果这些关键用例缺失，系统将无法完成首要任务。他们还促进架构设计，而且往往是最频繁使用的用例。其实这个理解很好懂，我也比较赞成，一句话就是系统必不可少的功能，如果把系统无限缩小，到不能再缩小了（再缩小系统都无法使用了），这时剩下的用例就是关键用例。而关键需求决定架构，所以这些关键用例往往对架构设计的影响是很大的。所以分析用例模型时要特别重视关键用例的识别。有时候不能直接听客户所谓的优先级高的用例。因为客户不懂系统实现，他们只关注功能，不关注你如何设计，如何分析。当然他们提的优先功能固然不可不重视，但是我们不能局限于这些，我们需要认真分析，把那些客人认为非优先，但是通过分析，我们认为确实是关键需求的用例找出来，否则以后等用户去发现这些“关键用例”，然后再提需求变更就麻烦了，因为原来的关键需求识别上没有做好，现在要变更需求，可能影响到架构，搞不好系统整个都要整改，那就麻烦了。我的识别方法时：客户眼中的“优先”功能 + 系统最小实现的功能。把握了这个原则，识别关键用例还是不难的。
第二 重要（或其次）用例
RUP中的解释是这样的：
该等级的用例于系统功能的支持有关，比如统计数据编译，报告生成，监督和功能测试等。如果他们缺失，系统仍然可以再一定时间内完成基本任务，但服务质量所有下降。这类功能其实相比之下不太好识别，因为特征不够明显，不过识别原则还是很清晰，就是与系统功能的支持有关。比如常见的系统的用户管理模块，管理模块，系统分类模块等，都是为了支持整个系统其他关键用例服务的。没有他们系统还是可以用，但是相对质量不高。这类重要性用例的识别，我的方法时抓住一个“支持”2字的理解就比较好识别了，分析多了，就自然有了感觉，而且，结合关键用例和辅助性的用例的分析，用排除法也可以使分析得更加准确。
第三 辅助性（一般）用例
RUP中的解释是这样的：
这些用例和类着重舒适性的功能 ，与系统的主要任务无关，但有助于系统的使用和市场定位。我的理解，一句话，就是系统扩展的功能，生动一点说，就是锦上添花的功能。根据这个特征，这列用例还是比较好识别的。
总结：一般来说，不同等级的用例对架构的影响程度跟他们的关键程度是成正比的。但是也应该明确，有些关键用例没有或基本没有影响力，反过来也是一样，某些辅助性的用例可能对系统架构产生比较大的影响。所以，方法论的东西没有绝对的正确，只是利用这些理论分析相对有效。呵呵，在现实中经常发现，爱因斯坦真了不起，相对论用途那么广泛，有时不自觉感受到其存在了，而在学生时代远远理解不到这个层次. 
转载自： http://blog.csdn.net/chuan122345/article/details/5167035