希望加以说明，最好能举个例子！
------解决方案--------------------------------------------------------
作需求的目的是什么呢？
我的目的是未设计做准备资料。做需求分析的时候，我们手中的资料是用户要求的功能，有用户工作中的各种单据报表。这是我们的出发点。
再看目的地。需求分析的目的是设计。那么设计要做什么？设计要解决的问题是如何编码。也就是要给出类的结构。无论概要设计或是详细设计，是封装程度不同的组件。也就是说我们要在设计的时候，组装出最后的类来。
那么，用什么东西来组装类？类里只有两种东西——数据和方法。用户对流程的描述陷于细枝末节也好，纠缠不清也好，总之，那不能用来直接对应到最后的方法。用户的单据报表，也无法需要分析重组。甚至用户会丢失很多环节。
那么如何做需求分析就很清楚了。我的需求分析，就干一件事情，识别出用户描述中的方法和数据，并分离出来。我不在乎我分离的数据有多少冗余，也不怕多。我也不关心我找到的方法有什么性能，有什么复杂度，只要在一个流程中被当作独立的功能来看待。
那么，需求的工作是从客户的描述找到数据和方法。那么找我们的uml图吧。那个图即有数据又有方法？
类图----有数据，有方法，类中就封装这两个东西。但是需求阶段的类图无法作为最终成果。而且直接画类图和拍脑门想也没有什么区别了。类图是需求分析的一个产物，需求的类图是整个分析设计的一个中间环节。
用例图--两者都没有。
状态图--有数据，有方法。但是限制是这些数据需要用状态来表达，方法仅仅是与状态相关的。也就是说不是所有的数据和方法都能用状态图表达。
活动图--作为流程图的替代者，专门用于描述流程。即可以用整个活动图作为一个方法的描述。也可以将活动图的一个活动看作一个方法。而且，活动图中活动之间可以画对象流。
如果我们将活动图中所有活动间的对象流补全，并连接起来，就能够看到一个完整的方法与方法所要操作的数据的关系。而且可以弥补用户最初叙述中缺失的环节。
所以我喜欢用这个。这个图中的泳道，正好把活动和对象粗略分类，形成最初的对象模型。
时序图，写作图--这两个图是一体的，能够呼唤。其重点是函数的调用关系，时序图更加强调时间顺序。但是用这个图，你永远也分析不出你有多少数据要操作，他们的结构是什么样子的。十分遗憾的是，以目前我所看的设计，时序图是设计的主流，无论需求期间，还是设计阶段。很多文档或设计中，仅仅只有用例图，类图和时序图。不过这样的东西，做得好的都很难见到。
组件图，部署图，不分析了。
所以，对我来说，没有活动图的需求是不完整的。因为这样的需求做完之后，无论是我，还是别人，做设计的时候都无法从需求分析的结果中获得所有信息。这就意味着设计人员还要去翻调研的资料，才能知道自己的方法要操作什么数据。这样的需求分析，就是给自己在设计的时候找麻烦，而且浪费时间，弄不好还要害同事。
需求，就是明确用例。然后分解大用例。之后用活动图分析每个用例的流程。在此期间能够获得主要的方法流和数据流。找到重要的方法、复杂的方法，去详细分解。然后把具体数据填充到得到的数据结构中。然后通过流程图，把与之相关的活动作为方法，填到数据结构的类中，形成需求分析中的类图。
这样，我的目的就达到了，我的类图中即包含了所有的功能方法，还有与之对应的数据。我在分析的时候，可以在某种程度上抛开那些需求分析中的流程图，仅根据需求中的类图，来做我的设计。把需求的类分解或合并，补充，明确，或分层。
--------OK，需求结束，需求的时候，我偏爱活动图！！！