说明：

1、这里的用例指的是需求用例，不是设计用例；

2、引入“需求用例”目的在于核心功能的补充描述；

3、核心功能最好的描述方式仍然是语言文字；

概要：

需求用例的使用会有很多误区，即便是老手也容易出现问题！如果刚开始接触需求分析、撰写《需求规格说明书》或起步从事业务需求分析工作，那么业务需求用例会是一个好的工具。需要强调的是，它只是一个辅助工具而已，用的不好对项目发展时有阻碍作用的；

具体内容，如下：

1、业务用例想当然

我看到有人用这样一个用例图来做案例，一眼感觉很别扭，一时说不出问题出在哪里。

索性我自己根据内容画了一个，如下：

对系统管理员来说：分类管理与用户管理是一个层级上的；而作者及读者也同样会存则信息分类的问题；

所以把握用例的层次非常重要！

 2、用例分析过度

用例分析的目的我们说啦，是为了对核心功能做补充；在用例的基础上核心功能目标概念清晰了即可；如下：

首先，上图整体看上去有点吓人了。东西太多，谁能一下看清楚？而且上面的用例是可以合并的；

因此，上图是过度的业务用例；

插一句牢骚话：

项目分析阶段，我宁可用绘制上图的分析人员，也不会去用满嘴空谈的“高手”、“行业专家”， 一切从实际出发，对项目有意义的弯路可以走！

3、正确识别用例的标准-从用例标准入手

上图中的几个错误

1、所有的维护项都应该从新描述；

2、维护管理员登录权限，应该被定义为更新管理员权限与查看管理员权限；

修改上图如下：

结论：

1、业务用例不是设计用例；

2、业务用例是描述用户对系统的操作，不应包括系统自身实现的造作；

3、业务用例的修辞要准确，用户一眼看不懂、词汇模糊的用例是无效的用例；

4、没有业务用例定义的标准的用例，都是没有价值的用例；

5、增删改(更新)不是一个用例，是系统必须做出的机器操作（“序列项”）；

６、查询是一个“序列项”，与更新不同的是，在这个用例中即使没有也可以；如：更新管理员权限，不一定非要查询；

附录：我的规格描述模板

（完）