Use Cases是什么？
其实可以顾名思义。Use – 使用，Cases – 案例/实例/情况。使用的对象当然就是系统了，或者是系统的某个部分。
我们来看下Use Cases的定义：
Use Cases描述了在不同条件下，system对actors的请求所作出的响应。换言之，用例描述了actors能用system做什么。
在定义中，我并没有完全使用中文，因为Use Cases、actors有各种版本的翻译。
据我所知，Use Cases有以下几种版本翻译：用例、使用案例、用况。我最喜欢用例这个翻译。actors有以下几种版本翻译：参与者、角色、或者执行者。system没什么争议，一般都翻译为系统。
举个Use Case的例子
我举个简单系统的登录作为例子：
UC：登录
简要说明
会员可以使用用户名和密码登录系统。
参与者
会员
前提条件
无
基本流程
1. 用户选择登录。
2. 系统给出登录表单。
3. 用户填写用户名、密码，提交。
4. 系统校验用户名和密码组合正确。
5. 用户登录成功。
扩展流程
4a. 系统校验用户名和密码组合错误：
4a1. 系统报错。
后置条件
用户处于登录状态。
一个用例主要包括以下几部分：用例名称、简要说明、参与者、前提条件、基本流程、扩展流程、后置条件。
用例名称：通常用执行功能的名称命名，一般以动词+（宾语）组成，主要便于顾名思义。
简要说明简短的描述参与者通过这个用例可以完成什么任务。
参与者：代表执行该用例的一类群体，代表的是角色，而不是具体的个体。
前提条件：执行该用例之前，系统必须满足的条件。
基本流程：一些顺利的情况。所有句子采用同一种简单的执行步骤。
扩展流程：执行基本流程中出现的不同情况。同样，所有句子采用同一种简单的执行步骤。
后置条件：执行该用例之后，系统必须满足的条件。
虽然也可以用活动图来表示Use Cases，但从根本上来说，用例是文本形式的，即使是没有接受过培训的人员也可以容易的交流。所以文本是编写用例的首选形式。
什么是Use Case Diagrams（用例图）？
用例图是表现用例、参与者及他们之间关系的图形。
拿以上的登录用例来举例：
“小人”表示参与者，“椭圆”表示用例，“箭头”表示关联（可以理解为参与者参与该用例），椭圆外面的“矩形边框”表示系统边界。
用例和需求有什么关系？
用例是捕捉系统功能和需求的高效工具，可以准确描述系统要完成的任务，所以用例是需求非常重要的一部分。
但是，用例并不是所有的需求，没有完全详细的描述数据需求、业务规则、非功能需求、用户界面等内容。
准备好编写用例了吗？
想学会阅读用例还是比较简单的，但是，要学会编写一个好的用例却不容易。这不是我说的，这是用例方面著名专家Alistair Cockburn提醒我们的。
根据个人的经验，学习编写用例一段时间后，感觉用例比较简单。再过一段时间的实践应用，发现用例很难。继续经过不断的学习和锻炼，又会慢慢的掌握好方法，进而处理好用例和其它需求内容之间的关系。