今天在看《Agile Software Development》，读到附录中关于UML的介绍，不禁慨叹：我以前在UML的时候怎么就那么的蹩脚呢，特别是在描述需求的时候。
我刚刚设计了一个项目，一开头就碰到一个头疼的问题——需求分析。我想取消我们以前那种繁杂的用文字描述的文档方法，采用UML的图形化来表示。取消的原因有两个，一是项目的组员不怎么愿意看那个文档来了解需求，我们这些搞技术的文字表述能力都不咋样，自己的东西自己看还好，给别人看就禁不住考验了；二是那个文档写起来太麻烦，以后需求改变了，没有时间也没有精力改那个文档，组员之间也是通过口头或者mail里面的只言片语来沟通需求，结果文档就成了一个摆设，需求到最后也没有真正管理起来。
可是怎么用UML来清晰的描述需求呢？认真看了《UML Distilled》，这本写得很通俗易懂，很容易上手。然而在具体的应用过程中，却碰到了麻烦。能够表述需求的，就是那个用例图了，领域图也可以勉强用用。更加要命的是，用例图在描述需求的时候显得太简单了，就是Actor加上Use Case，几乎是把显而易见的东西画了简单明了的图而已。而那个领域图，更加偏向分析设计方面，也不适合跟不懂技术的人员沟通。在这种情况下，只有采用图形+文字的描述方法，通过简单的图形配上大段的文字描述。这也使我一直耿耿于怀。
读了《Agile Software Development》中关于UML的介绍之后，让我有了新的启发。比如说用例图吧，可以通过扩展点(extension point)，使用《extend》关系来连接用例。举例说，客户在买单的时候，可以选择多种支付方式，每种支付方式有不一样的处理流程。如果把买单作为用例A，而把多种支付方式作为用例B1,用例B2等，那么用例B1，用例B2就扩展了用例A。这样准确的描述了多种支付方式的需求。其中关于《include》关系的描述也有用途。这些方法以前我也看到过，但是没有今天看得这么清晰。也许是在经历了挫折之后，看到一种新的解决方法，格外的注意。
不过虽然在UML的图形表示法上取得了一些进展，需求管理的根本问题还没有得到解决。有很多的需求（至少客户这么认为），比如：界面上的要求、操作上的要求（要支持触摸等）、流程上细化的需求（要按照星期几促销等）等等，所有的这些需求，跨越了项目范围、关键流程、细化的流程、界面要求等等，怎么管理起来真是一个问题。
我正在思考，也有了一些眉目，这些思考就留在我的下一篇文章中吧。
