D1: ドメイン共通要求仕様書

inputする成果物

成果物のパス	内容
docs/D1.business-requirements/business-requirement-document.md	上流のBRD(スコープ・KPI・予算/期間制約・コンプライアンス制約 等を参照)
docs/D1.business-requirements/product-requirement-document.md	上流のPRD(方針・概念・体験設計・制約・受け入れ基準 を参照)
docs/D1.business-requirements/actor-list.md	上流のアクター一覧(直接利用アクターの抜粋元・対応アクターIDの引用元)
docs/D1.business-requirements/domain-definition-document.md	上流のドメイン定義書(ドメイン構成と分割方針の起点)
docs/D1.business-requirements/domain-requirements/domain-common-requirement-document.md	既存のドメイン共通要求仕様書(更新・レビュー時のみ参照。新規作成時は未存在)

outputする成果物

成果物のパス	内容
docs/D1.business-requirements/domain-requirements/domain-common-requirement-document.md	ドメイン共通要求仕様書本体

使用するテンプレート

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

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

章構成

本書は以下の章で構成される。各節の要求は ID(DOM-COMMON-<カテゴリ>-<連番> 形式)を付与する。ドメイン要求仕様書群(個別)とは並列の関係にあり、参照関係を持たない(各ドメイン要求仕様書は本書を「継承」「参照」せず、それぞれが独立した要求集合となる)。下流のユーザーストーリー一覧・ユースケース一覧・機能一覧(D2)等からは、横断ストーリー・横断機能の起点として本書の ID が直接参照される。

• §本書について(概要 / 注記)
• §機能要求(DOM-COMMON-FR-*)
• §非機能要求(DOM-COMMON-NFR-*)
• §UI/UX 方針(DOM-COMMON-UX-*)
• §セキュリティ要求(DOM-COMMON-SEC-*)
  • §データアクセス要求(DOM-COMMON-SEC-DATA-*)
• §法務・コンプライアンス要求(DOM-COMMON-REG-*)
• §受け入れ基準(本書全体としての検収観点)

新規作成時の振る舞い

新規作成時(docs/D1.business-requirements/domain-requirements/domain-common-requirement-document.md 未存在)は ユーザーへのヒアリングを行わず、上流(PRD・BRD・アクター一覧・ドメイン定義書)と業界一般知識から本書を直接生成する。

1. PRD §「体験設計」・§「制約事項」・§「受け入れ基準」 と BRD §「事業戦略」「KPI」「セキュリティ要件」「法令・規制要件」 を読み、横断的に効く具体要求を抽出する
2. テンプレートの章順に従って書き出す。各章の主な引き取り元と注意点は以下:
   • 本書について: 概要 / 注記 の2つのサブ見出しに分割。概要は1〜2文に圧縮し、ドメイン定義書との関係と本書のスコープ(3ドメイン以上の横断要求)に絞る。「PRD は方針 / 本書は具体要求(横断・並列)レイヤー / ドメイン要求仕様書群は具体要求(個別・並列)レイヤー」の関係解説や想定読者リストは下流成果物の前提説明簡素化方針に揃えて省く
   • 機能要求: 業務通知・帳票出力・業務の中断/再開・同意取得 等、複数ドメインで共通利用する 業務機能 を集約。列見出しは「機能区分」とする。認証・認可・監査ログ等のセキュリティの仕組みは §セキュリティ要求 へ、エラー検知・リトライ・冪等性等の信頼性および外部サービス疎結合連携等のアーキ方針は §非機能要求(信頼性・互換性) へ振り分ける
   • 非機能要求: 性能(レスポンスタイム・スループット)・可用性・拡張性・運用性・保守性・互換性・信頼性 のカテゴリで整理。外部サービス・既存システムとの疎結合性・更改耐性は §非機能要求 の互換性カテゴリで扱う
   • UI/UX 方針: 対象デバイス・OS・ブラウザ / 利用シーン / アクセシビリティ / デザインシステム / 言語・通貨・地域 / エラー時の体験 等の観点で方針宣言。各観点に ID(DOM-COMMON-UX-<連番>)を付与する(下流のユーザーストーリー一覧・画面コンセプト集等から参照できるようにするため。方針宣言だからといって ID を省かない)
   • セキュリティ要求: 業界基準準拠・認証・データ保護・アクセス制御・監査ログ・脆弱性対策・インシデント対応 等を集約。配下に §データアクセス要求(エンティティ×機密区分×アクセス制御) を入れ子で配置。外部システム参照のみで本プロダクトでは保有しないエンティティ(商品マスタ・募集人マスタ 等)も §データアクセス要求 で棚卸しし、「参照」「原本は外部」の方針を明記する
   • 法務・コンプライアンス要求: 適用法令・規制を列挙し、本書での求める対応・主たる影響範囲を整理
   • 受け入れ基準: 本書記載の共通要求が満たされていることの検収観点を 3-7 項目で示す
