软件开发的难点之一是如何了解客户的需求,现实工作中,开发者们就像瞎子摸象一样从用户的根枝末节来勾画需求,而这一方面耗时巨大,另一方面很难获得完整的需求,于是就有频繁的变更,搞得甲乙双方都痛苦不堪。
于是有了面向对象的“敏捷”开发方法,其特点是利用用例图、类图(对象建模图)、序列图、活动图等各种图示来力图系统性地展示客户需求。这种方法明显比传统的需求析方法进步了很多,对于开发者来说可以更方便的找出需求后面的内在数据联系,但很可惜的是这种方法体系对于客户来说就像“天书符号”,对于初级的项目成员,掌握这种技术也非常困难,很多团队往往因为“道行不够”而陷入困境。
有没有更好的办法使用户和开发者都能很快协调一致呢,答案是需要二者有相同的“语言”来沟通,即应该找到一种二者都能很好理解的需求梳理方法,通过业务流程的描述来进行梳理应该是一个非常好的途径,这是二者能够找到共同的思考点。
但是如何梳理这个业务流程呢? 用户眼中并没有一个流程图的清晰框架,他只知道谁干了什么事,会有什么结果,那么开发者就需要帮助用户对业务流程进行系统化的梳理。我们用如下图示先来看看业务流程的数据内在联系。
这个示意图展示了需求与业务流程的联系,业务在进行中会与各种提交物打交道,而流程的流转是通过操作或者叫任务进行的,这里就可以看到一个业务流程的业务流转过程的大致关系,即提交物、执行人和操作。现实开发中,不论传统的流程图也好还是UML图也好&#