Skip to content


什么是Use Case (用例)

在这篇Post中,简要介绍一些Use Case的基本概念。

Use Case是什么?

其实可以顾名思义。Use – 使用,Case – 案例/实例/情况。使用的对象当然就是系统了,或者是系统的某个部分。PS, use case是可数名词。

我们来看下Use Case的定义:

Use Case描述了在不同条件下,system对actors的请求所作出的响应。换言之,用例描述了actors能用system做什么。
在定义中,我并没有完全使用中文,因为Use Case、actors有各种版本的翻译。

据我所知,Use Case有以下几种版本翻译:用例、使用案例、用况。我最喜欢用例这个翻译。actors有以下几种版本翻译:参与者、角色、或者执行者。system没什么争议,一般都翻译为系统。

举个Use Case的例子

我举个简单系统的登录作为例子:

UC:登录

简要说明

会员可以使用用户名和密码登录系统。

参与者

会员

前提条件

基本流程

1. 用户选择登录。

2. 系统校验用户不是登录状态。

3. 系统给出登录表单。

4. 用户填写用户名、密码,提交。

5. 系统校验用户名和密码组合正确。

6. 用户登录成功。

扩展流程

2a. 系统校验用户已经是登录状态:
       2a1. 系统显示**。

5a. 系统校验用户名和密码组合错误:
       5a1. 系统报错。

后置条件

用户处于登录状态。

一个用例主要包括以下几部分:用例名称、简要说明、参与者、前提条件、基本流程、扩展流程、后置条件。

用例名称:通常用执行功能的名称命名,一般以动词+(宾语)组成,主要便于顾名思义。

简要说明简短的描述参与者通过这个用例可以完成什么任务。

参与者:代表执行该用例的一类群体,代表的是角色,而不是具体的个体。

前提条件:执行该用例之前,系统必须满足的条件。

基本流程:一些顺利的情况。所有句子采用同一种简单的执行步骤。

扩展流程:执行基本流程中出现的不同情况。同样,所有句子采用同一种简单的执行步骤。

后置条件:执行该用例之后,系统必须满足的条件。

虽然也可以用活动图来表示Use Cases,但从根本上来说,用例是文本形式的,即使是没有接受过培训的人员也可以容易的交流。所以文本是编写用例的首选形式。

什么是Use Case Diagrams(用例图)?

用例图是表现用例、参与者及他们之间关系的图形。
拿以上的登录用例来举例:

Sign In

“小人”表示参与者,“椭圆”表示用例,“箭头”表示关联(可以理解为参与者参与该用例),椭圆外面的“矩形边框”表示系统边界。

用例和需求有什么关系?

用例是捕捉系统功能和需求的高效工具,可以准确描述系统要完成的任务,所以用例是需求非常重要的一部分。
但是,用例并不是所有的需求,没有完全详细的描述数据需求、业务规则、非功能需求、用户界面等内容。

准备好编写用例了吗?

想学会阅读用例还是比较简单的,但是,要学会编写一个好的用例却不容易。这不是我说的,这是用例方面著名专家Alistair Cockburn提醒我们的。
根据个人的经验,学习编写用例一段时间后,感觉用例比较简单。再过一段时间的实践应用,发现用例很难。继续经过不断的学习和锻炼,又会慢慢的掌握好方法,进而处理好用例和其它需求内容之间的关系。

Posted in 需求分析/产品设计.

Tagged with .


4 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. 十月 says

    希望将来能有更加深入的内容介绍喔~

  2. Carrie says

    刚开始学做产品,多谢分享~~

    • TzingChu says

      不客气,互相交流 :)

Continuing the Discussion

  1. 新入职互联网产品从业人员的三个月 » Go!欧欧! linked to this post on 2010年10月14日

    [...] 在入职后两周后就接到了第一项任务:对网站现有在线沟通系统进行优化设计。当时脑子对PRD没有太多的概念,手边仅有的参考文档是面试时给主管的一份关于注册登录流程的策划,而这份文档是用Axure直接生成的。当时还是用了这个办法在交付日期前三天生成了一份进行了交付。虽然在对页面描述方面已经完全够用,但自己还是觉得这样的文档可阅读性实在太差。所以试着按iamsujie提供的产品需求模板和用例模板和TzingChu在博客里说的需求文档和UC的撰写和编号问题重新“借鉴”了一份文档出来,重新交付了一遍。其实PRD的核心就是把事情说清楚,为什么做,做些什么,怎么做且图片胜于文字,可以总结为“码字”。根据后续的一些零散项目来看(包括一些抽象规则的制订),我很多文档因为没有经验没有说到细节上,在最开始的两三个项目中还会让协作同事有不清晰的地方。文字解释看似容易但如何简洁明了精确的描述做好很难且需要时间和经验的累积。而在一些迅速执行的小项目的进行过程中PRD的存档意义还略略超过操作意义。 [...]



Some HTML is OK

or, reply to this post via trackback.