用例初学习

一、用例的相关概念（what）

用例是文本形式的情节描述，用以说明某参与者使用系统以实现某些目标。

注意：用例不是图形，而是文本。很多初学者认为用例就是用例图

用例是对一组动作序列（其中包括它的变体）的描述，系统执行该动作序列来为参与者产生一个可观察的结果值。这个动作序列就是业务工作流程，项目的涉众都能理解，基于它所进行的讨论，能较好地完善这个序列。

用例特别适用于描述用户的功能性需求，它描述的是一个系统做什么（what），而不是说明怎么做（how）。用例不关心系统设计，编写用例的最昂贵的错误包括太多细节和用户界面说明，使得用例变长，难以阅读。

 

二、为什么要使用用例（why）

1．              有利于开发者与用户之间进行交流。编写用例的难度比较低，开发者和用户都可以编写，而且可以基于用例进行交流。（很多项目就是因为需求不清楚，最后导致失败）

2．              用例强调了用户的目标和观点。用例中提出的问题是“谁使用系统、他们使用的典型场景是什么、他们的目标是什么”。所以用例要比待开发系统的特性清单更强调以客户为中心。

 

三、怎么样使用用例（how）

用例的三种形式：

1.       摘要：简介的一段式概要，通常用于主成功场景，一般在早期需求分析中使用。

2.       非正式：用几个段落覆盖不同场景，一般在早期需求分析中使用。

3.       详述：详细编写所有步骤及各种变化，同时具有补充部分，在需求细化过程中使用。

 

详述的内容及各部分的解释是：

1.       范围：界定所要设计的系统，比如是将企业和收款系统作为当前范围，还是只是将收款系统作为当前范围

2.       级别：主要分为用户目标级别或子功能级别，用户目标级别是通常用的级别。两者的主要区别是当若干常规用户共享重复的子步骤时，将其分离出来。

3.       主要参与者：调用系统服务来完成目标的主要参与者。

4.       涉众及其关注点列表：界定了系统必须要做的工作。该项回答了以下问题：用例应该包含什么，答案是：用例应该包含满足所有涉众关注点的事物。在编写用例其余部分之前就确定涉众及其关注点，能够让我们更加清楚地了解详细的系统职责。

5.       前置条件和成功保证：前置条件：给出在用例中场景开始之前必须永远为真的条件。成功保证：给出用例成功结束后必须为真的事物。

6.       主成功场景和步骤（或基本流程）：描述了满足涉众关注点的典型成功路径。它通常不包括任何或分支。

7.       扩展（或替代流程）：描述了其他所有场景或分支，包括成功和失败路径，

8.       特殊需求：如果有与用例相关的非功能性需求、质量属性或约束，那么应该将其写入用例。其中包含需要考虑和必须包含在内的质量属性（如性能、可靠性和可用性）和设计约束（通常对于I/O设备）。

9.       技术和数据变元表：描述技术变元，这些变元是关于必须如何实现系统的，而非实现系统的哪些功能。比如说pos系统的输入必须是读卡器和键盘。

 

至于使用用例图和活动图在这里暂时不做介绍