D1: ドメイン要求仕様書

inputする成果物

成果物のパス	内容
docs/D1.business-requirements/product-requirement-document.md	親文書のPRD(継承する横断要求の正典)
docs/D1.business-requirements/domain-definition-document.md	ドメイン定義書(対象ドメインの定義・ドメイン間連携の正典)
docs/D1.business-requirements/actor-list.md	アクター一覧(業務主体の参照元)
docs/D1.business-requirements/business-requirement-document.md	BRD(スコープ・KPI・法令制約 等の根拠)
docs/D1.business-requirements/domain-requirements/<domain正式名>-requirement-document.md	既存ドメイン要求仕様書(更新・レビュー時のみ参照。新規作成時は未存在)

outputする成果物

成果物のパス

内容

docs/D1.business-requirements/domain-requirements/<domain正式名>-requirement-document.md

ドメイン要求仕様書本体(1ドメイン=1ファイル)。ファイル名はドメインコードを省略せず正式英語名とする: HEAR=hearing / DESIGN=design / APPL=application / DECL=declaration / UNDW=underwriting / PREM=premium / BOOK=booking / PLCY=policy / PROD=product-specification(PRDの product-requirement-document との混同回避)/ CUST=customer / CHNL=channel / SUIT=suitability / KYC=know-your-customer / ASF=anti-social-forces / ESIGN=electronic-signature / AUDIT=audit。例: know-your-customer-requirement-document.md

使用するテンプレート

出力時は以下のテンプレートを読み込み、その章構成・書き方ヒントに従う。

テンプレートのパス	内容
.claude/skills/d1-domain-requirement-document/template.md	ドメイン要求仕様書テンプレート(章構成・書き方ヒント)

章構成

本書は専用の「対象ドメイン」「継承するドメイン共通要求」「他ドメインとの連携」「想定読者」章を 持たない。ドメイン定義は正典であるドメイン定義書を参照する。本書とドメイン共通要求仕様書は並列の関係(参照関係を持たない)であり、横断的な水準・方針・原則は共通要求側に責務があるため、本書ではそれらを再記述しない。他ドメイン連携は各業務ルールの「根拠/制約」列および「受け入れ基準」にインラインで紐づける。固定章構成は以下:

# {{ドメイン名}}要求仕様書
## 本書について
### 概要        … 定型2文(ドメイン名のみ置換)
### 注記        … 定型1文
## 業務要求
### 業務ルール
### 業務状態遷移
### 業務運用(イレギュラー対応)
## セキュリティ要求
### データアクセス要求
## 受け入れ基準

新規作成時の振る舞い

新規作成時は ユーザーへのヒアリングを行わず、PRD・ドメイン定義書・アクター一覧・BRD と業界一般知識から各ドメイン要求仕様書を直接生成する。1ドメインずつ、テンプレートの章順に従って書き出す。

1. 本書について: テンプレートの定型文をそのまま用い、{{ドメイン名}} をドメイン定義書「一覧」の名と一致させて置換する。概要・注記以外の前文は設けない
2. 業務ルール: BRD のスコープ・法令制約、ドメイン定義書の「主な関心事」「ドメイン間の主な連携」、業界一般知識から、本ドメイン固有の判断基準・制約・条件を導く。ドメイン共通要求と並列の関係にあるため、共通要求と内容が重なる業務ルール(横断的な水準・方針・原則の言い換え)は本書に書かない。各業務ルールの「根拠/制約」列には法令・ドメイン定義書の関心事・他ドメインとの連携・業界基準 等を記載し、ドメイン共通要求の ID(DOM-COMMON-*)は記載しない(参照関係を持たないため)。本ドメインの責務境界(他ドメイン・既存システムとの分担)が明確な場合は、その範囲を業務ルールとして1項立てる(例: 計上完了までを担い継続収納は既存収納システムに引き渡す、本ドメインは証跡の収集・保全に責務を限定し業務判断ロジックは工程ドメインに委ねる 等)
3. 業務状態遷移: 本ドメインが管理する主要業務対象の業務状態と遷移(状態定義表+遷移表)を示す。導入文では主要業務対象を「」付きで明示する(例: 「主要な業務対象である『申込』の業務状態と遷移を示します」)。独立した複数の業務対象を持つドメインは Mermaid の composite state(state "名前" as エイリアス { ... })で1つの図に並置する。遷移ラベルに (XXX-BR-N) 形式の業務ルールIDを括弧書きで添えると図と表のトレーサビリティが上がる
4. 業務運用(イレギュラー対応): 正常系から外れる業務局面と業務上の取り扱いを示す。「業務上の対応」列の末尾に (XXX-BR-N に整合) 形式で 本ドメイン内の関連 BR ID のみ を併記する(DOM-COMMON-* は参照関係を持たないため記載しない)
5. セキュリティ要求 > データアクセス要求: ドメイン共通要求の機密区分の 語彙(「個人情報」「要配慮個人情報」「業務上機密」 等) を引いて、本ドメイン固有の主要データを分類する。ID 参照(DOM-COMMON-SEC-DATA-* の記載)はしない(並列モデルのため)。構造詳細は D2 に降ろす
6. 受け入れ基準: 業務ルールの網羅・主要業務状態遷移の通し確認 等を 3〜7 項目で示す。ドメイン共通要求の ID(DOM-COMMON-*)は併記しない(並列モデルのため)。本書独自の受け入れ観点を、本ドメイン内の BR/IRR/DATA ID で必要に応じて参照しつつ書く
7. 上流から確定できない値には要確認マーカーを付ける。将来段階導入の要求には [フェーズ2] ラベルを付ける
8. ID は <ドメインコード>-<カテゴリ>-<連番> 形式(成果物略号=当該ドメインコード)。カテゴリは 業務ルール=BR / 業務運用(イレギュラー)=IRR / ドメイン固有データ=DATA。例: DOM-HEAR-BR-1, DOM-HEAR-IRR-1, DOM-HEAR-DATA-1。CLAUDE.md §8 に準拠

