ユースケース一覧の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、ユーザーストーリー一覧・ドメイン要求仕様書群を上流とし、**1 オペレーション(操作。ドメイン要求仕様書の業務状態遷移における 1 遷移)= 1 UC = 1 シーケンス図** の単位に分割した一覧。
1 UC 1 行のフラット表で章分割せず、ID は通し連番(`UC-1`, `UC-2`, …)。
**後続の D2 システム要件・D3 システム設計工程における最重要成果物であるシーケンス図の分割単位** となるため、各 UC は 1 本のシーケンス図に無理なく収まるオペレーション粒度(例: 設計書作成=「商品・特約選択」「保険料試算」「意向整合検証」「プラン比較提示・確定」に分割)とし、工程まるごとを 1 UC にしない。
同一アクターのインライン例外(IRR)は同一 UC の alt 分岐に、別アクター・別トリガの収束業務とプロダクト共通能力(認証/中断再開/通知/帳票/同意/縮退/例外UX)は独立 UC に切り出す。ユーザーストーリー一覧の策定後、業務局面のオペレーション分解段階で呼び出す。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
| 成果物のパス | 内容 |
|---|---|
docs/D1.business-requirements/user-story-list.md | 上流のユーザーストーリー一覧(本書の集約源。US-* ID をそのまま「関連 US」列に引く) |
docs/D1.business-requirements/product-requirement-document.md | 上流の PRD(直接利用アクター・体験設計・受け入れ基準) |
docs/D1.business-requirements/domain-requirements/*.md | 上流のドメイン要求仕様書群。各書の §業務状態遷移(stateDiagram)が UC のオペレーション分割の主たる根拠(遷移=オペレーション=UC)。§業務ルール・§業務運用(イレギュラー対応)は各 UC の成果・alt 分岐・関連要求 ID の根拠 |
docs/D1.business-requirements/domain-requirements/domain-common-requirement-document.md | 上流のドメイン共通要求仕様書(横断 UC 候補の判定根拠) |
docs/D1.business-requirements/actor-list.md | アクター一覧(ACT-* ID の参照元) |
docs/D1.business-requirements/use-case-list.md | 既存のユースケース一覧(更新・レビュー時のみ参照。新規作成時は未存在) |
| 成果物のパス | 内容 |
|---|---|
docs/D1.business-requirements/use-case-list.md | ユースケース一覧本体(単一のフラット表) |
出力時は以下のテンプレートを読み込み、その列構成・書き方ヒントに従う。
| テンプレートのパス | 内容 |
|---|---|
.claude/skills/d1-use-case-list/template.md | ユースケース一覧テンプレート(列構成・書き方ヒント) |
本書は 「本書について」「想定読者」「注記」「受け入れ基準」 等の編集メタ章を持たない。タイトル(# ユースケース一覧)直下に単一のフラット表のみが置かれる構成。前提・位置づけ・編集チェック観点は本スキル(および テンプレ冒頭の HTML コメントブロック)に集約し、成果物本体には残さない。スプレッドシート/Excel への移送を想定し、ドメイン別の章分割は行わない。
# ユースケース一覧
| ID | ドメイン / 区分 | UC 名 | 主アクター | トリガ | 主要価値 | 関連 US | 関連要求 ID |
|---|---|---|---|---|---|---|---|
| UC-6 | 設計書作成 | 確定意向を受領し商品・特約を選択してプランを構成する | 募集人: ACT-1・ACT-2 | ... | ... | US-13, US-14 | DOM-DESIGN-BR-1, ... |
| UC-7 | 設計書作成 | 保険料を試算する | 募集人: ACT-1・ACT-2 | ... | ... | US-17, US-18 | DOM-DESIGN-BR-3, ... |
| UC-8 | 設計書作成 | 設計プランの意向整合性を検証する | 募集人: ACT-1・ACT-2 | ... | ... | US-15, US-16 | DOM-DESIGN-BR-2, ... |
| UC-67 | 横断 | 本プロダクトにログインする | 全直接利用アクター: ACT-1〜6 | ... | ... | US-100〜105 | DOM-COMMON-SEC-1, DOM-COMMON-SEC-2 |
| UC-68 | 横断 | 業務通知を配信する | ... | ... | ... | US-106〜110 | DOM-COMMON-FR-1 |
シーケンス図分割単位としての規律(本書の最重要原則): 各 UC は 1 本のシーケンス図に対応する 1 オペレーション(操作)。「主アクター 1(または同等業務責務の複数アクター)・トリガ 1・成果 1」を満たし、1 本のシーケンス図に無理なく収まる粒度であること。
新規作成時(docs/D1.business-requirements/use-case-list.md 未存在)は ユーザーへのヒアリングを行わず、上流(ユーザーストーリー一覧・ドメイン要求仕様書群・PRD・アクター一覧)から本書を直接生成する。
システム等を主アクターにしない)区分=横断)の扱い — プロダクト共通(プラットフォーム)能力は独立 UC とする:
DOM-COMMON-* 要求(FR/NFR/SEC/UX/REG)および関連するドメイン IRR を「関連要求 ID」に引くUC-<連番> 形式の通し番号(例: UC-1, UC-2 …)。ドメイン情報は ID に含めず「ドメイン / 区分」列で表現する意向把握)または 横断。複数ドメインにまたがる場合は主たるドメイン名を記載(横断は §横断の判定基準に従う)意向を把握する / 申込を受け付ける / 本プロダクトにログインする)。システム実装語(画面名・API 名・テーブル名)は混入させない募集人: ACT-1・ACT-2)。被保険者本人・申込人本人など本人系も同様に併記可。業務責務が異なるアクターは別 UC に分割 する顧客との初回面談』, 第一回保険料の支払期日到来, 契約成立確定`)。業務言語で記述適合性原則違反のリスクなく後工程へ意向を引き渡せる)。なぜ必要かを業務観点で記述。KPI への直接効果があれば BRD KPI を引用US-1〜12 のように波ダッシュで圧縮、不連続は US-1, US-3, US-5 のようにカンマ区切り。範囲とカンマの混在可(US-1〜12, US-114)。横断 US を吸収する場合もここに含めるDOM-<コード>-BR/IRR/DATA-* および/または DOM-COMMON-*)。関連 US から逆引きで決定。1 UC は両方の要求体系を参照しうる(横断要求の取り込みも併記される)[フェーズ2] ラベルを付ける(ユーザーストーリー一覧・PRD・ドメイン要求仕様書の同種ラベルと表記を揃える)UC-<連番> 形式の通し番号。ドメインや区分は ID に含めず「ドメイン / 区分」列に降ろす(CLAUDE.md §8 の「単一種類しか振らない成果物では <成果物略号>-<連番>」に準拠)### {{ドメイン名}} のような subsection を復活させない。区別は表の「ドメイン / 区分」列で表現するACT-* をそのまま使う(本書独自の USR-* 等を作らない)。主アクター列の表記は アクター名: ACT-N のコロン区切り(複数は中黒)US-1〜12 のように波ダッシュで圧縮、不連続は US-1, US-3 のようにカンマ区切り。範囲とカンマの混在(US-1〜12, US-114)を許容する。範囲表記時も含まれる全 US が当該 UC に紐づくことを必ず確認する(範囲内に他 UC 所属 US が混在しないこと)[フェーズ2] ラベルを付ける。ユーザーストーリー一覧・PRD・ドメイン要求仕様書の同種ラベルと表記を揃えるUS-* ID と関連 US 列の範囲表記が完全一致すること(参照切れ・取りこぼしを起こさない)。各 UC の関連要求 ID が上流要求書に実在することを確認する執筆完了時に以下の観点で出力を検査し、不備があれば修正したうえで出力を完了とする。
### {{ドメイン名}} subsection を作っていないか(フラット表 1 枚に集約されているか)アクター名: ACT-N 形式で、アクター一覧の ID と一致しているか(本書独自のユーザー ID が作られていないか)US-1〜12 等)が連続する US 群でのみ用いられ、範囲内に他 UC 所属 US が混在していないかUC-<連番> の通し番号で重複なく連続しているか(ドメイン情報を ID に含めていないか)[フェーズ2] ラベルが付与され、上流の同種ラベルと表記が揃っているか{{ や XXX のプレースホルダ、不要な要確認マーカーが残っていないか作成・更新時は以下の下流成果物との整合を意識する:
| 下流成果物 | ユースケース一覧から何を引く |
|---|---|
| 機能一覧(D2) | 各 UC から「主要価値の実現に必要な機能」を抽出。横断(プラットフォーム能力)UC(認証・中断再開・通知配信・帳票出力・同意管理・縮退運用・例外UX)由来の機能は横断機能としてまとめる |
| 画面要件群(D2) | 各 UC の主アクター × 主要価値 から、主アクター視点での画面要件を導出 |
| L1/L2 シーケンス図(D2/D3) | 本書の 1 UC = 1 シーケンス図 を基本とする。主アクター・トリガ・成果が一意のためシーケンスがそのまま描ける。業務局面 UC のシーケンスは、横断能力 UC(通知配信・帳票出力・同意管理・縮退運用・KYC/反社/電子署名 等)のシーケンスを参照(ref フラグメント)し、共通フローを括り出すことで 1 本あたりの長さを抑える |
| テスト計画 | 各 UC の主要価値・トリガ・関連 US の Acceptance Criteria を起点に業務観点テストケースを設計 |
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
アクター一覧の新規作成・更新・レビューを支援する。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策定後、ドメイン整理の段階で呼び出す。
ドメイン要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)を親文書とし、ドメイン定義書で定義された各ドメインごとに1冊作成される。**ドメイン共通要求仕様書(横断的な水準・方針・原則)とは並列の関係にあり、当該ドメイン固有の業務ルール・業務状態遷移・業務運用(イレギュラー対応)のみを扱う(共通要求と内容が重なる要求は本書に書かない=厳密な MECE)。** PRD・ドメイン定義書の策定後、ドメインごとの業務要求を具体化する段階で呼び出す。下流のユーザーストーリー一覧・ユースケース一覧・機能一覧(D2)・画面要件群(D2)・L1/L2シーケンス図の起点となる。
プロダクト要求仕様書(PRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、方針・概念・体験設計・制約・受け入れ基準を扱う文書。具体的な横断要求(機能要求・非機能要求・UI/UX・セキュリティ・法務 等)は独立成果物のドメイン共通要求仕様書に集約し、PRD は要求 ID を持たない。BRD・アクター一覧・ドメイン定義書 を上流とし、BRD策定後、ドメイン共通要求仕様書の作成前に呼び出す。