業務受入条件 作成ルール
Business Acceptance Criteria (BAC) Documentation Rules
本ドキュメントは、業務分析・要求定義のために 業務受入条件を統一形式で記述する標準ルールです。 BAC は「業務側から見て、このシステムで業務が回せる」ことを確認するための受入条件を定義します。
1. 全体方針
- 対象は「業務として受け入れ可能であること」を示す条件であり、業務用語で、期待結果が検証可能な形に書きます。
- 実装詳細（例: 物理テーブル名、SQL、実装クラス/関数名、APIの内部処理）は記載しません。
- クリック手順の逐語列挙など、UIの操作手順に寄りすぎた記述は避け、業務行為として要約します。
- 1ファイル = 1 受入対象（業務の塊）を基本とします。肥大化する場合は受入対象を分割します。
2. 用語定義
| 用語 | 定義 |
|---|---|
| BAC | 業務受入条件。業務側の観点での受け入れ基準（期待結果） |
| 受入対象 | 業務として実現したい能力（例: 商品販売） |
| シナリオ | 具体的な業務シナリオ（例: 顧客が商品を購入する） |
| 前提 | シナリオ開始前の条件（前提状態、準備） |
| 操作 | 業務の実行（業務イベントや操作の要約） |
| 期待結果 | 観測可能な事実（状態変化、記録、通知など） |
3. ファイル命名・ID規則
- ファイル名:
bac-<番号>-<短い日本語名>.md（例:bac-0010-商品販売.md） - Frontmatter:
id:bac-sale-checkoutのように小文字ハイフン形式。title: 「業務受入条件: 商品販売」など。
4. 推奨 Frontmatter 項目
Frontmatter は docs/handbook/shared/schemas/spec-frontmatter.schema.yaml の制約に従います。
| 項目 | 説明 | 必須 |
|---|---|---|
| id | 受入条件ID（bac-...） | ○ |
| type | test 固定 | ○ |
| title | 受入条件名（例: 業務受入条件: 商品販売） | ○ |
| status | draft/ready/deprecated | ○ |
| part_of | 上位BAC ID（分割している場合） | 任意 |
| based_on | 根拠となる仕様ID（BPS/BR/UIS/BES/BEL 等） | 任意 |
| supersedes | 置き換え関係（古仕様→新仕様） | 任意 |
推奨:
based_onに、受入対象の仕様IDを列挙します（例:bps-...,br-...,uis-...,bes-...）。- BR や BPS 側の
testsから BAC を参照できるよう、ID は安定させます（名前を変える場合はsupersedesを使う）。
5. 本文構成（標準テンプレ）
各 BAC ファイルは以下の見出しを順番に並べます。
- 概要
- 受入条件
- メモ / 将来課題
6. 記述ガイド詳細
6.1 概要
- 1〜3文で「何を受け入れるか」を書きます。
- 可能であれば、対象の業務イベント（BEV）や業務プロセス（BPS）を言及し、
based_onと整合させます。
任意（レビューが速くなる場合のみ）:
- 「誰が」「何のために」を 1 行で明記してよいです。
- 例: 「役割: 発注担当者 / 目的: 在庫補充のために発注〜入荷〜支払を追跡できる」
6.2 受入条件
Markdown で「受入対象」と「シナリオ」を記述します。
基本:
- 1ファイル = 1 受入対象（大きい場合はファイル分割）。
- シナリオは 2〜8 個程度を目安に、業務の代表パターンを押さえます。
- 期待結果は 観測可能な事実 として書きます（例: 「在庫が減少する」「売上が記録される」「納品が記録される」など）。
シナリオの標準テンプレ（推奨）:
### シナリオ: <短い名称>#### 前提（箇条書き）#### 操作（箇条書き。クリック手順の逐語列挙ではなく、業務行為として要約）#### 期待結果（箇条書き。状態変化/記録/通知などの観測点）#### 判定方法（任意。どこを見て合否判定するか）
記述のコツ:
- 「前提」はシナリオ開始時点で成立している状態を業務用語で書く。
- 「操作」は業務イベントや業務行為に寄せ、UI は必要最低限の要約に留める。
- 「期待結果」は検証不能な曖昧表現（「正しく処理される」等）を避け、観測できる事実に分解する。
6.2.1 ケース表
同じ業務行為を 入力値や条件だけ変えて反復する場合は、シナリオを増やす代わりに ケース表で差分をまとめてよいです。
- 使いどころ: 金額計算・税区分・支払方法・数量パターンなど、差分が「値」中心で説明できる場合
- 避けるべき: 例外時の扱いがケースごとに大きく異なり、期待結果の観測点が増える場合（この場合はシナリオ分割の方がレビューしやすい）
書き方（最小）:
### シナリオ: <共通の業務行為>を 1 つ置く- その下に
#### ケース一覧（表）を置き、ケースごとの違いを表にまとめる
ケース表の例（列は必要に応じて調整）:
| ケース | 条件/入力 | 操作 | 期待結果（観測点） |
|---|---|---|---|
| C1 | … | … | … |
※ ケース表を使う場合でも、「期待結果（観測点）」は検証可能な事実として具体化してください。
6.3 メモ / 将来課題
- 未確定の運用（例: 締め処理、例外時の扱い）や、将来追加したい Scenario を記録します。
7. 禁止事項
| 項目 | 理由 |
|---|---|
| 物理テーブル名・物理カラム名・SQL全文 | 概念レベル逸脱 |
| 実装クラス/関数名、APIの内部実装詳細 | 実装依存で変更に弱い |
| クリック/画面遷移の逐語列挙 | UI変更に弱い・本質が埋もれる |
| 期待結果が曖昧（「正しく処理される」等） | 検証不能 |
8. よくある誤りと対策
- シナリオが UI 手順書になっている → 「操作」を業務行為に要約し、「期待結果」を観測可能な事実に寄せる。
- 期待結果が 10 個以上に肥大 → シナリオを分割するか、期待結果を整理（“必須の観測点”に絞る）。
- 例外系が抜けている → 代表的な異常（在庫不足、入力不備、締め済み等）をシナリオで追加する。
9. サンプル（簡易）
---
id: bac-sale-checkout
type: test
title: 業務受入条件: 商品販売
status: draft
part_of: []
based_on:
- bps-sale-checkout
- bes-sale-checkout
- br-sale-total-calc
supersedes: []
---
## 概要
レジ会計時に、商品販売（会計確定）が業務として成立し、売上と在庫が正しく記録されること。
## 受入条件
### シナリオ: 顧客が商品を購入する
#### 前提
- 顧客がレジに商品を持参している
- 商品の在庫が十分にある
#### 操作
- レジ担当者が会計を確定する
#### 期待結果
- 売上が記録される
- 商品の在庫が減少する
## メモ / 将来課題
- 将来: 返品・取消の受入条件を追加する。9.2 サンプル（複合・長め）
「複合シナリオ」の例です（発注→入荷→請求→支払までの一連を、同一の受入対象として確認）。
ここでは、レビューしやすさのために 同一受入対象に対する代表パターン（正常系）と例外（差異） を、別シナリオとして並べています。
---
id: bac-procurement-order-to-payment
type: test
title: 業務受入条件: 仕入（発注〜入荷〜支払）
status: draft
part_of: []
based_on:
- bps-procurement-order
- bps-procurement-receive
- bps-accounting-payment
- bes-purchase-order-confirmed
- bes-goods-receipt-confirmed
- bes-invoice-received
- bes-payment-confirmed
supersedes: []
---
## 概要
在庫補充のための仕入で、発注・入荷・支払までの一連が業務として成立し、在庫・仕入・支払の記録が矛盾なく追跡できること。
## 受入条件
この受入対象では、少なくとも次を確認します。
- 正常系: 発注→入荷→請求→支払までが完了し、相互に追跡できる
- 例外: 入荷で数量差異が発生した場合でも、差異と未完了（未入荷残）が追跡できる
### シナリオ: 発注から入荷・請求・支払までが完了する（数量一致）
#### 前提
- 商品Aの在庫が発注点以下である
- 仕入先Sが取引可能（取引停止ではない）である
- 仕入先Sの支払条件が登録されている
#### 操作
- 発注担当者が商品Aを数量10で発注確定する
- 仕入先Sから商品Aが数量10で納品され、入荷検品を確定する
- 経理担当者が仕入先Sの請求書（発注分）を受領する
- 経理担当者が支払を確定する
#### 期待結果
- 発注が記録される
- 発注には発注番号、仕入先、発注明細（商品、数量、単価）が保持される
- 入荷が記録される
- 入荷には入荷日、仕入先、入荷明細（商品、数量）が保持される
- 在庫が数量10増加する
- 請求が記録される
- 請求には請求番号、仕入先、対象期間、請求金額が保持される
- 支払が記録される
- 支払には支払日、仕入先、支払金額、支払方法が保持される
- 発注・入荷・請求・支払が相互に追跡できる（参照関係を辿れる）
### シナリオ: 入荷検品で数量差異があり、差異と未入荷残が追跡できる（不足）
#### 前提
- 仕入先Sが取引可能（取引停止ではない）である
- 仕入先Sの支払条件が登録されている
- 発注担当者が商品Aを数量10で発注確定している（同一の発注番号を持つ）
- 仕入先Sから商品Aが数量9で納品される（発注数量に対して不足がある）
#### 操作
- 入荷検品を確定する
#### 期待結果
- 入荷が記録される
- 入荷数量は数量9として記録される
- 発注に対する差異（不足1）が記録される
- 不足1は、同一の発注に紐づく未完了（未入荷残）として追跡できる
- 在庫が数量9増加する
## メモ / 将来課題
- 将来: 不足分の追加入荷（分納）で未入荷残が解消される Scenario を追加する。
- 将来: 請求書が「発注数量基準」か「入荷実績基準」かの違いを扱う Scenario を追加する。
- 将来: 値引・返品・訂正（請求訂正、支払取消）を扱う Scenario を追加する。9.3 サンプル（役割/目的 + ケース表）
「役割/目的」の明記と、「ケース表」で差分をまとめる例です。
---
id: bac-sale-payment-method
type: test
title: 業務受入条件: 会計確定（支払方法の記録）
status: draft
part_of: []
based_on:
- bps-sale-checkout
- br-sale-total-calc
supersedes: []
---
## 概要
レジ会計の確定時に、支払方法の違いにかかわらず、売上が記録され、支払方法が追跡できること。
役割: レジ担当者 / 目的: 会計確定の結果として、売上と支払方法を記録し追跡できる
## 受入条件
### シナリオ: 会計確定が支払方法別に成立する
#### 前提
- 顧客がレジに商品を持参している
- 商品の在庫が十分にある
#### 操作
- 会計を確定する（支払方法を選択して確定する）
#### ケース一覧
| ケース | 条件/入力（支払方法） | 期待結果（観測点） |
| ------ | --------------------- | ------------------------------------------------------- |
| C1 | 現金 | 売上が記録され、支払方法=現金として追跡できる |
| C2 | キャッシュレス | 売上が記録され、支払方法=キャッシュレスとして追跡できる |
#### 判定方法（任意）
- 売上記録（レジ記録）で、売上の作成と支払方法の記録が確認できる
## メモ / 将来課題
- 将来: 支払方法別の明細（例: 釣銭、手数料、入金/未入金の扱い）を追加する。10. 生成 AI への指示テンプレート
生成 AI に業務受入条件（BAC）を作らせるときは、以下のような指示を与えます。
以下のルールに従って、業務受入条件（BAC） を 1 ファイル作成してください。出力は Markdown とします。
対象は 1 つの受入対象（1ファイル=1受入対象）です。受入条件は Markdown 形式で記述してください。
禁止: 物理テーブル名・物理カラム名・SQL全文、実装クラス/関数名、API内部実装詳細、クリック手順など UI 操作の逐語列挙
先頭に YAML Frontmatter を付与し、以下の形式で記述してください（
id/type/title/statusは必須）：yaml--- id: bac-<英小文字とハイフンで構成したID> type: test title: 業務受入条件: <受入対象名> status: draft # draft / ready / deprecated part_of: [] based_on: [] supersedes: [] ---本文は次の見出し（日本語）をこの順序で必ず含めてください：
- 概要
- 受入条件
- メモ / 将来課題
受入条件にはシナリオを 2〜6 個程度作成してください。
各シナリオは、少なくとも次の小見出しを含めてください：
前提 / 操作 / 期待結果
小見出しのレベルは
####を推奨します（例:#### 前提）。任意: 同じ業務行為を条件/入力だけ変えて繰り返す場合は、「#### ケース一覧（表）」を追加して差分を表でまとめてよいです。
「期待結果」は「観測可能な事実」（状態変化/記録/通知など）として具体的に書き、検証可能にしてください。
全体を 業務用語で統一 し、略語を使う場合は、業務用語集に存在する一般的な略語のみとし、意味が推測しづらい略語や内部コードは使用しないでください。
補足:
titleの<受入対象名>は、ここでは「受入対象名」を指します。