如果使用者故事告訴系統做什麼，那麼業務規則告訴系統如何決定。
一個功能在螢幕上可能看起來很簡單，但背後隱藏著許多規則：誰被批准、限制是多少、哪些案例被阻止、何時升級、需要哪些資料以及當兩個規則衝突時優先考慮哪些策略。
如果 BA 寫的規則不明確，Dev 常常必須猜測。以不同的方式進行品質保證測試。商家表示「我不是這個意思」。這是非常昂貴的返工來源。
1.什麼是業務規則？
業務規則是決定業務如何運作的限制、策略或條件。
例如：
- 18歲以下的客戶不得開設投資帳戶。
- 超過5億的貸款申請需要部門主管級別的批准。
- 折扣代碼僅適用於每位客戶一次。
- 用戶只能在預約時間前至少2小時取消預約。
- 缺少所需文件的文件必須變更為「需要額外」狀態。
好的規則必須足夠清晰，以便開發人員實施和 QA 編寫測試案例。如果規則只對業務聽起來合理而無法測試，那麼對於軟體BA來說它還不夠好。
2. 將規則分類以提出正確的問題
BA 應該在編寫細節之前將規則分組：
| 規則組 | 要問的問題 |
|---|---|
| 資格 | 誰有資格？誰不符合資格？ |
| 計算 | 計算公式是什麼？怎麼圓？ |
| 驗證 | 需要哪些欄位？格式/範圍/唯一是什麼？ |
| 授權 | 誰可以查看、建立、編輯、批准和刪除？ |
| 狀態轉換 | 哪個狀態轉移到哪個狀態？ |
| SLA / 時序 | 什麼是截止時間、等待時間、截止時間？ |
| 例外 | 當資料遺失、不正確、重複或過期時該怎麼辦？ |
| 合規 | 哪條規則來自法律、政策、審計或合約？ |
分類有助於 BA 不會提出隨機問題。對於每組規則，您知道哪些利害關係人需要確認以及哪些工件需要更新。
3.如何寫原子規則
原子規則是僅陳述一個條件或決定的規則。不要將許多想法合併在一個長句子中。
不好的例子：
客戶收入穩定、信用評分良好、無壞帳、記錄齊全，即可獲得貸款。
重寫：
| 身分證 | 規則 |
|---|---|
| BR-001 | 客戶最近 3 個月的平均收入必須 >= 15,000,000 越南盾。 |
| BR-002 | 內部信用評分必須 >= 650。 |
| BR-003 | 客戶在過去 24 個月內不得有第 3、4 或 5 組債務。 |
| BR-004 | 申請必須有完整的 CCCD、損益表和貸款申請。 |
每條規則應具有：
- 穩定的ID
- 來源利害關係人或來源文檔
- 版本或生效日期
- 業主批准
- 通過/失敗範例
- 測試影響
4.什麼時候使用決策表？
當決策取決於許多條件時，請使用決策表。
貸款申請審批功能範例：
| 條件/結果 | 規則 1 | 規則 2 | 規則 3 | 規則 4 |
|---|---|---|---|---|
| 收入>=1500萬 | 是 | 是 | 是 | 尼 |
| 信用評分 >= 650 | 是 | 是 | 尼 | - |
| 無壞帳 | 是 | 尼 | - | - |
| 所需文件齊全 | 是 | 是 | 是 | 是 |
| 決定 | 自動批准 | 人工審核 | 拒絕 | 拒絕 |
| 原因代碼 | AP-001 | RV-002 | RJ-003 | RJ-004 |
決策表幫助團隊了解條件的組合。它還可以幫助 QA 更快地建立測試案例：每一列幾乎都是一組測試場景。
5.如何寫出易於維護的決策表
一個好的決策表需要：
- 顯式條件是/否、範圍或枚舉。
- 符號
-僅當條件不影響決策時才使用。 - 每欄給一個獨特的決定。
- 如果系統需要顯示原因，則有原因代碼或訊息代碼。
- 如果多個規則匹配，則有規則優先權。
- 未列出的組合有預設情況。
如果木板太大，請勿嘗試將其塞入一塊木板中。我們按類別來分開：
1.資格審查。 2、風險排查。 3. 審批路徑。 4. 通知/訊息。
6. 從規則到使用者故事和測試案例
使用者故事範例：
As a loan officer
I want the system to evaluate loan eligibility
So that I can reduce manual screening time.
驗收標準：
Scenario: Auto approve eligible application
Given the applicant has income >= 15,000,000 VND
And credit score >= 650
And no bad debt in the last 24 months
And all required documents are complete
When the officer submits the application
Then the application status is "Auto Approved"
And the reason code is "AP-001"
可追溯性：
| 交流 | 規則 | 測試用例 |
|---|---|---|
| AC-001 | BR-001、BR-002、BR-003、BR-004 | TC-貸款-001 |
| AC-002 | BR-003 | TC-貸款-006 |
| AC-003 | BR-004 | TC-貸款-008 |
BA不需要取代QA來編寫整個測試案例，但BA必須幫助規則足夠清晰，以便QA將其轉換為測試案例，而無需猜測。
7. 檢查清單審查業務規則
交接前，檢查：
- 該規則有 ID 嗎？
- 該規則有來源嗎？
- 該規則是否已獲得業主批准？
- 該規則是否有通過/失敗範例？
- 該規則是否與其他規則衝突？
- 該規則是否有優先順序？
- 該規則是否有例外/預設情況？
- 該規則是否有訊息或原因代碼？
- 該規則是否影響資料、API、UI、報告、審核日誌？
- 該規則是否有 AC/測試案例的痕跡？
8. 常見錯誤
錯誤1：用含糊的字詞寫規則
「優先 VIP 客戶」還不夠。誰是VIP？按 SLA、佇列、折扣或核准途徑決定優先順序？
錯誤2：不詢問預設
當資料落入無人提及的條件組合時，就會出現許多錯誤。
錯誤3：無版本規則
業務規則會根據政策而變化。如果沒有版本/生效日期，團隊就很難審核系統當時為何做出這個決定。
更完整的決策表示例
用例：客戶更改諮詢時間表。
業務規則：
| 規則ID | 規則 |
|---|---|
| BR-001 | 只有擁有預約的客戶才能在線上重新安排。 |
| BR-002 | 預約必須處於已確認狀態。 |
| BR-003 | 預約開始時間必須至少與預約開始時間 4 小時。 |
| BR-004 | 確認時必須有新的插槽可用。 |
| BR-005 | 如果重新安排成功，則必須重新開放舊時段。 |
決策表：
| 條件/結果 | R1 | R2 | R3 | R4 | R5 |
|---|---|---|---|---|---|
| 使用者是所有者董事 | 是 | 尼 | 是 | 是 | 是 |
| 狀態=已確認 | 是 | - | 尼 | 是 | 是 |
| >= 剩餘 4 小時 | 是 | - | - | 尼 | 是 |
| 新老虎機可用 | 是 | - | - | - | 尼 |
| 決定 | 允許重新安排 | 拒絕 | 拒絕 | 拒絕 | 拒絕 |
| 原因代碼 | 好的 | NOT_OWNER | 無效狀態 | CUTOFF_EXPIRED | 截止日期SLOT_UNAVAILABLE |
| 用戶留言 | 重新安排成功 | 您無權更改此日期 | 預約日程無法更改 | 日程即將推出，請撥打熱線 | 該插槽剛剛被放置 |
映射到測試用例：
| 規則列 | 測試案例 |
|---|---|
| R1 | TC-RS-001 改期成功 |
| R2 | TC-RS-002 用戶更改其他人的日程安排 |
| R3 | TC-RS-003 預約已取消不可變更 |
| R4 | TC-RS-004 在 4 小時內重新安排 |
| R5 | TC-RS-005 新插槽剛預約 |
練習練習
選擇您熟悉的功能，例如安排、套用折扣代碼或批准退款。寫：
- 10條原子業務規則。
- 決策表至少有4個決策欄位。
- 3 小黃瓜驗收標準。 4.從規則到AC的追溯表。
參考來源
- IIBA BABOK 指引： https://www.iiba.org/standards-and-resources/babok/
- IEEE/ISO/IEC 29148-2018： https://standards.ieee.org/ieee/29148/6937/
- PMI 商業分析從業人員： https://www.pmi.org/shop/p-/book/business-analysis-for-practitioners-a-practice-guide/00101570601
結論
業務規則是BA將策略轉化為系統行為的地方。決策表是一個非常強大的工具，可以減少業務、開發和 QA 之間的誤解。如果規則明確，有ID，有來源，有例子，有可追溯性，團隊在衝刺過程中就會減少很多無用的爭論。