程序员做项目管理的必备技能（下）

上节课我们通过几个示例给大家讲了用例图的基本语法，用例图的是通过图形描述系统的两个问题：

1. 这个系统有谁在用

2. 这些人通过系统能做什么事情

关于它的语法，其实没有那么多，我们知道通过用例图怎么描述下面这个商品管理页面的需求

以及分清楚下面两个用例图的区别即可

这些我们都在上节内容中有过详细讲解，今天更多的是来给大家分享一些使用上的建议，你的用例图怎么准确描述出系统功能、以及怎么靠用例图作出更详细的需求规格给到甲方确认或者让程序员来进行实施，掌握这些足以让我们应对项目经理的客户对接、产品经理的需求拆解等工作。

在继续本节的内容前再提醒一下苹果手机的用户，因为苹果税的存在本专栏在微信直接订阅价格会高于安卓用户，所以专栏在小报童同步更新，苹果手机用户可以通过扫描二维码在小报童订阅阅读，规避额外开销。

用例的粒度和建议

跟前面学过的活动图中活动的粒度一样，用例图中用例的粒度应该是多大或者是多小在UML里并没有明确规定和固定的法则，需要通过实践慢慢体会，这里给大家一些实践后的建议。

刚开始实践使用用例图表示需求的新手，建议遇到能拆分成子用例的用例时都进行拆解和详细说明，等熟练掌握用例图之后，如果负责的业务需求会在系统中有大量类似“管理某某”的用例，一般只会选择其中一两个进行分解和详细说明，而其他相似的“管理某某”用例只会用文字注释说明需要注意的地方，不会再逐一分解成子用例进行详细说明。

以上是对用例粒度的建议，大部分需求的用例中，CURD类的用例占比较大，下面还有一些实践上的建议：

• 在合作方（客户、产品PM、业务、与系统有关的其他职能人员）能准确全面理解的基础上用例越精简越好，用例图是降低沟通成本提高沟通效率的工具，并不是完全替代我们沟通的工具。

• 我们不应该盲从的从客户、需求源头人员的想法中直接导出用例，用例应该更多地从系统的目标、待解决的客户问题而推导出来的。

• 用例不应该使用技术语言来描述，要用使用这个系统的人们能看懂的语言，保证他们能够看懂。