一：基本概念
--->用例定义了一组用例实例，其中每个实例都是系统所执行一系列操作，这些操作生成特定主角可以观测的值。
--->所谓用例，就是一件事情，要完成这件事情，需要一系列活动，而做一件事情可以有很多不同的办法和步骤，也可能遇到各种各样意外情况。因此这件事情是由很多不同情况的集合构成的。在UML中称之为用例场景。一个场景就是一个用例的实例。
--->一个系统的功能性是由一些对系统有愿望的参与者要做的一些事情构成的，事情完成后就达成了参与者的一个愿望，当全部参与者的所有愿望都能够通过用例来达到，那么这个系统就被确定下来。
--->捕捉功能性需求，这就是用例的作用。
二：用例的特征
---->用例是相对独立的。
（1）不需要与其他用例交互而独自完成参与者的目的。用例从“功能”上说是完备的。
（2）用例本质体现了参与者的愿望，不能完整达到参与者愿望的不能称之为用例。
（3）例如：人到银行取钱是有效用例。
---->用例执行结果对参与者来说是可观测的和有意义的。
（1）人去银行取钱，得到了钱。是有效的用例，因为得到了钱。填写取款单，则不是有效用例，只是步骤。
（2）人登陆qq,进入主页。是有效用例，因为通过验证，进入操作界面。而输入密码，则不是有效用例。只能是步骤。
---->这件事情必须由一个参与者发起，不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。
（1）用例总是由一个参与者发起的。参与者的愿望是这个用例存在的原因。
---->用例必然是以动宾短语形式出现的。
（1）用例必须有一个动作和动作的受体。
（2）喝水是一个有效的用例。而“喝”和“水”却不是。
---->一个用例就是一个需求单元，分析单元，设计单元，开发单元，测试单元，甚至部署单元。
三：用例的粒度
---->粒度是令人困惑的。比如在ATM取钱的场景中，取钱，读卡，验证帐号，打印回执单等都可能是用例。显然，取钱包含了后续的其他用例，取钱粒度更大一些，其他用例的粒度则更小一些。到底是一个大的用例合适还是分解成多个小用例合适呢？
---->这个问题并没有一个标准的规则。笔者可以给大家分享的经验是在项目过程中，根据阶段不同，使用不同粒度。
（1）在业务建模阶段，用例的粒度以每个用例能说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。这将有助于明确需求范围。例如：取钱，报装电话，借书等表达完整业务的用例，而不需要细到验证密码，填写申请单，查找书目等业务中的一个步骤。
（2）在用例分析阶段，即概念建模阶段，用例的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。需要注意的是，这个阶段需要采用一些面向对象的方法，归纳和抽象出业务用例中关键概念模型并为之建模。例如：宽带业务需求中有申请报装和申请迁移地址用例，在用例分析时，可归纳和分解为提供申请资料，受理业务，现场安装等多个业务流程中都会使用的概念用例。
（3）在系统建模阶段，用例视角是针对计算机的。因此用例的粒度以一个用例能够描述操作者和计算机的一次完整交互为宜。例如：填写申请单，审核申请单，派发任务单等。可理解为一个操作界面或一个页面流。
---->实际上，用例粒度划分依据（尤其是业务用例）最标准的方法是以该用例是否完成了参与者的某个完整目的为依据的。
---->用例分析是以参与者为中心的，因此用例的粒度以能完成参与者目的为依据。
四：用例的获得 
---->我们知道用例的定义就是由参与者（actor）驱动的，并且给参与者提供可观测的有意义的结果的一系列活动的集合，用例的来源就是参与者对系统的期望。
---->发现用例的前提条件是：（1）发现参与者（2）确定参与者的同时就确定系统边界。
---->捕获用例前需要能够清楚地理解下面几个问题。以下：参与者改叫主角
（1）主角位于系统边界外的。
（2）主角对系统有着明确的期望和明确的回报要求
（3）主角的期望和回报要求在系统边界之内的。
（4）一个明确的有效的目标才是一个用例的来源
（5）一个真实的目标应当完备表达主角的期望。
（6）一个有效的目标应当在系统边界内，由主角发动，并且有明确的后果。
---->从客户哪儿捕获用例的中心思想？
（1）你对系统有什么期望？
（2）你打算在这个系统里做些什么事情？
（3）你做这些事的目的是什么？
（4）你做完这些事情希望有一个什么样子的结果？
五：用例和功能的误区
---->实际应用中，用例是非常容易被误解和误用的。尤其是习惯了面向过程结构化设计方法的计算机技术人员，最普遍的理解错误是认为用例就是功能的划分和描述。他们认为一个用例就是一个功能点。这是错误的。
---->用例不是功能。用例是一组功能组合。
---->在描述一个事物的时候，我们可以从以下三个观点出发：
（1）这个事物是什么？
（2）这个事物能做些什么？
（3）人们能够用这个事物做什么？
例如：描述一辆自行车的时候，我们同这样说明
第一个人：自行车是一种交通工具，它由传动系统，刹车系统等部分组成【第一个人描述的是一种结构性观点。】
第二个人：自行车可以骑行，可以载物【第二个人描述的是一种功能性观点，说明事物的可利用价值】
第三个人：人们可以用双脚蹬动踏板而往前行，可以用手捏合刹车让自行车停下来。【第三个人描述的是一种使用者观点，说明事物对使用者的意义】
----->而我们熟知这都是我们对一个东西非常熟悉，才可以这样描述。对于一个未知的事物我们是无法这样描述的。软件恰恰就是这样一个不存在的事物，无法直接知晓它的结构，价值，意义。
---->因此，我们从使用者观点出发描述软件是非常合适的。使用者观点告诉需求收集人员，他希望这个系统是什么样，他将怎么样使用这个系统，希望获得什么结果。那么软件只需要按照使用者要求提供一个实现，就不会偏离使用者的预期。至于功能性观点和结构性观点，则可以通过使用者观点推导出来。
----->使用者观点实际就是用例观点。一个用例是一个参与者如何使用系统，获得什么结果的一个集合。通过用例分析，得出结构性和功能性的内容，最终实现用例，也就实现了使用者的观点。
【用例和功能区别的总结】
------>功能是脱离使用者的愿望而存在的。我们常常说某个工具具有某个功能，它是描述工具的，而不是站在使用者的角度描述使用者愿望的。功能用来描述某某东西能做什么，它与使用者愿望无关，描述的是事物固有的性质。
------>功能是孤立的，给一个输入，通过计算就有一个固定的输出。功能描述的是一个个点。如果要达成一个特定的目标，必须要额外加上一个顺序的过程把点串起来才能完成一个系统性的工作。而用例描述的是一个系统性的工作。这个系统性的工作明确地达成一个特定的目标。
------>如果非要从功能的角度解释用例。那么用例可以解释为一系列完成一个特定目标的“功能”的组合，针对不同的应用场景，这些“功能”体现不同的组合方式。并且，不是先有了这些“功能”才来组合某个场景，而是先有了场景，才分解出“功能”。这里的“功能”之所以打引号，是因为UML里没有这个功能词。实际上从场景分解出来的是对象。这些对象通过消息相互交流而完成场景。
例子：从功能的角度出发，对电视的描述：能开关，能显示，可以调频道，可以调声音。
从用例的角度出发，对电视的描述：有一个人要观看电视节目的用例，第一步是先打开开关，调到自己喜欢的频道，如果声音不合适，可以调节一下，以上三者是因为人的需求而相关起来的。读者可以细细品味一下这其中的区别。
原文：http://www.cnblogs.com/shangxiaofei/p/5031076.html