任务Task
任务，来自“目标导向的活动模型”，即：目标-任务-工具，它所描述的是人们为了到达某种目标而采取的行动。用户所采取的行动有大有小、有粗有细，其粒度是与“目标”的层次相对应的。设计软件时，我们需要考虑海平面及更高的任务目标。
任务是对用户为了达到某种目标所采取的行动的统称，它既可以是海平面级的任务，也可以是风筝层、云彩层的任务。海平面级的任务是最小粒度的任务，游鱼层、蛤贝层的用户“行动”一般对应执行任务时所采取的“步骤”，它们都没有业务价值。因此，我们可以讲任务定义为“有业务价值的”用户行动。由于海平面级的任务有着最小的业务价值，所以，我们以后提到“任务”一词时通常都特指“海平面级的任务”，对应“用户级别的目标”。
用例UseCase
“用例是代表系统中各涉众之间就系统的行为所达成的契约。用例描述了在不同条件下，系统对某一涉众的请求所做出的响应。提出请求的涉众被称为主执行者（primary actor）。主执行者通过发起与系统的一次交互来实现某个目标。系统对任一执行者所做出的响应，要保证所有涉众的利益不受侵犯。根据执行者做出的请求和请求涉及的条件，系统将执行不同的行为序列，每一行为序列称之为一个场景（Scenario）。一个用例是多个不同场景的集合。”
以上是Alistair Cockburn在《编写有效用例》中对“用例”的一段描述。在我看来，用例更像是一种文学体裁，一种与小说、诗歌、散文等并列的文学体裁。用例这种体裁很适合用来描述业务过程、软件需求以及人机交互过程。也就是说，我们写用例的目的，就是要对业务过程、软件需求、人机交互过程等进行详细准确的描述，以便让涉众就软件系统的行为达成一致。而用例，正是能清晰地记录涉众所达成的一致意见的最佳表达形式，所以，用例不仅仅是一种“契约”，它也正是记录涉众就系统行为所达成的一致意见的“最佳体裁”。
正如任务会有不同的层级（云彩层、风筝层、海平面层），用例也可以描述不同层次的内容。因为用例只是一种“体裁”，所以它的内容可以非常广泛：业务过程、软件需求、人机交互过程。我们在“任务建模”阶段，主要用用例来描述人机交互过程，并且，多数情况下是用来描述“用户目标级”的任务的。用例也会包含这两种情况：1）只描述用户执行任务的步骤；2）既描述用户执行任务的步骤又描述系统的反馈，此时的用例反映整体的人机交互过程。在此给出用例的模板，供大家参考。
用户故事UserStory
在介绍“敏捷软件开发生命周期：产品–>版本计划–>迭代–>用户故事”时，我们已经对“用户故事”有过介绍：用户故事是最基本的设计单元。用户故事就是以用户的语言对产品功能（feature）所作的描述。关于用户故事，应注意以下几点：
每个用户故事，只描述一个功能（feature）
用户故事，用的是用户的语言，体现了“以用户为中心”的思想
用户故事是产品设计的上下文背景
用户故事，是用来做出开发计划的，每个用户故事的开发周期不要太长，建议不超过1周或10天（属经验性估计，仅供参考，您别跟我较真，别问我为什么不是1周零一天或11天等等…….。一个用户故事是最小的开发单元，所以开发一个用户故事的时长最好是您能掌控的最小开发周期，所以给出了1周或10天的建议。）
接上一点。“能掌控”，就意味着每个用户故事都可以在“事前”被准确地估量出来，“事后”被准确地衡量。
|
作为 |
[某种类型的用户] |
|
我想 |
[执行某某任务] |
|
这样，我就能 |
[达成某某目标] |
例如：
|
作为 |
“直奔主题”的购物者 |
|
我想 |
在店内找到CD的位置 |
|
这样，我就能 |
快速买下它，然后马上离开；我好继续回到自己的生活轨迹中，爱干嘛干嘛了。 |
“用户故事”这一概念是在敏捷开发过程中为了控制项目的迭代进度而采用的。用户故事是最小的设计单元，它只包含一个功能点，可以被任意地分配给任何一个开发人员来实现。用户故事中所包含的功能点，可能只对应用例/任务中某一步骤中所涉及的某一个具体操作，User Story通常会比Use Case小。但是，为了在开发人员在实现该功能时，能够贯彻UCD思想，体现用户目标，所以我们会在描述该功能的时候提及用户的“目标”和“任务”，当然，也会说明该功能所要面对的用户是什么样子的。这样，就有了用户故事“作为[××用户]，我需要[××功能]支持我完成[××任务]，这样，我就能达成[××目标]”。
Alistair Cockburn曾对User Story、Use Case、Scenario作过区分：
A user story is the title of one scenario whereas a use case is the contents of multiple scenarios
“用户故事”相当于“场景”的标题，而“用例”则是多个“场景”内容的集合。
由于“场景”是一个“行为序列”，那么它必定会涉及多个操作，势必也需要软件系统提供多个“功能”。依我本人的看法，每个用户故事只会包含一个功能点，这样会方便开发工作的分配，有利于项目迭代进度的掌控。但是，依Cockburn的看法，每个用户故事会包含一个“行为序列”中的所有功能（不值一个功能）。我是这么处置我与Cockburn观点上的分歧的：如果每个用户故事包含一个功能点好安排工作、有利于掌控项目进度，我们就在每个用户故事中只包含一个功能点；如果每个用户故事包含一个“行为序列”（一个场景）中涉及的多个功能点更利于安排工作、更利于掌控项目进度，我们就在每个用户故事中包含多个功能点。
“用户故事”是项目管理的一种工具，每个用户故事的开发时间不应长于10天，否则项目进度不易掌控。User Story更像是分析问题、规划项目进度时所用工具，而Use Case则是对业务、需求等分析的结果。
场景Scenario
“场景”这个词，有两拨人在用：一拨是交互设计师（如Alan Cooper）；另一拨是需求分析师（如Alistair Cockburn）。当然，他们所指的含义也不一样。关于“场景”一词两用的情况，在RUP（Rational Unified Process）中已有辨析：“场景”在 RUP 内部指用例实例，即只是一个经过可能的基本流和备选流的特定“路径”（即Cockburn所说的“一个行为序列”）。但是，在以用户为中心的设计方法和用户界面设计方法中常常将“场景”描述为使用经历（Cooper就这么做），这实际上包含了更多的细节，而不仅局限于事件流。虽然该附加信息可能与后来的设计阶段无关，但它对于了解用户、任务和环境却必不可少。因此，场景可以在业务建模工作流程中广泛应用，但是在需求工作流中，重点则转移到用例上。
小结
任务来自“目标导向的活动模型”（目标-任务-工具），它所描述的是人们为了到达某种目标而采取的行动。没有其他说明的情况下，“任务”一词通常都特指“海平面级的任务”，对应“用户级别的目标”。海平面级的任务是最小粒度的任务。
用例是记录各涉众之间就系统的行为所达成的契约的“最佳体裁”。
用户故事是分析问题、规划项目进度时所用工具，而用例则是对业务、需求等分析的结果。用户故事是最小的设计单元，它只包含一个功能点。
场景经常被交互设计师用来描述业务建模工作流程中用户的使用经历，但是在需求工作流中，场景则是用例的一个具体实例，是一个经过可能的基本流和备选流的特定“路径”（即Cockburn所说的“一个行为序列”）。交互设计师所说的场景中涉及的Actor肯定是人，而用例中的场景，它的Actor既可以是人，也可以是软件系统。
Alistair Cockburn说：“用户故事”相当于“场景”的标题，而“用例”则是多个“场景”内容的集合。
