ドメイン要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)を親文書とし、ドメイン定義書で定義された各ドメインごとに1冊作成される。
**ドメイン共通要求仕様書(横断的な水準・方針・原則)とは並列の関係にあり、当該ドメイン固有の業務ルール・業務状態遷移・業務運用(イレギュラー対応)のみを扱う(共通要求と内容が重なる要求は本書に書かない=厳密な MECE)。** PRD・ドメイン定義書の策定後、ドメインごとの業務要求を具体化する段階で呼び出す。
下流のユーザーストーリー一覧・ユースケース一覧・機能一覧(D2)・画面要件群(D2)・L1/L2シーケンス図の起点となる。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
| 成果物のパス | 内容 |
|---|---|
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 | 既存ドメイン要求仕様書(更新・レビュー時のみ参照。新規作成時は未存在) |
| 成果物のパス | 内容 |
|---|---|
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ドメインずつ、テンプレートの章順に従って書き出す。
{{ドメイン名}} をドメイン定義書「一覧」の名と一致させて置換する。概要・注記以外の前文は設けないDOM-COMMON-*)は記載しない(参照関係を持たないため)。本ドメインの責務境界(他ドメイン・既存システムとの分担)が明確な場合は、その範囲を業務ルールとして1項立てる(例: 計上完了までを担い継続収納は既存収納システムに引き渡す、本ドメインは証跡の収集・保全に責務を限定し業務判断ロジックは工程ドメインに委ねる 等)state "名前" as エイリアス { ... })で1つの図に並置する。遷移ラベルに (XXX-BR-N) 形式の業務ルールIDを括弧書きで添えると図と表のトレーサビリティが上がる(XXX-BR-N に整合) 形式で 本ドメイン内の関連 BR ID のみ を併記する(DOM-COMMON-* は参照関係を持たないため記載しない)DOM-COMMON-SEC-DATA-* の記載)はしない(並列モデルのため)。構造詳細は D2 に降ろすDOM-COMMON-*)は併記しない(並列モデルのため)。本書独自の受け入れ観点を、本ドメイン内の BR/IRR/DATA ID で必要に応じて参照しつつ書く[フェーズ2] ラベルを付ける<ドメインコード>-<カテゴリ>-<連番> 形式(成果物略号=当該ドメインコード)。カテゴリは 業務ルール=BR / 業務運用(イレギュラー)=IRR / ドメイン固有データ=DATA。例: DOM-HEAR-BR-1, DOM-HEAR-IRR-1, DOM-HEAR-DATA-1。CLAUDE.md §8 に準拠DOM-COMMON-* ID は記載しない。本書と共通要求は同じ要求実体を語らない=厳密な MECE を維持する[フェーズ2] ラベルで境界を明示し、PRD・BRD の同種ラベルと表記を揃える執筆完了時に以下の観点で出力を検査し、不備があれば修正したうえで出力を完了とする。
DOM-COMMON-* ID が記載されていないか(並列モデルのため参照関係を持たない。語彙(機密区分名等)の引用は OK、ID 記載は NG)(XXX-BR-N に整合) 形式で紐づけられているか(DOM-COMMON-* 参照は記載しない)DOM-COMMON-SEC-DATA-*)を記載していないかDOM-COMMON-* ID 参照や「継承 PRD 要求の充足」表現を含んでいないか<ドメインコード>-<カテゴリ>-<連番> 形式)が付与され、後続成果物から参照可能になっているか[フェーズ2] ラベルが付与されているか{{ や XXX のプレースホルダ、不要な要確認マーカーが残っていないか作成・更新時は以下の下流成果物との整合を意識する:
| 下流成果物 | ドメイン要求仕様書から何を引く |
|---|---|
| ユーザーストーリー一覧 | 当該ドメインの業務ルール・業務運用(誰が何のために) |
| ユースケース一覧 | 業務状態遷移・業務運用(イレギュラー対応)から具体シナリオ |
| 機能一覧(D2) | 業務ルールから導出される機能(横断機能は別途ドメイン共通要求から導出される) |
| 画面要件群(D2) | 業務状態遷移・業務運用 + 機能一覧 |
| L1/L2 シーケンス図 | 業務状態遷移・業務ルールの根拠/契機が指すドメイン定義書の連携 |
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
アクター一覧の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本システムに関わるすべての人間アクター(関係者)を一覧化する文書。TOGAFのActor Catalog相当。BRDの下流に位置する成果物。後続の成果物であるプロダクト要求仕様書やユーザーストーリー一覧、C4モデルレベル1、C4モデルレベル2、L1シーケンス、L2シーケンスなど、様々な成果物から参照される。BRD策定後、アクター整理の段階で呼び出す。
ビジネス要件定義書(BRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)の中でも最上流に位置する成果物であり、ドメイン定義書・プロダクト要求仕様書(PRD)本体・ドメイン要求仕様書群すべての根拠となる業務観点の要求文書。新規プロジェクト立ち上げ時の最初の成果物作成、戦略・スコープの大きな変更、KPI見直しのタイミングで呼び出す。
ドメイン共通要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)が方針・概念を扱うのに対し、本書は **3 ドメイン以上で横断的に効く具体的な要求(水準・方針・原則)** を集約する文書。**ドメイン要求仕様書群(個別)とは並列の関係にあり、横断的な水準・方針・原則は本書が単独で責務を持つ(=厳密な MECE。個別ドメインで言い換えない)。** 機能要求・非機能要求・UI/UX 方針・セキュリティ要求・データアクセス要求・法務/コンプライアンス要求 の各節を持つ。PRD・アクター一覧・ドメイン定義書 を上流とし、PRD策定後、ドメイン要求仕様書群(個別)の作成前に呼び出す。
ドメイン定義書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本プロダクトを構成する業務領域(ドメイン)を網羅・分類する文書。問題空間(プロダクトが扱う業務領域)の整理であり、DDDにおけるBounded Context(解空間としての実装上の境界)とは別レイヤーで扱う。BRDの下流に位置する成果物。後続のプロダクト要求仕様書、ドメイン要求仕様書群(各ドメインごとに1つ)など、様々な成果物から参照される。BRD策定後、ドメイン整理の段階で呼び出す。
プロダクト要求仕様書(PRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、方針・概念・体験設計・制約・受け入れ基準を扱う文書。具体的な横断要求(機能要求・非機能要求・UI/UX・セキュリティ・法務 等)は独立成果物のドメイン共通要求仕様書に集約し、PRD は要求 ID を持たない。BRD・アクター一覧・ドメイン定義書 を上流とし、BRD策定後、ドメイン共通要求仕様書の作成前に呼び出す。
画面コンセプト集の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト全体の画面体験コンセプト(体験方向性・体験原則・トーン&マナー方針)と、それを体現する代表シーン2-3を、ビジネスサイドが議論・合意できるサイズに整理する文書。業界を問わず利用可能(業務アプリ・ゲーム・コンシューマー向けサービス・SaaS 等)。プロダクト要求仕様書(PRD)・アクター一覧・ユーザーストーリー一覧を上流とし、下流のワイヤーフレーム・画面遷移図・画面要件群(D2)の判断基準となる画面体験の方向性を定める。全画面の網羅は D2 画面要件群に降ろし、本書はコンセプトと代表シーンに集約する。PRD・ユーザーストーリー一覧の策定後、D2 画面要件群の作成前、もしくはデザイン会社への発注前に呼び出す。