留意事項

• 並列モデル(本書と共通要求は参照関係を持たない): 横断的な水準・方針・原則は ドメイン共通要求仕様書 が単独責務を持つ。本書はそれを「継承」「参照」せず、当該ドメイン固有の業務ルールのみを書く。「根拠/制約」列・IRR の整合先・受け入れ基準のいずれにも DOM-COMMON-* ID は記載しない。本書と共通要求は同じ要求実体を語らない=厳密な MECE を維持する
• 共通要求の言い換えになっていないか自問する判定指針: ある BR を本書に書くべきか判定する際、「当該ドメイン業務の文脈で意味が成立する固有の業務ルールか、それともドメイン共通要求(横断的水準・方針・原則)の言い換えか」を問う。
  • 共通要求の言い換え(横断的な水準・方針・原則を別言葉で書いている / 「データ種別が違うだけ」「対象帳票が違うだけ」の差分しかない)→ 本書に書かない。共通要求側に責務を委ねる(共通要求側で十分な粒度・具体性で書かれているなら、個別側で補足する必要はない)
  • 当該ドメイン固有の業務ルール(共通要求にはない、当該ドメイン業務の文脈・判断基準・対象範囲・例外条件・運用サイクルが本質)→ 本書に BR として書く。共通要求と内容が重ならないよう、業務ルールの主題を「当該ドメイン固有のスコープ・粒度・対象集合・運用」に絞る
• 言い換えになりやすい領域(注意領域): 以下の領域は個別ドメイン側で共通要求の言い換えになりがち。本書で BR を立てる前に、共通要求側で既に書かれていないかを確認すること:
  • 改ざん不能性・証跡保持期間 — AUDIT/SUIT/PLCY/ESIGN 等で頻発
  • 電子帳簿保存法対応(真実性・可視性) — PLCY/AUDIT/ESIGN/SUIT 等で頻発
  • 同意管理(取得・撤回・更新) — CUST/HEAR/DECL 等で頻発
  • RBAC・最小権限 — AUDIT/権限を扱う全ドメインで頻発
  • 反社チェック義務 — ASF と他ドメインの境界で発生 これらに該当する BR を立てるときは、上記「判定指針」に従って、共通要求の言い換えになっていないか必ず自問する
• 統制責務ドメイン(AUDIT/CUST/SUIT 等)の規律: 性格上、共通要求と同領域を扱うドメインでは、「当該ドメイン固有の運用ルール」と「共通要求の言い換え」の境界に特に注意する。「監査ログを 10 年保持」「改ざん不能に保つ」のような共通要求と同文の BR は不要(共通要求側に委ねる)。「監査対象イベントの一覧を当該ドメイン固有の業務イベント粒度で定義する」「証跡の網羅性を当該業務工程の通し確認で担保する」「権限申請・承認の業務手続きを運用する」のように、当該ドメイン固有のスコープ・粒度・対象集合・運用サイクルを主題とする BR のみ立てる
• ドメイン定義書の定義を改変しない: 対象ドメインの ID・名・区分・種別・概要・主な関心事 はドメイン定義書が正典。専用の「対象ドメイン」章は持たないが、業務ルール・データ要求の根拠はドメイン定義書の関心事・連携と矛盾させない(齟齬を見つけたらドメイン定義書側の修正を促す)
• ドメインの What に留まる: 「本ドメインとして何を満たすべきか」を業務言語で書く。機能名・画面名・テーブル名・API 名等の How(D2 以降)は混入させない。ただしビジネス・規制上譲れない本ドメイン固有の具体水準は本書で確定する
• システム寄り用語に「業務」を冠する: 状態遷移→業務状態遷移、例外処理→業務運用(イレギュラー対応) のように、D1 成果物ではシステム実装を想起させる語に「業務」を明示し、業務観点であることを保つ
• 業務ルールが中核: 本書の価値は当該ドメイン固有の業務ルール・判断基準・条件分岐の網羅にある。各ルールに根拠(法令 / PRD §ID / ドメイン定義書の関心事・連携)を必ず紐づける。専用の継承章・他ドメイン連携章を持たない分、トレーサビリティはこの根拠列が担う
• 責務境界を業務ルール化する: 後続ドメイン・既存システムとの分担が明確なドメインでは、「本ドメインの責務はXXXまでとし、以降は……の責務とする」を業務ルールとして1項立てる。これにより下流の機能一覧・C4・シーケンス図で責務漏れ/重複を起こさない
• 連携はドメイン定義書を起点: 専用の「他ドメインとの連携」章は持たないが、業務ルール・状態遷移の根拠/契機はドメイン定義書の「ドメイン間の主な連携」と矛盾させない。詳細シーケンスは下流の L1/L2 シーケンス図に降ろす
• フェーズ2 ラベル: 初期フェーズ対象外の業務ルール・データは [フェーズ2] ラベルで境界を明示し、PRD・BRD の同種ラベルと表記を揃える
• 1ドメイン=1ファイル: ドメイン定義書の全ドメインに対し原則1ファイル。PRD「ドメイン構成と要求仕様書群への分割方針」での統合/分割判断に従う

