OO系统分析员之路--用例分析系列（1）--什么是用例

chenxm21

最初由 pushboy 发布
[B]恩，楼上说得对。
昨天在讨论的时候，也提到类似的观点。很多客户实际上对于电脑、软件都没有什么概念，而我们在需求分析、调研的时候，总是很容易的使用各种设计、软件、系统的思想和术语进去。这样，在很多时候，成了我们一厢情愿的事情，最后会发现，客户的需求总是不断的变化，原因可能就是我们在开始的时候的错误的引导
业务分析和业务建模的时候，需要抛弃电脑软件系统的概念，单纯的成为一个业务人员角色
这样的理解，不知道对不对 [/B]

有一定的道理，但要防止一种倾向，就是被用户带着走，完全根据用户的想法或者说是一些根本不是很成熟的想法拽着走。

需求分析不仅要能反映用户的一些要求，当然还要能够一定程度上取挖掘潜在的需求，改正用户的一些不合理的或者不合逻辑的要求，你刚才也说了，很多用户根本不懂的计算机方法的领域知识，他们的需求片面，不合理也是很正常的。

所以在需求分析的过程中 不仅要能反映客户的需求，而且要能引导客户的需求，挖掘客户的潜在需求。

pushboy

最初由 chenxm21 发布
[B]

在进行用例分析之前，确定有多少个actor，但是怎样确定有多少个actor呢？ 确定了有这么多actor后，又怎样确定actor和usecase有关系呢？

呵呵，这样一步，一步就使用例需求分析了。一般来说我们可以通过和用户积极交互，应用场景方法，brainstorming方法等来一步一步draw出我们的真个用例框架。但我们会说，这个过程是如此的不可控制，如此的不可衡量，信息是如此的不可传递性，我们怎样来做这个分析的过程呢？其实最近我也在思考这些问题，如何能够把一些形式化的语言，或者类形式化的表达方式引进需求分析的过程，而非像现在的用例分析过程一样，完全是个经验的积累，我也想这也是为什么这么多人没有真正掌握用例分析的原因了。 [/B]

是啊，从我自己工作中感觉来看，基本上是一个经验的积累。
现在很多需求人员和设计人员是分离的，而且，需求人员很少了解软件系统，设计人员很少了解业务流程 —— 或者说，即便了解，也更多的带上了设计的烙印 —— 这样在前期，基本上就存在一个脱节的现象
需求和客户不一致，设计和需求不一致，开发和设计又有偏差，最后出来的东西，总是和开始的规划有相当的距离。
理论上总是很好描述的，但是在实际工作中，受限于环境和能力，总是会有各种各样的问题产生而不尽如人意

coffeewoo

今天偶然发现这里就我写的这个东东有了些讨论，很开心，这也是我写它的出发点。对于业务建模来说，UML只提供了工具，RUP只提供了过程，到底怎样才能把工具和过程结合起来，把需求说清楚？怎么做？我在工作过程中总结出一套自己的方法，我想把这些方法写下来，跟大家讨论。
目前这个系列文章已经写到了第5部分了。欢迎大家去我的blog http://coffeewoo.itpub.net 看，希望不吝赐教。

coffeewoo

最初由 pushboy 发布
[B]那么，是否可以这样理解。
实际上，是以actor为中心的，而不是usecase
有了actor，才会有case；case是actor的动作
我们在讨论case之前，首先要确定actor，而不是相反 [/B]

我觉得这个理解不完整。应该这样说，需求的获取，业务模型的建立以actor为中心。因为actor是系统的驱动者和系统存在的意义。而系统开发，不论是分析，设计，测试，部署等等过程则又是以usecase为中心。

actor为中心的目的是为了准确的获取需求，是对外的；usecase为中心是为了把需求准确的传递到后续的一切软件过程中去，是对内的。这样理解应该更完整一些。

coffeewoo

最初由 chenxm21 发布
[B]

在进行用例分析之前，确定有多少个actor，但是怎样确定有多少个actor呢？ 确定了有这么多actor后，又怎样确定actor和usecase有关系呢？

呵呵，这样一步，一步就使用例需求分析了。一般来说我们可以通过和用户积极交互，应用场景方法，brainstorming方法等来一步一步draw出我们的真个用例框架。但我们会说，这个过程是如此的不可控制，如此的不可衡量，信息是如此的不可传递性，我们怎样来做这个分析的过程呢？其实最近我也在思考这些问题，如何能够把一些形式化的语言，或者类形式化的表达方式引进需求分析的过程，而非像现在的用例分析过程一样，完全是个经验的积累，我也想这也是为什么这么多人没有真正掌握用例分析的原因了。 [/B]

这也是我一直在思考的问题。我觉得分析过程很难用一个统一的方法来规定，因为我们总在面对不同的客户不同的业务。但又不是章可循的，我总结了一些步骤，可以广泛讨论。我觉得信息的可传递性是建立在文档上的，很多人在做用例分析时，只记录结果，不记录分析过程，或者根本就不知道分析过程方法，信息就丢失了。我将尽力在系列文章里说明这些方法。比如，actor来自于stakeholder，usecase来自于actor访谈录等等