ユーザーストーリーがシステムに何をすべきかを伝える場合、ビジネスルールはシステムに決定方法を伝えます。
機能は画面上ではシンプルに見えますが、その背後には多くのルールが隠されています。つまり、誰が承認されるか、制限はいくらか、どのケースがブロックされるか、いつエスカレーションされるか、どのデータが必要か、2 つのルールが競合する場合にどのポリシーが優先されるかなどです。
BA が不明瞭なルールを作成した場合、Dev は推測する必要があることがよくあります。別の方法での QA テスト。ビジネスは「それは私が言いたかったことではありません」と言った。これは非常に高価な再作業のソースです。
1. ビジネスルールとは何ですか?
ビジネス ルールは、ビジネスの運営方法を決定する制約、ポリシー、または条件です。
たとえば:
- 18 歳未満のお客様は投資口座を開設することができません。
- 5 億を超える融資申請には部門長レベルの承認が必要です。
- 割引コードは、お一人様につき 1 回のみ適用されます。
- ユーザーは予約時間の少なくとも 2 時間前にのみ予約をキャンセルできます。 ・必要書類が不足している書類は「追加必要」ステータスに変更してください。
適切なルールは、開発者が実装し、QA がテスト ケースを作成できるほど明確でなければなりません。ルールがビジネスにとって合理的であるように聞こえるだけで、テストできない場合、それはソフトウェア BA にとって十分ではありません。
2. 適切な質問をするためのルールを分類する
BA は、詳細を記述する前にルールをグループ化する必要があります。
| ルールグループ | 質問 |
|---|---|
| 資格 | 誰が適格ですか?資格がない人は誰ですか? |
| 計算 | 計算式は何ですか？丸めるにはどうすればいいですか？ |
| 検証 | どのフィールドが必須ですか?形式/範囲/固有のものは何ですか? |
| 認可 | 表示、作成、編集、承認、削除できるのは誰ですか? |
| 状態遷移 | どの状態がどの状態に転送されるのか? |
| SLA / タイミング | 締め切り時間、待ち時間、締め切り時間とは何ですか? |
| 例外 | データが欠落している、正しくない、重複している、または期限切れになっている場合はどうすればよいですか? |
| コンプライアンス | 法律、政策、監査、または契約に基づくルールはどれですか? |
分類は、BA がランダムな質問をするのを防ぐのに役立ちます。ルールのグループごとに、どの関係者が確認する必要があるか、どのアーティファクトを更新する必要があるかがわかります。
3. アトミックルールの書き方
アトミック ルールは、1 つの条件または決定のみを記述するルールです。 1 つの長い文に多くのアイデアを組み合わせないでください。
悪い例:
顧客は安定した収入があり、信用度が高く、不良債権がなく、完全な記録を持っている場合に融資を受ける資格があります。
書き換えます:
| ID | ルール |
|---|---|
| BR-001 | 顧客は過去 3 か月の平均収入が 15,000,000 VND 以上である必要があります。 |
| BR-002 | 内部信用スコアは 650 以上である必要があります。 |
| BR-003 | 顧客は、過去 24 か月以内に債務グループ 3、4、または 5 を持っていてはなりません。 |
| BR-004 | 申請書には完全な CCCD、損益計算書、ローン申請書が必要です。 |
各ルールには次のものが必要です。
- 安定したID
- ソース関係者またはソース文書
- バージョンまたは発効日
- 所有者が承認する
- 合否例
- テストの影響
4. デシジョンテーブルをいつ使用するか?
決定が多くの条件に依存する場合は、デシジョン テーブルを使用します。
ローン申請承認機能の例:
| 条件・結果 | ルール 1 | ルール 2 | ルール 3 | ルール 4 |
|---|---|---|---|---|
| 収入 >= 1,500万 | や | や | や | N |
| クレジット スコア >= 650 | や | や | N | - |
| 不良債権はない | や | N | - | - |
| 必要書類が完了しました | や | や | や | や |
| 決定 | 自動承認 | マニュアルレビュー | 拒否 | 拒否 |
| 理由コード | AP-001 | RV-002 | RJ-003 | RJ-004 |
デシジョンテーブルは、チームが条件の組み合わせを確認するのに役立ちます。また、QA がテスト ケースをより迅速に作成するのにも役立ちます。各列はほぼテスト シナリオのグループです。
5. 保守しやすいデシジョンテーブルの書き方
優れたデシジョンテーブルには以下が必要です。
- 明示的な条件はい/いいえ、範囲または列挙型。
- サイン
-条件が決定に影響しない場合にのみ使用してください。 - 各列は独自の決定を示します。
- システムが理由を表示する必要がある場合は、理由コードまたはメッセージ コードがあります。
- 複数のルールが一致する場合、ルールの優先順位があります。
- リストにない組み合わせにはデフォルトのケースがあります。
ボードが大きすぎる場合は、1 つのボードに詰め込まないでください。クラスごとに分けてみましょう。
- 適格性チェック。
- リスクチェック。
- 承認ルーティング。
- 通知/メッセージ。
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 の代わりにテスト ケース全体を記述する必要はありませんが、QA が推測することなくルールをテスト ケースに変換できるように、BA はルールが十分に明確になるよう支援する必要があります。
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 |
|---|---|---|---|---|---|
| ユーザーはオーナーディレクター | や | N | や | や | や |
| ステータス = 確認済み | や | - | N | や | や |
| >= 残り 4 時間 | や | - | - | N | や |
| 新しいスロットが利用可能 | や | - | - | - | N |
| 決定 | 再スケジュールを許可する | 拒否 | 拒否 | 拒否 | 拒否 |
| 理由コード | OK | 所有者ではありません | 無効なステータス | カットオフ_期限切れ | スロット_使用不可 |
| ユーザーメッセージ | 正常に再スケジュールされました | この日付を変更する権利はありません | 予約スケジュールは変更できません | 近日中にスケジュールが決まりますので、ホットラインにお電話ください | このスロットは配置されたばかりです |
テストケースへのマッピング:
| ルールの列 | テストケース |
|---|---|
| R1 | TC-RS-001 は正常に再スケジュールされました |
| R2 | TC-RS-002 ユーザーが他の人のスケジュールを変更する |
| R3 | TC-RS-003 キャンセルされた予約は変更できません |
| R4 | TC-RS-004 4 時間以内にスケジュールを変更 |
| R5 | TC-RS-005 の新しいスロットが予約されました |
練習問題を練習する
スケジュール設定、割引コードの適用、返金の承認など、使い慣れた機能を選択してください。書きます:
- 10 のアトミック ビジネス ルール。
- デシジョンテーブルには少なくとも 4 つのデシジョン列があります。 3.3 ガーキンの許容基準。
- ルールから 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 があり、ソースがあり、例があり、トレーサビリティがある場合、チームはスプリント中の多くの無駄な議論を減らすことができます。