需求文档之用例识别

      用例识别对需求来说至关重要，本文整理心得体会，也请多多指正。

1.     用例图

由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。

?  用例图是需求分析的产物，主要作用是描述参与者和用例之间的关系，帮助用户可视化了解系统的功能。

?  用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。

?  用例方法是完全从外部来定义系统功能，它把需求和设计完全的分离开来。

2.     用例

用例表示系统的一项外部功能，它从用户的角度分析所得的需求。为完成一个相对完整的一种功能，系统执行的一系列动作的集合

?  是外部可见的一种系统功能

?  代表的是一个完整的功能

?  有一系列动作

3.     识别用例的要点

3.1.          可观测→用例止于系统边界

描述交互，而不是内在的系统活动

3.2.          结果值→用例是有意义的目标

业务功能，非系统处理

3.3.          系统执行→结果值由系统生成

系统需要处理的，有系统生成的；

3.4.          由参与者观测→业务语言、用户观点

从参与者的角度来描述，使用业务语言；

3.5.          一组用例实例→用例的粒度

用例要有路径，路径要有步骤；而这一切都是可观测的，最常犯错误：粒度过细，陷入功能分解，过细的粒度，一般都会导致技术语言的描述，而不再是业务语言。

C(Create)、R(Read)、U(Update)、D(Delete)的粒度问题

所有业务最终会成为CRUD？CRUD能为Actor提供价值？CRUD掩盖业务，锐变成关系数据库的建模：“系统就是数据的增删改查”，关心数据的存储和维护，反而忽略了用户的目的。

如果CRUD不涉及复杂的交互，一个用例“管理××”即可；

不管是C、R、U、D，都是为了完成“管理”目标；

甚至很多种的基本数据管理都可以用一个用例表示；

可以把包含复杂交互的路径独立出去形成用例

3.6.          用例命名

使用动词开头；

需求文档之用例识别