Aaron之无主题空间

皆主题,此谓无主题。
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

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

Posted on 2009-05-31 14:31  Aaron  阅读(641)  评论(0编辑  收藏  举报
本文将自己学习和实践中的一些小心得分多个短文写出来;力求重实践。本文不欲说明如何找出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 CaseUse Case描述的只是系统的功能需求。关于需求的“全集”参见《需求模型》。

 

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

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