您当前的位置: 软件开发的难点之一是如何了解客户的需求，现实工作中，开发者们就像瞎子摸象一样从用户的根枝末节来勾画需求，而这一方面耗时巨大，另一方面很难获得完整的需求，于是就有频繁的变更，搞得甲乙双方都痛苦不堪。
于是有了面向对象的“敏捷”开发方法，其特点是利用用例图、类图（对象建模图）、序列图、活动图等各种图示来力图系统性地展示客户需求。这种方法明显比传统的需求析方法进步了很多，对于开发者来说可以更方便的找出需求后面的内在数据联系，但很可惜的是这种方法体系对于客户来说就像“天书符号”，对于初级的项目成员，掌握这种技术也非常困难，很多团队往往因为“道行不够”而陷入困境。
有没有更好的办法使用户和开发者都能很快协调一致呢，答案是需要二者有相同的“语言”来沟通，即应该找到一种二者都能很好理解的需求梳理方法，通过业务流程的描述来进行梳理应该是一个非常好的途径，这是二者能够找到共同的思考点。
但是如何梳理这个业务流程呢？ 用户眼中并没有一个流程图的清晰框架，他只知道谁干了什么事，会有什么结果，那么开发者就需要帮助用户对业务流程进行系统化的梳理。我们用如下图示先来看看业务流程的数据内在联系。
这个示意图展示了需求与业务流程的联系，业务在进行中会与各种提交物打交道，而流程的流转是通过操作或者叫任务进行的，这里就可以看到一个业务流程的业务流转过程的大致关系，即提交物、执行人和操作。现实开发中，不论传统的流程图也好还是UML图也好，主要关注的是操作，以及操作间的关系，并都是以操作来确立开发内容，而用户关注的主要是需求与提交物（即操作的结果），因此很难找到交集。
我们是不是可以从其他角度思考问题呢。假设我们从业务发现了一个需求，从需求确立符合需求的操作，并根据操作来确立提交物及执行者，同时基于操作，我们会发现新的操作条件、内容等需求，进而不断深入完整的构建出整个业务流程体系，不就可以在用户和开发者之间找到一个共同语言了吗。 同样，在提交物、执行着方面都会有需求提出，也会不断丰富整个业务流程体系。
业务流程体系的建立不仅对软件开发有帮助，对业务流程的管理也很有帮助，他会帮我们找到业务流程的漏洞，进而找到业务弥补漏洞的可行方法。另外，我们在办理业务时往往被要求提交很多完全没有用处的表格，这可能是原来曾经有相应的操作与需求，后来取消了，但提交物还保留，给我们的客户体验带来很大麻烦，有了这个体系，就可以帮助我们发现那些不再有意义的提交物了。
现实工作中，往往需求很笼统，于是在细化过程中，需求往往被细化为若干子需求，当某个需求完整的被其下所有子需求所描述时，该需求就变成了一个分组的标识而已，这时，在需求细化子需求的过程中，需求的操作也可能被细化，乃至迁移到子需求中。这样就有助于我们精细的梳理业务流程及需求体系了。
再发散一下，对比看上图与UML的关系吧：
- 用例图自然描述的是操作执行者的操作及操作关系，是以执行者的视角看问题的结果。
- 状态图顾名思义就是以提交物状态视角看问题了；
- 活动图或者传统的流程图试图把操作定义个先后顺序（这里面有味道呦，大家可以仔细品味一下，以后再说说这个顺序的缺陷问题），
- 对于用途最大，也是最有意义的类图（对象建模图），他貌似与提交物有关系，但又似是而非，实际则展示的是另一种关系- 业务间关联，如果我们可以把业务划分为若干子业务，就会发现子业务之间的联系就是这种对象关联，比如考勤业务、休假业务与职员业务之间也是存在着一对多/多对多的关联的。
- UML并没有对提交物有什么作为，所以用户很难理解对象的概念，它里面有些数据与提交物有关，但分散在各处的提交物又可能都指向同一字段。所以他在架构设计体系中是存在短板的。
相关文章请看：
探索流程的奥秘之二： 流程的步骤是什么东东 .
探索流程的奥秘之一 - 从Petrinet的令牌生成机制缺陷看新的流程令牌生成方式