让技术人员看得懂的流程（2）

                         ——用例模型

一般的管理流程都将软件项目划分为“需求->分析->设计->实现->维护”，对应的技术流程中首先也肯定是要将需求明确，而“用例模型”就是用于获得和分析需求的。

简单来说，用例模型就是要将客户的需求写下来。“需求”不是很好理解，更加通俗的讲法是“故事(story)”。我觉得“故事”这个词非常好，非常形象，非常容易理解！我们看看为什么“故事”更加容易适合说明客户要求：

（1）故事中有很多角色，而需求中也有很多角色；

（2）故事有具体的经过，有开始、进行、结束；而需求也是一个完整的流程，有输入、处理、输出。

（3）故事必须有意义，而需求对客户来说，也是必须有意义的；

 

具体的用例格式等这里就不详细描述了，大家上网搜索一下就知道了，如何更好的把握需求可以参考我的博文《需求分析的故事——如何练就需求分析的火眼金晴？》，下面我把用例模型阶段容易犯的错误重点说明一下。

1）“需求”和“功能”混淆

很多朋友在分析需求的时候，将“功能”和“需求”混淆起来，导致了需求的粒度不合理，或者把握不住重点的需求，我总结出一个很简单的区分办法：“需求是对客户有价值的东西，功能是为了实现需求而作的东西”。

以POS机为例：对于客户来说，“买单”是一个有价值的东西，因为客户买完单就可以把商品拿走了；而买单过程中的“读商品条形码”、“计算商品总额”、“打印购物清单”等都是功能，因为它们当中任何一个独立的功能对客户没有价值（你不会跑到超市“读商品条形码”玩吧:-P），只是为了实现“买单”而做的。

2）在用例模型阶段进行系统分解

除了容易将“功能”和“需求”混淆外，用例模型阶段还有一个常见的错误就是在用例模型阶段对系统进行分解。

以POS机为例，有的人将需求描写为：扫描机扫描商品条形码信息，然后将信息发给库存系统，库存系统返回详细的商品信息给交易系统……在用例模型阶段这样做是不对的，因为这样转移了我们的注意力：从关注用户需求转到了系统分析了。

记住：用例模型关注的是用户需求，不需要进行系统分解，把系统当做一个黑盒看待就可以了。

 

下面我们给出POS机一个简单的用例片段，有兴趣的可以自己写一个完整的（这个完整的可不简单哦，至少可以写3页）：

1）顾客携带商品到收银台；

2）收银员扫描商品条形码；

3）系统根据条形码获取并显示商品信息；

4）收银员重复2~3步，直到所有商品扫描完毕；

5）系统计算商品总额；

。。。。。。。。。。。。。。。。。。。。

n）系统打出商品清单，完成交易。 

===================2010.03.20补充==================

（经过garrodran99的提醒，补充SSD（系统顺序图）的内容，在此感谢garrodran99）

SSD即系统顺序图，目的就是站在系统的角度，以UML的顺序图来描述系统与“外部实体”（包括人、其它系统、输入输出设备）的交互过程，简单来说就是“图形化的用例”。

那为什么有了文字化的用例文档，还要图形化的SSD呢？其实很简单：字不如表，表不如图，因为图可以一目了然的看出交互过程。

可能有的朋友又要问了：既然图那么好，还要文字描述的用例做什么呢？有两个原因：第一个是客户不会用UML给你描述需求，客户只会用自然语言描述需求；第二个就是图形的优点是简洁、一目了然，但图形的缺点就是不能承载太多信息，详细和丰富的信息还是要文字来承载。

用一句话总结就是：交互用图形，说明用文字！

那么，是否一个用例就要写一个SSD呢？基本上不需要，因为SSD重点在描述系统的交互过程，如果用例本身没有什么交互、或者交互很少或者很简单，就不需要SSD。只有主要的、复杂的用例才需要SSD。