對於經常變化，或多樣性很高的業務規則，直接由程序員使用開發語言編寫並不明智。如使用java，c#等語言直接表達企業的規定、制度或管理辦法，甚至不定時修改的計算公式，這並非合理的做法。編程語言、數據表結構、分佈式部署等因素綜合之後，這些業務邏輯會變得不好維護。傳統的IT專家會認爲只要需求做得好，分析透徹，所有的系統需求都會被定義，可以使用一定的表結構和設計來降低或解決這些頻繁的修改或多樣性。但如果業務的變化範圍很大，多樣性是天馬行空的，或當前根本沒有需求，而是決策者在一定時期根據形勢而作出的決策，那即使不考慮金錢成本，業務系統是否又能快速響應呢？
引入規則解決方案，是一個大趨勢，與傳統相對，她對頻繁變化和多樣式的決策反應非常的快，是一個較合理的手段。引入之後，業務系統的生命週期，如軟件需求採集，系統分析設計，編碼，測試和維護都會發生深刻的變革。
[img]http://dl2.iteye.com/upload/attachment/0112/1562/5f632a16-99ac-3d8e-ad93-5bdf03f3e28c.png[/img]
需求採集
在並行開發的情況下，對於新開發的系統，業務規則是作爲需求採集的一部分。業務規則的採集是通過不同的需求交付物（如領域模型和業務用例）來收集。從深層次來講，業務規則重點強調的是業務基本理由（規則背後的業務策略和動機），並不是關注被基本理由所驅動而產生的業務動作。相應地，我們需要特定的過程，角色，技巧和交付物去處理業務規則。同時，這些收集“業務規則”或“中間交付物”的過程和技巧，依賴於公司一直使用的傳統需求採集技術。如公司一直是使用用例來採集功能需求的，那麼業務規則的採集就應該基於這些用例所表達的決策步驟的上下文信息。對於重構系統的情況，現存的系統和文檔可以作爲需求採集一個重要內容，也是業務規則的來源，這種情況下，規則發現的過程和技巧是同樣適用的。
在非同步開發的情況下，我們需要清晰地把業務規則與過程、角色、技巧和交付物分開。與特定的業務程序的需求採集分開的。
系統設計
系統的分析與設計，要更加關注業務並依賴規則引擎去執行業務決策，除此之外，系統的基礎架構應該要儘量少地被特定的規則解決方案所影響。程序的分析和設計時，會有更多的規則或決策方面的內容。我們需求做規則分析的工作，包括將重複的業務邏輯分解爲若干簡單的自動化的邏輯，檢測規則之間的冗餘、重複或衝突，記錄業務規則的決策意圖。還需要根據業務需求或程序設計的需求，將規則打包成一個規則集，該規則集由測試、部署和執行等一體化的組件組成。我們還要清晰地設計和列出業務規則管理系統(vrs)的管理部件，包含規則庫的結構，規則元數據，用規則改變流程的措施等等。最後我們要設計業務程序與規則管理系統的相互調用接口。
編碼
基礎架構的代碼編寫，不受規則解決方案的影響。但是決策邏輯將會被分離出來，通過一個業務規則管理系統(vrs)進行編寫，我們需要新的流程，技術，技巧，角色和工具去編寫業務規則。這樣的分離的結果是這兩方面的程序可以減少耦合並相對獨立地推進。當項目的基礎架構完成之後，不用等到第一個業務規則代碼類編寫出來和測試，我們就可以參與到項目中。這種情況下，客戶會懷疑"爲什麼還在需求採集中，就已經將研發團隊放回公司了"，但我們在未寫一個業務邏輯層代碼之前，就已經完成所有的業務規則的編寫，大部分規則也已經被測試。這樣，規則編寫問題和系統架構會相對獨立。
測試
在傳統的系統開發中，功能測試是在程序已經被開發出絕大部分時纔會進行的。進一步講，黑盒功能測試沒有爲程序業務邏輯方面的調試提供什麼幫助，反之白盒測試需要我們分析和辨別複雜邏輯運行環境中的邏輯路徑。而使用規則解決方案，我們可以用較少的架構代碼，測試相對獨立的功能。這就像通過代碼執行功能的單元測試，可以辨別，跟蹤，修改獨立的邏輯路徑。獨立規則的測試能力是一個強大的驗證和確認的工具。
維護
在傳統的系統開發中，維護請求都走一條相似的實現路徑，不分業務規則還是基礎架構代碼，都基本這樣：管理員簽發維護請求，該請求會下發到IT人員的手，去實現、測試和部署。在規則解決方案的幫助下，業務規則或決策邏輯被獨立地部署和維護，我們有不同的業務流程來識別業務規則，並使用輕量級的規則部署機制。業務規則維護是整個業務管理活動中的一環。規則管理受同步或異步開發模式的業務規則解決方案所深深影響。
引入規則解決方案，是一個大趨勢，與傳統相對，她對頻繁變化和多樣式的決策反應非常的快，是一個較合理的手段。引入之後，業務系統的生命週期，如軟件需求採集，系統分析設計，編碼，測試和維護都會發生深刻的變革。
[img]http://dl2.iteye.com/upload/attachment/0112/1562/5f632a16-99ac-3d8e-ad93-5bdf03f3e28c.png[/img]
需求採集
在並行開發的情況下，對於新開發的系統，業務規則是作爲需求採集的一部分。業務規則的採集是通過不同的需求交付物（如領域模型和業務用例）來收集。從深層次來講，業務規則重點強調的是業務基本理由（規則背後的業務策略和動機），並不是關注被基本理由所驅動而產生的業務動作。相應地，我們需要特定的過程，角色，技巧和交付物去處理業務規則。同時，這些收集“業務規則”或“中間交付物”的過程和技巧，依賴於公司一直使用的傳統需求採集技術。如公司一直是使用用例來採集功能需求的，那麼業務規則的採集就應該基於這些用例所表達的決策步驟的上下文信息。對於重構系統的情況，現存的系統和文檔可以作爲需求採集一個重要內容，也是業務規則的來源，這種情況下，規則發現的過程和技巧是同樣適用的。
在非同步開發的情況下，我們需要清晰地把業務規則與過程、角色、技巧和交付物分開。與特定的業務程序的需求採集分開的。
系統設計
系統的分析與設計，要更加關注業務並依賴規則引擎去執行業務決策，除此之外，系統的基礎架構應該要儘量少地被特定的規則解決方案所影響。程序的分析和設計時，會有更多的規則或決策方面的內容。我們需求做規則分析的工作，包括將重複的業務邏輯分解爲若干簡單的自動化的邏輯，檢測規則之間的冗餘、重複或衝突，記錄業務規則的決策意圖。還需要根據業務需求或程序設計的需求，將規則打包成一個規則集，該規則集由測試、部署和執行等一體化的組件組成。我們還要清晰地設計和列出業務規則管理系統(vrs)的管理部件，包含規則庫的結構，規則元數據，用規則改變流程的措施等等。最後我們要設計業務程序與規則管理系統的相互調用接口。
編碼
基礎架構的代碼編寫，不受規則解決方案的影響。但是決策邏輯將會被分離出來，通過一個業務規則管理系統(vrs)進行編寫，我們需要新的流程，技術，技巧，角色和工具去編寫業務規則。這樣的分離的結果是這兩方面的程序可以減少耦合並相對獨立地推進。當項目的基礎架構完成之後，不用等到第一個業務規則代碼類編寫出來和測試，我們就可以參與到項目中。這種情況下，客戶會懷疑"爲什麼還在需求採集中，就已經將研發團隊放回公司了"，但我們在未寫一個業務邏輯層代碼之前，就已經完成所有的業務規則的編寫，大部分規則也已經被測試。這樣，規則編寫問題和系統架構會相對獨立。
測試
在傳統的系統開發中，功能測試是在程序已經被開發出絕大部分時纔會進行的。進一步講，黑盒功能測試沒有爲程序業務邏輯方面的調試提供什麼幫助，反之白盒測試需要我們分析和辨別複雜邏輯運行環境中的邏輯路徑。而使用規則解決方案，我們可以用較少的架構代碼，測試相對獨立的功能。這就像通過代碼執行功能的單元測試，可以辨別，跟蹤，修改獨立的邏輯路徑。獨立規則的測試能力是一個強大的驗證和確認的工具。
維護
在傳統的系統開發中，維護請求都走一條相似的實現路徑，不分業務規則還是基礎架構代碼，都基本這樣：管理員簽發維護請求，該請求會下發到IT人員的手，去實現、測試和部署。在規則解決方案的幫助下，業務規則或決策邏輯被獨立地部署和維護，我們有不同的業務流程來識別業務規則，並使用輕量級的規則部署機制。業務規則維護是整個業務管理活動中的一環。規則管理受同步或異步開發模式的業務規則解決方案所深深影響。
