用例浅谈

用例（use case）是现代软件工程中用来采集需求和软件设计的一个常用工具。那么用例到底是什么东西？什么时候用这个工具？如何使用这个工具呢？本文就结合本人在日常工作中的实践经验来做一个简单的介绍。

用例的定义有很多，几乎每一本书的作者都有自己的理解。但是用例的本质不变，系统的使用者对系统发出的一次请求，用例描述系统完成这个目标的过程的一种方法。因此我们可以用4个词来概括用例；他们是：角色，请求，步骤和目标。 有的书上说是三个要素。一个是参与者，也就是我这里的角色。一个是用例只描述单独的任务，也就是我这里的请求和步骤；最后一个是用例必须产生一个对用户有意义的结果，也就是我这里的目标。

系统的主要角色（可能是最终用户，也可能是其他系统）启动了一个交互，他有一个用户目标（user goal）。由于用户请求的上下文不同，前提条件不同，因此这个交互可能产生多个场景。一个UC会把目标相同的场景集合起来。


用例的格式

一般来说，用例可以以多种形式编写，但是大多数情况下都是用于和非专业人员交流，因此，用纯文本方式比较好。同时可以节约时间。

对于用例的格式，很多书上面都有不同的定义，但是我个人认为，用例没有特别的格式。只要意思清晰明了即可。每个人编写的用例都是不同的。UC写作有简化版本和完全格式版本，可以根据项目规模大小选用。

使用用例来发现需求

当编写一个新系统的用例时，一般先写黑盒，然后设计人员细化时变成白盒。黑盒UC的作用主要用来引发讨论，一般由PD或者RE来写，写好之后和Dev和Test以及客户进行讨论。因此UC常常被用作是头脑风暴的工具。UC本身的功能就是捕捉已知的功能性需求并为之建模，这样可以完成高质量的需求报告，相对来说比一般方法要可靠，完全的多。

但是用UC来找出需求时需要注意两点：
1. 它是真正的需求，不是行为或者过程，应该要正确的写出系统必须做的事情，而不是如何做事情。
2. 它不是所有的需求，它们不包括外部接口，数据格式、业务逻辑以及复杂的公式等。他们组成了所有需求中的一部分。不过虽然只有一部分，但是是最重要的一部分。


用例的价值

UC很流行大抵上是因为他们一致、连贵的说明了这个系统是如何使用的。在早期提出完备的UC，系统的使用者就知道该系统可以做什么了。他们可以及早的做反馈、进行调整或者拒绝该UC。不管采用何种设计方法，需求分析阶段的用例建模工作都能发挥极其重要的作用。

有一些公司是不是用用例方法的。他们使用的是Feature。首先获取用户需求，然后由PM大致写出该系统的Feature，当然要包括所有的用户需求，然后通过头脑风暴完善Feature List。最后为每个Feature添加Function List。

事实上，系统级的黑盒UC就可以看作是Feature。每一个步骤就是这个Feature下面的功能。

UC的价值最早产生于当这个用户目标（user goal）创建，并把它们放入到系统的特性列表中去时。这个列表说明了系统可以做的事情，规定了系统的范围。

这个List会由用户代表，PM，公司专家，行业专家代表等人检查。他们会用这个Feature List估算成本和系统实现复杂度，由此确定系统的起始点。这个列表可以联系到复杂性、风险管理、成本、时间和状态检查。

第2个价值体现在UC的作者用头脑风暴的方式把主成功路线上一切可能的错误列举出来的时候。这时候，他可能会发现一些令人惊讶的事情，或者是客户没有想到的事情。这些事情可能导致新的使用者，新的UC的出现。

第三，用例可以帮助我们划分软件的开发周期，评估研发工作量。对于优先级较高的用例会在早期的迭代周期中实现，优先级较低的用例则安排在后续的迭代中完成。

用例模型在整个开发过程中都扮演着非常重要的角色。它用来驱动软件的分析和设计逐步细化。

最后，软件项目中的功能性测试用例，基本上都是根据用例模型来确定的。

用例建模

用例建模是通过分析用户的功能性需求，得到用例模型的工作过程。一般包括下面几个步骤：

1. 确定系统边界
2. 确定参与者
3. 找出所有用例
4. 确定每个用例的级别
5. 用例描述
6. 画出以整个系统为对象的顺序图
   

编写用例

不要一开始就写出所有的细节，这是违反事物发展规律的，就像荒谬地要求把需求全部搞清才能做设计一样。用例的细化一般有4个阶段。
1. Actor & Goals
列出所有参与者以及他们的用户

2. Use case brief or main success scenario
选出主要的一些UC，写出触发条件和一个大致的轮廓，也就是主成功场景。保证该系统的功能真的是Stakeholder们感兴趣的。

3. Failure conditions
完成主成功场景后，用头脑风暴的方式找出所有可能的失败，首先把它们全部列出，而不是直接就讨论系统的应对之策。

4. Failure handling
写下系统是如何处理每一个错误的。这时候，常常会有一些原本不明显的问题被渐渐暴露出来或者错误处理会突然引入新的用户或者新的用户目标。

大多数项目时间紧张，人员精力有限，在项目前该确定要工作到何种细致程度，因此我强烈建议按照上面4个顺序来。