軟件開發的難點之一是如何瞭解客戶的需求，現實工作中，開發者們就像瞎子摸象一樣從用戶的根枝末節來勾畫需求，而這一方面耗時巨大，另一方面很難獲得完整的需求，於是就有頻繁的變更，搞得甲乙雙方都痛苦不堪。
於是有了面向對象的“敏捷”開發方法，其特點是利用用例圖、類圖（對象建模圖）、序列圖、活動圖等各種圖示來力圖系統性地展示客戶需求。這種方法明顯比傳統的需求析方法進步了很多，對於開發者來說可以更方便的找出需求後面的內在數據聯繫，但很可惜的是這種方法體系對於客戶來說就像“天書符號”，對於初級的項目成員，掌握這種技術也非常困難，很多團隊往往因爲“道行不夠”而陷入困境。
有沒有更好的辦法使用戶和開發者都能很快協調一致呢，答案是需要二者有相同的“語言”來溝通，即應該找到一種二者都能很好理解的需求梳理方法，通過業務流程的描述來進行梳理應該是一個非常好的途徑，這是二者能夠找到共同的思考點。
但是如何梳理這個業務流程呢？ 用戶眼中並沒有一個流程圖的清晰框架，他只知道誰幹了什麼事，會有什麼結果，那麼開發者就需要幫助用戶對業務流程進行系統化的梳理。我們用如下圖示先來看看業務流程的數據內在聯繫。
這個示意圖展示了需求與業務流程的聯繫，業務在進行中會與各種提交物打交道，而流程的流轉是通過操作或者叫任務進行的，這裏就可以看到一個業務流程的業務流轉過程的大致關係，即提交物、執行人和操作。現實開發中，不論傳統的流程圖也好還是UML圖也好，主要關注的是操作，以及操作間的關係，並都是以操作來確立開發內容，而用戶關注的主要是需求與提交物（即操作的結果），因此很難找到交集。
我們是不是可以從其他角度思考問題呢。假設我們從業務發現了一個需求，從需求確立符合需求的操作，並根據操作來確立提交物及執行者，同時基於操作，我們會發現新的操作條件、內容等需求，進而不斷深入完整的構建出整個業務流程體系，不就可以在用戶和開發者之間找到一個共同語言了嗎。 同樣，在提交物、執行着方面都會有需求提出，也會不斷豐富整個業務流程體系。
業務流程體系的建立不僅對軟件開發有幫助，對業務流程的管理也很有幫助，他會幫我們找到業務流程的漏洞，進而找到業務彌補漏洞的可行方法。另外，我們在辦理業務時往往被要求提交很多完全沒有用處的表格，這可能是原來曾經有相應的操作與需求，後來取消了，但提交物還保留，給我們的客戶體驗帶來很大麻煩，有了這個體系，就可以幫助我們發現那些不再有意義的提交物了。
現實工作中，往往需求很籠統，於是在細化過程中，需求往往被細化爲若干子需求，當某個需求完整的被其下所有子需求所描述時，該需求就變成了一個分組的標識而已，這時，在需求細化子需求的過程中，需求的操作也可能被細化，乃至遷移到子需求中。這樣就有助於我們精細的梳理業務流程及需求體系了。
再發散一下，對比看上圖與UML的關係吧：
- 用例圖自然描述的是操作執行者的操作及操作關係，是以執行者的視角看問題的結果。
- 狀態圖顧名思義就是以提交物狀態視角看問題了；
- 活動圖或者傳統的流程圖試圖把操作定義個先後順序（這裏面有味道呦，大家可以仔細品味一下，以後再說說這個順序的缺陷問題），
- 對於用途最大，也是最有意義的類圖（對象建模圖），他貌似與提交物有關係，但又似是而非，實際則展示的是另一種關係- 業務間關聯，如果我們可以把業務劃分爲若干子業務，就會發現子業務之間的聯繫就是這種對象關聯，比如考勤業務、休假業務與職員業務之間也是存在着一對多/多對多的關聯的。
- UML並沒有對提交物有什麼作爲，所以用戶很難理解對象的概念，它裏面有些數據與提交物有關，但分散在各處的提交物又可能都指向同一字段。所以他在架構設計體系中是存在短板的。
針對這種業務流程梳理模式，我們開發了一款應用構建產品，有興趣的網友可以到普知傑網站（也可通過谷歌搜索到）瀏覽並試用
相關文章請看：
探索流程的奧祕之一 - 從Petrinet的令牌生成機制缺陷看新的流程令牌生成方式