学步园

从这个角度我们分析出了系统的基本活动以及涉及这些活动的系统外部元素（人，设备）。这些活动被称为用例，外部元素被称为参与者。

参与者可能是人或者机器。从某个角度来说，应该找出在机器后边的那些人，因为只有他们会关注需求捕获。

用例应该反映系统的主要活动。例如用户使用ATM就是一个用例而用户输入个人信息代码（PIN）就不是。

有时这样做有一些困难，所以我们看到把大的用例分成较小的子用例是很有用的。比如我们可能有关于存款、取款和帐户查询的几个用例。

没有一个严格的和快速的规则。一些系统结构师喜欢用少量的彼此关联的大型用例；另一些人喜欢用大量的小型用例。对于任何一个特定的项目来说一个有用的规则是用例数不应该超过30个（如果需要更多的用例，那么就应该把项目拆开来做）。

接下来我们要在一个或多个用例图上展示用例和参与者之间的关系。对一个大型项目来说可能需要不止一个用例。通常把彼此有关系的一组用例显示在一张图上。

我们必须针对每一个用例给出一个详细的说明。这些说明包括用例的正常行为，可选行为以及前约束和后约束条件。所有这些都包含在被称为用例说明书或用例策略的文档中。

3.2.1 流程步骤
需求捕获流程的步骤可以总结如下：
1. 在说明文档中描述问题的概况，描述其解决方案应有的特性。
2. 找出用例和参与者，并在用例图中显示它们之间的关系。
3. 对用例加以详细说明，包括常态行为，可选行为，前约束和后约束条件。
4. 在需求补充说明书中描述所有非功能性的需求。
在渐进的开发过程中，我们会根据用例的重要程度来选择处理用例的顺序。早期的过程会着重于捕获重要用例的关键行为。