2.1.1　用例模型

当我们经过一番需求调研，将需求中的第一手资料从调研现场捕获回来以后，接下来应当怎样进行分析整理呢？不少团队对此都比较迷茫，没有一个统一而有效的方法，往往想到哪里就做到哪里。采用这种方式，一些问题想到了就做了，没有想到的则忽略了。但实际上，需求分析不应该是姜太公钓鱼，而应当是拉网排查。任何一个疏忽都可能给项目研发带来风险。因此，我们应当采用一套成熟而完整的分析方法，稳步有序地完成分析工作，让需求的分析与整理完整而有效。这套成熟而完整的分析方法就是用例模型。

用例模型是一套基于UML用例图进行需求分析的实践方法，它将要分析的业务系统当成一个黑盒，描述了系统到底为用户提供了哪些功能，以及这些功能到底被哪些用户使用。同时，它以图形化的方式来表达需求，是沟通用户与技术人员的重要桥梁。

一般来说，在一个用例模型中通常有三种元素：用例（User Case）、参与者（Actor）与系统边界（Boundary）。

用例，描述的是系统为用户提供哪些功能，也就是系统能为用户做什么，通常被绘制成一个椭圆。

参与者，就是使用本系统的那些人，他们按照职责被划分成不同的角色。然而，更加广义的参与者是指那些站在系统外部，触发系统去执行某个功能的外部事物，它不仅包括角色，还包括时间与外部系统。系统按照某些时间周期自动执行任务，触发这些任务的是系统本身，但是系统会按照某些既定的周期定期执行，因此我们会在参与者头上绘制一个时钟。外部系统是指在本系统之外触发本系统执行某些操作的系统，比如电商网站在进行支付的时候，会调用那些支付系统，对于支付系统而言，电商网站就是它的外部系统，它被绘制成一个小方块。

最后是系统边界，也就是系统要实现的功能范围，通常被绘制成一个虚线的方框。在用例分析阶段，系统边界的确定对软件项目极其重要。软件的实质是对真实世界的模拟，但真实世界又是无限广大的，因此它必须有一个范围，这涉及软件开发的工作范围与工作量。然而，在软件开发过程中，一个极其重要的风险就是客户不断地变更系统边界，导致开发工作量越来越大，最终导致项目失败。所以，必须在用例分析阶段确定系统的边界。客户在需求变更的时候会扩大系统边界，那么我们可以记录下这些需求。但这部分的开发工作必须在下一个阶段开展，从而有效避免项目的进度失控。

通常情况下系统边界不用真正绘制出来，因为在用例图中被绘制成用例的必然是系统内部的功能，被绘制成参与者的必然是系统外部事物。通过区分用例与参与者，就可以顺利地落实系统边界。

那么，运用用例模型，该如何由粗到细地分析一个复杂的业务系统呢？我们以“中医远程智慧医疗平台”为例，看一看用例模型的分析过程。