3. ID は DOM-COMMON-<カテゴリ>-<連番> 形式。カテゴリは 機能要求=FR / 非機能要求=NFR / UI/UX 方針=UX / セキュリティ要求=SEC / 法務・コンプライアンス要求=REG。データアクセス要求はセキュリティ要求の子のため、入れ子カテゴリ SEC-DATA をハイフン連結した DOM-COMMON-SEC-DATA-<連番> とする
4. ユーザー識別子は別途本書で作らず、アクター一覧の対応アクターID(ACT-1, ACT-2, ...)をそのまま用いる(二重識別子を避ける)。複数アクターをまとめる場合は中黒区切り(例: ACT-5・ACT-6)
5. 上流から確定できない値には要確認マーカーを付ける(例: 具体的な性能数値・SLAの厳密値・セキュリティ準拠基準のバージョン 等)

留意事項

• 本書の規律(共通要求のみを書く): 「3 ドメイン以上で共通して効く要求」のみ本書に書く。2 ドメイン以下にしか効かない要求はドメイン要求仕様書(個別)に降ろす。本書を everything doc 化させない
• §機能要求 は業務機能に絞る(がっつり業務寄せ): §機能要求 には「プロダクトが業務として提供する横断機能」(業務通知・帳票出力・業務の中断/再開・同意取得 等)のみ置く。認証・認可・監査ログ等のセキュリティの仕組みは §セキュリティ要求、エラー検知・リトライ・冪等性等の信頼性および外部サービス疎結合連携等のアーキ方針は §非機能要求(信頼性・互換性) に振り分ける。判定軸は「重複の有無」ではなく「業務の話か」で、セキュリティ・法務と多少重なっても業務機能なら機能要求に残してよい
• 下流成果物との棲み分け: 以下は本書に書かず、各下流成果物に降ろす
  • 個別ドメインの業務ルール・業務状態遷移・業務運用(イレギュラー対応) → ドメイン要求仕様書群(個別)
  • ユーザーストーリー(誰が何のために) → ユーザーストーリー一覧
  • ユースケース(具体的な操作シナリオ) → ユースケース一覧
  • 機能の網羅リスト → 機能一覧(D2)
  • 画面の具体仕様 → 画面要件群(D2)
• 業務 + プロダクト観点に留まる: 機能名・画面名・テーブル名・API 名等のシステム実装語は混入させない
• What と How の境界(具体水準は本書で確定): 原則として How(具体的な実装手段)には踏み込まないが、ビジネス・規制上譲れない具体水準(可用性目標値・監査ログ保持期間・準拠すべき業界基準・暗号化アルゴリズム強度 等)は本書で確定する。判定軸は「ビジネス・規制の非交渉性」: 実装選択肢を狭めるだけの規定なら D2 以降に降ろし、ビジネス上の必達条件であれば本書に書く。「可用性は高水準を保つ」のようなフワッとした抽象化で逃げない
• 並列モデルでの単独責務: 本書とドメイン要求仕様書群(個別)は 並列の関係(参照関係を持たない)。横断的な水準・方針・原則は本書が 単独責務 を持ち、個別ドメイン側で言い換えない。本書の各 ID(DOM-COMMON-FR-1, DOM-COMMON-NFR-1, DOM-COMMON-SEC-1, DOM-COMMON-REG-1 等)は下流のユーザーストーリー一覧・機能一覧(D2)から 横断ストーリー・横断機能の起点として直接参照される。文言・粒度を一貫させ、表記揺れを起こさない
• 個別ドメイン側で言い換えられやすい領域: 以下の領域は本書で定義しても、AUDIT/SUIT/CUST/PLCY/ESIGN 等の個別ドメインで言い換え再記述されやすい。本書側ではこれらの ID を 明確に「これが単独責務」と読み手に伝わる粒度・具体性で記述し、個別ドメイン側が「本書の言い換え BR」を立てる動機を与えないように設計する:
  • 改ざん不能性・証跡保持期間(SEC-6/SEC-7)
  • 電子帳簿保存法対応(真実性・可視性)(REG-5)
  • 同意管理(取得・撤回・更新)(FR-4 + REG-3 + SEC-DATA-2)
  • RBAC・最小権限(SEC-5)
  • 反社チェック義務(REG-7) 個別ドメイン側で BR として立てるべきは「当該ドメイン固有のスコープ・粒度・対象集合・運用」のみで、本書とは内容が重ならない
