杂话用例建模【1】：需求即Use Case？非也。

本文将自己学习和实践中的一些小心得分多个短文写出来；力求重实践。本文不欲说明如何找出Use Case、如何描述Use Case等，因为这方面资料很多。我只是将我自己的一些体会和我曾经或正在困惑的问题写出来讨论。因此本文亦不会对一些常见的术语进行特别说明，如Use Case、RUP、MSF等。
写成一篇篇小短文是因为我自己喜欢读小短文，可参见“让它们更短些吧——呼吁大家让我们的互联网文字更具可读性”。

 

需求=Use Case Model?非也。

并不是任何类型的项目都适合采用Use Case来描述需求；即便适用Use Case，那么Use Case也不能描述需求的全部，Use Case只能描述功能需求。

Use Case描述的是它的执行者和系统之间的交互，是对系统或子系统的某个连贯的功能单元的定义和描述。所以Use Case擅长的是描述特定场景下执行者和系统之间的交互过程，从而定义出系统的功能。所以最常见之用于描述MIS类项目的软件需求。

那么一般来说，Use Case不适合描述哪些需求呢？技术、算法相关的，如数据挖掘，如服务程序；用户体验需求；技术改造和升级需求；等等。

因此在新项目开始前，应先小酌一下，Use Case Modeling是否是最好的捕获需求的方式。

那么软件需求除了Use Case还有什么？对于做需求分析的人来说，绝不要忘了需求不仅只有Use Case。Use Case描述的只是系统的功能需求。关于需求的“全集”参见《需求模型》。

 

离题点说，Use Case除了描述软件需求，还可以做什么？

Use Case是描述“用户”和“系统”之间交互的很好的形式。当我们把“用户”和“系统”的外延放大时，发现Use Case可以做很多事情。比如，我曾发现有公司使用Use Case来描述公司内部的业务流程，比如把某部门当作一个“系统”，与该部门产生“业务关系”的人是用例的执行者。