完成時のセルフチェック

執筆完了時に以下の観点で出力を検査し、不備があれば修正したうえで出力を完了とする。

• 固定章構成(本書について[概要/注記]→業務要求[業務ルール/業務状態遷移/業務運用]→セキュリティ要求[データアクセス要求]→受け入れ基準)に一致しているか。廃止章(対象ドメイン/継承するドメイン共通要求/他ドメインとの連携/想定読者)を復活させていないか
• 本書の表・受け入れ基準・IRR 整合先に DOM-COMMON-* ID が記載されていないか(並列モデルのため参照関係を持たない。語彙(機密区分名等)の引用は OK、ID 記載は NG)
• 各 BR について「共通要求(横断的水準・方針・原則)の言い換えではなく、当該ドメイン固有の業務ルールか」を自問したか。言い換え BR を残していないか
• 言い換えになりやすい領域(改ざん不能性 / 電子帳簿保存法 / 同意管理 / RBAC / 反社)に該当する BR を立てた場合、共通要求の言い換えではなく当該ドメイン固有のスコープ・粒度・対象集合・運用を主題としているか
• 統制責務ドメイン(AUDIT/CUST/SUIT 等)で、「改ざん不能に保つ」「N 年保持」等の共通要求と同文の BR を作っていないか
• 業務ルール・データ要求の根拠(法令・ドメイン定義書の関心事・連携・業界基準 等)が記載されており、ドメイン定義書と矛盾していないか
• 本ドメイン固有の業務ルール・業務状態遷移・業務運用(イレギュラー対応)が網羅され、各業務ルールに根拠が紐づいているか
• 他ドメイン・既存システムとの責務境界が明確なドメインで、その境界が業務ルールとして明示されているか
• 業務状態遷移の導入文で主要業務対象が「」付きで明示されているか(汎用文「主要な業務対象の業務状態と遷移を示します」のままになっていないか)
• 複数の独立業務対象を持つドメインで composite state による並置表現が検討されているか
• 業務運用(イレギュラー対応)の「業務上の対応」列に、関連する 本ドメイン内の BR/IRR ID が (XXX-BR-N に整合) 形式で紐づけられているか(DOM-COMMON-* 参照は記載しない)
• 状態遷移・例外処理 等のシステム寄り用語に「業務」が冠されているか
• データアクセス要求が ドメイン共通要求の機密区分の 語彙(「個人情報」「要配慮個人情報」「業務上機密」 等)を引いており、ID 参照(DOM-COMMON-SEC-DATA-*)を記載していないか
• 受け入れ基準が本ドメイン内の業務ルール・業務状態遷移の網羅を観点とし、DOM-COMMON-* ID 参照や「継承 PRD 要求の充足」表現を含んでいないか
• 機能名・画面名・テーブル名・API 名等の How(D2以降)が混入していないか
• 各表に ID(<ドメインコード>-<カテゴリ>-<連番> 形式)が付与され、後続成果物から参照可能になっているか
• 将来要件に [フェーズ2] ラベルが付与されているか
• {{ や XXX のプレースホルダ、不要な要確認マーカーが残っていないか

下流への伝搬関係

作成・更新時は以下の下流成果物との整合を意識する:

下流成果物	ドメイン要求仕様書から何を引く
ユーザーストーリー一覧	当該ドメインの業務ルール・業務運用(誰が何のために)
ユースケース一覧	業務状態遷移・業務運用(イレギュラー対応)から具体シナリオ
機能一覧(D2)	業務ルールから導出される機能(横断機能は別途ドメイン共通要求から導出される)
画面要件群(D2)	業務状態遷移・業務運用 + 機能一覧
L1/L2 シーケンス図	業務状態遷移・業務ルールの根拠/契機が指すドメイン定義書の連携