システム受入条件仕様（SAC）作成ルール

本ドキュメントは、品質保証・運用設計・テスト設計のために システム受入条件（System Acceptance Criteria: SAC）を統一形式で記述する標準ルールです。 SAC は「システム全体としての合格基準（機能・非機能・障害・移行など）」を、Markdown 形式で検証可能な形に落とし、受入判断の根拠を明確にします。

1. 全体方針

• SAC は システム全体としての出口条件（合格基準） です。
  • 例: 「性能試験で全ての NFR を満たし、重大障害 0 件であること」
• 受入条件は 観測・計測できる事実として書きます。
  • 「正しく動作する」「問題ない」などの曖昧表現は禁止。
• 手順書を作るのが目的ではありません。
  • クリック手順や画面遷移の逐語列挙は避け、システムに与える入力/操作と期待結果を要約します。
• 実装詳細（例: 物理テーブル名、SQL全文、実装クラス/関数名、特定ライブラリの設定値）は記載しません。
• 1ファイル = 1 受入対象（合格基準のまとまり）を基本とします。
  • 例: 性能（主要API/画面）, 障害復旧, セキュリティ（権限/監査）, 移行（初期データ） など

2. 用語定義

用語	定義
SAC	システム受入条件。システム全体としての合格基準（出口条件）
受入対象	受入として保証したい範囲や品質（例: 性能、障害復旧、移行）
シナリオ	受入条件の具体ケース
前提	シナリオ開始前の条件（前提状態、試験環境、負荷条件など）
操作	システムに与える入力/操作/イベントの要約
期待結果	観測可能な事実（状態変化、記録、通知、計測値など）

3. ファイル命名・ID規則

• ファイル名: sac-<番号>-<短い日本語名>.md （例: sac-0010-性能.md）
• Frontmatter:
  • id: sac-performance, sac-disaster-recovery のように小文字ハイフン形式。
  • title: 「システム受入条件: 性能」など。

推奨:

• 受入対象が肥大化する場合は、カテゴリやサブシステム単位で分割し、下位文書側で part_of に上位SACを指定します。
• based_on には、根拠となる仕様 ID（例: nfr-..., bac-..., br-..., bps-...）を列挙します。

4. 推奨 Frontmatter 項目

Frontmatter は docs/handbook/shared/schemas/spec-frontmatter.schema.yaml の制約に従います。

項目	説明	必須
id	受入条件ID（sac-...）	○
type	test 固定	○
title	受入条件名（例: システム受入条件: 性能）	○
status	draft/ready/deprecated	○
part_of	上位SAC ID（分割している場合）	任意
based_on	根拠となる仕様ID（NFR/BAC/BR/BPS/ADR/TSL 等）	任意
supersedes	置き換え関係（古仕様→新仕様）	任意

推奨:

• based_on に、受入条件の根拠となる NFR/BAC を必ず紐づけます。
• SAC が下位のテスト設計（テスト条件一覧、システムテスト仕様など）へ分解される場合、tests から参照できるよう ID は安定させます。

5. 本文構成（標準テンプレ）

各 SAC ファイルは以下の見出しを順番に並べます。

1. 概要
2. 受入条件
3. メモ / 将来課題

6. 記述ガイド詳細

6.1 概要

• 1〜3文で「何を合格とするか（出口条件）」を書きます。
• 可能なら対象仕様（NFR/BAC/主要機能）を言及し、based_on と整合させます。

6.2 受入条件

SAC は Markdown で「受入対象」と「シナリオ」を記述します。

基本:

• 1ファイル = 1 受入対象（大きい場合はファイル分割）。
• シナリオは 2〜8 個程度を目安に、合否判定が必要な代表パターンを押さえます。
• 期待結果は 観測・計測できる事実 として書きます（可能な限り数値・単位を含める）。

シナリオの標準テンプレ（推奨）:

• ### シナリオ: <短い条件名>
  • #### 前提（箇条書き）
  • #### 操作（箇条書き。クリック手順の逐語列挙ではなく、入力/操作/イベントとして要約）
  • #### 期待結果（箇条書き。観測点/計測値/閾値を含める）
  • #### 判定方法（任意。どこを見て合否判定するか）

記述のコツ:

• 非機能は「指標＋基準（閾値）」まで書きます。
  • 例: 応答時間（P95）/ 稼働率 / エラー率 / RTO / RPO / 監査ログの保持期間 など
• “環境や負荷条件”が重要な場合は、「前提」に条件を明記します。
  • 例: 「ピーク時相当の負荷（100 RPS）を与えている」
• 1つのシナリオに要求を詰め込みすぎない（レビュー・切り分けが難しくなる）。

6.2.1 ケース表

同じ操作を 条件/入力だけ変えて反復する場合は、シナリオを増やす代わりに ケース表で差分をまとめてよいです。

書き方（最小）:

• ### シナリオ: <共通の操作/イベント> を 1 つ置く
• その下に #### ケース一覧（表）を置き、ケースごとの違いを表にまとめる

ケース表の例（列は必要に応じて調整）:

ケース	前提（条件/負荷/データ量）	操作	期待結果（観測点/基準）
C1	…	…	…

6.3 メモ / 将来課題

• 未確定の前提（例: ピーク時の定義、想定データ量、外部依存のSLA）
• 将来追加したい SAC（例: DR訓練頻度、監査ログの検索性）

7. 禁止事項

項目	理由
物理テーブル名・物理カラム名・SQL全文	概念レベル逸脱、変更に弱い
実装クラス/関数名、特定ライブラリの設定値の列挙	実装依存で変更に弱い
クリック/画面遷移の逐語列挙	UI変更に弱い・本質が埋もれる
「正しく動く」「問題ない」等の曖昧表現	検証不能

8. よくある誤りと対策

• 期待結果が曖昧（「性能が良い」） → 指標と基準（数値/単位）に分解する
• 前提がない（平常/ピークが不明） → 前提に条件（負荷、データ量、時間帯）を書く
• 期待結果が測れない → 観測点（ログ/監視/試験レポート等）を期待結果や判定方法に含める
• 1つのシナリオに要件を詰め込みすぎ → シナリオを分割する

9. サンプル（簡易）

メタ情報

---
id: sac-performance
type: test
title: システム受入条件: 性能
status: draft
part_of: []
based_on:
  - nfr-performance
supersedes: []
---

概要

主要な画面操作と主要 API が、平常時およびピーク時において業務上許容できる時間内で完了することを合格基準として定義する。

受入条件

シナリオ: 販売登録の応答時間

前提

• 対象環境はシステムテスト環境である

操作

• おばあちゃんが販売登録画面で一般的な会計を行う

期待結果

• 会計確定から結果表示までが 3 秒以内であること

シナリオ: 在庫照会APIの応答時間（平常時）

前提

• 平常時相当の負荷（20 RPS）を与えている

操作

• 在庫照会APIを呼び出す

期待結果

• 応答時間（P95）が 500ms 以内であること

メモ / 将来課題

• ピーク時の同時接続数・データ量の確定

10. 生成 AI への指示テンプレート

生成 AI に SAC を作らせるときは、以下のような指示を与えます。

• 以下のルールに従って、システム受入条件（SAC） を 1 ファイル作成してください。出力は Markdown とします。
• 目的: システム全体としての合格基準（出口条件）を、検証可能な形で定義し、受入判断の根拠を明確にすること。
• 禁止: 物理テーブル名・物理カラム名・SQL全文、実装クラス/関数名、特定ライブラリの設定値の列挙、クリック手順など UI 操作の逐語列挙

出力フォーマット

• 先頭に YAML Frontmatter を付与し、以下の形式で記述してください（id / type / title / status は必須、type は test 固定）：

  ---
  id: sac-<英小文字とハイフンで構成したID>
  type: test
  title: システム受入条件: <対象名>
  status: draft # draft / ready / deprecated
  part_of: []
  based_on: []
  supersedes: []
  ---

• 本文は次の見出し（日本語）をこの順序で必ず含めてください：

  1. 概要
  2. 受入条件
  3. メモ / 将来課題

• 受入条件は Markdown で「シナリオ」を 2〜8 個程度作成してください。

• 各シナリオは、少なくとも次の小見出しを含めてください：

  前提 / 操作 / 期待結果

• 小見出しのレベルは #### を推奨します（例: #### 前提）。

• 期待結果は 観測・計測できる事実として書き、可能な限り数値・単位（秒、ms、%、件、日など）を含めてください。