• PRD との役割分担: 方針・概念・体験設計・制約事項・受け入れ基準 は PRD の責務。本書は具体要求(共通)に責務を限定する。PRD と本書の二重定義を避ける
• フェーズ2 ラベルの付与: 初期フェーズの対象外で将来追加される要件(チャネル拡張・新商品・機械学習活用・将来連携 等)は [フェーズ2] ラベル(または「フェーズ2以降」記号)で明示し、初期/将来の境界を読み手に分からせる。BRD・PRD の同種ラベルと表記を揃える
• 上流との整合性: BRDのスコープ・KPI・制約・フェーズ2 / アクター一覧の対象ユーザー / ドメイン定義書のドメイン構成 / PRD の方針 と矛盾させない

完成時のセルフチェック

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

• 本書が「3 ドメイン以上で共通する要求」のみに絞られており、everything doc 化していないか(2 ドメイン以下のものが混入していないか)
• §機能要求 が業務機能(業務通知・帳票出力・業務の中断/再開・同意取得 等)に絞られ、列見出しが「機能区分」となっているか。認証・認可・監査ログ(→セキュリティ)/ エラー検知・リトライ・冪等性(→非機能の信頼性)/ 外部サービス疎結合 等のアーキ方針(→非機能の互換性) が混入していないか
• 個別ドメインの業務ルール・業務状態遷移・業務運用(イレギュラー対応)が混入していないか
• ユーザーストーリー・ユースケース・機能の網羅リスト・画面の具体仕様が混入していないか
• BRDのスコープ・KPI・制約と整合しているか(フェーズ2の境界も含む)
• 各節の要求表に ID(DOM-COMMON-<カテゴリ>-<連番> 形式)が付与され、下流(ユーザーストーリー一覧・機能一覧 等)から横断ストーリー・横断機能の起点として参照可能になっているか
• 個別ドメインで言い換えられやすい領域(改ざん不能性 SEC-6/SEC-7 / 電子帳簿保存法 REG-5 / 同意管理 FR-4+REG-3+SEC-DATA-2 / RBAC SEC-5 / 反社 REG-7)が、本書側で十分な粒度・具体性で書かれているか(あいまいで個別側が補足したくなる書き方になっていないか)
• 機能名・画面名・テーブル名・API 名等のシステム実装語が混入していないか
• ビジネス・規制上譲れない具体水準(可用性目標値・ログ保持期間・準拠基準 等)が抽象化されすぎていないか(「可用性は高水準を保つ」等のフワッとした記述で逃げていないか)
• 将来要件・将来拡張に該当する箇所に [フェーズ2] ラベル(または同等表記)が付与されているか
• §UI/UX 方針 が観点ごとに ID(DOM-COMMON-UX-*)を持ち、方針宣言に留まり具体画面仕様が混入していないか
• {{ や XXX のプレースホルダが残っていないか

下流への伝搬関係

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

下流成果物	ドメイン共通要求仕様書から何を引く
ドメイン要求仕様書群(個別)	参照しない(並列の関係。同じ要求実体を両側で語らない。本書が横断的水準・方針・原則の単独責務を持つ)
ユーザーストーリー一覧	横断ストーリー(区分=横断)の上流として DOM-COMMON-* を直接参照
画面コンセプト集	体験原則の上流参照(DOM-COMMON-*)
ユースケース一覧 / 機能一覧(D2) / 画面要件群(D2)	横断機能・横断要件の起点として参照