迷途书童

敏感、勤学、多思
随笔 - 77, 文章 - 4, 评论 - 86, 引用 - 0
数据加载中……

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


在做需求分析时,特别是在设计分析用例模型时,很多人可能碰到过这样的问题,如何准确划分优先级,根据我的经验,一般需求分析人员对用例的优先级划分上没有具体的原则和标准,往往跟着感觉走,要么是客户认为重要的,急着要实现的功能,优先级就高,当然也很重要。对于什么关键用例,什么重要用例,什么是辅助用例或一般用例,都没有具体分得很清楚,因为他们觉得优先的都重要,反正都是要开发的,客户说什么功能最急需要,那么就完成它,其余所有用例都为一般用例。

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

posted on 2012-05-11 04:56 迷途书童 阅读(1762) 评论(1)  编辑  收藏 所属分类: 业务建模

评论

# re: 如何确定用例和场景的优先级  回复  更多评论   

学习了
2012-05-11 08:32 | tb

只有注册用户登录后才能发表评论。


网站导航: