Skip to content
cccskills
FreePublished on GitHub

d2-function-list

機能一覧の新規作成・更新・レビューを支援する。ユースケース一覧をはじめとする D1.ビジネス要求成果物を「システムが提供する機能能力」へ翻訳する文書。ユースケース一覧の策定後、機能の洗い出し段階で呼び出す。

The English summary is being prepared. Showing the original description.

See how to install

Files included (2)

  • SKILL.md4.7 KB
  • template.md954 B

SKILL.md (original)

Review the instructions the agent will receive before you install.

D2: 機能一覧

inputする成果物

成果物のパス内容
docs/D1.business-requirements/use-case-list.md上流のユースケース一覧(機能抽出の主たる起点。各 UC を実現するシステム機能を抽出し、UC-* を「関連 UC」列に引く)
docs/D1.business-requirements/domain-requirements/*.md上流のドメイン要求仕様書群(ドメイン共通要求仕様書を含む)。個別書の §業務ルール(DOM-<コード>-BR-*)が機能能力、§業務運用イレギュラー対応(DOM-<コード>-IRR-*)が例外系の根拠。ドメイン共通要求仕様書の §機能要求(DOM-COMMON-FR-*)が横断共通機能の根拠
docs/D1.business-requirements/product-requirement-document.md上流の PRD(スコープ境界・[フェーズ2] 境界の判定根拠)
docs/D1.business-requirements/user-story-list.md上流のユーザーストーリー一覧(US-*。機能の網羅・利用アクター確認の補助)
docs/D1.business-requirements/actor-list.mdアクター一覧(ACT-* の参照元)

outputする成果物

成果物のパス内容
docs/D2.system-requirements/function-list.md機能一覧本体(単一のフラット表)。骨組みは .claude/skills/d2-function-list/template.md に従う

機能の粒度(UC 実現単位)

本書の最重要原則。1 機能は「ある UC の主要価値を実現するためにシステムが提供する、識別可能な機能能力(capability)」。

  • 抽出の起点は UC: 各 UC について「実現にシステムは何を提供する必要があるか」を問う。1 UC → 通常 1〜3 機能。
  • 密結合は束ねる: 入力とその場の検証 等、一体提供される能力は分割しない。CRUD の機械分割(登録/参照/更新/削除を別機能)はしない。
  • 横断共通機能は 1 つに集約: 複数 UC から再利用される能力(認証・中断/再開・通知配信・帳票出力・同意取得/撤回/更新・縮退運用・例外UX、外部連携の KYC・反社・電子署名・真実性措置)は 機能分類 = 横断 で 1 機能に集約し、関連 UC 列に呼び出し元 UC を併記する(アクター別・業務局面別に割らない)。
  • 下限: 単一フィールド検証 等、オペレーション未満には刻まない。
  • 上限: 工程まるごと(設計書作成機能 等)を 1 機能にしない。機能名が複数能力を接続詞でつないでいたら分解サイン。
  • 例外系: 同一機能のインライン例外(IRR)は当該機能に内包。別アクター・別トリガの収束業務(別 UC になっているもの)は別機能とする。
  • スコープは機能要求のみ: DOM-*-BR / DOM-COMMON-FR 由来の機能能力のみを立てる。非機能(NFR/SEC/UX/REG)は機能化せず D2 非機能要件側で扱い、本書では機能の制約・関連付け参照に留める。
  • 網羅: 全 UC が少なくとも 1 機能の「関連 UC」列に現れること(トレーサビリティは CLAUDE.md §11)。

各列の埋め方

  • ID: FUNC-<連番> の通し番号。分類は ID に含めず「機能分類」列で表現する。
  • 機能分類: ドメイン名(意向把握 / 設計書作成 / 引受査定 等)または 横断。ユースケース一覧の「ドメイン / 区分」と語彙を揃える。
  • 機能名: システム機能名(体言止め 〜機能)。D2 の抽象度はシステム機能能力(実装語の扱いは CLAUDE.md §11)。
  • 機能概要: システムが何をするか(検証・記録・連携・抑止 等)を主語システムで 1〜2 文。インライン例外の振る舞いも簡潔に含める。
  • 利用アクター: 元 UC の主アクターを引く。自動処理でも所管する人間アクターを据え、システム を利用アクターにしない。
  • 関連 UC: 実現する UC-*。
  • 関連要求 ID: 根拠要求(DOM-<コード>-BR/IRR/DATA-* / DOM-COMMON-FR-*)。元 UC の関連要求から該当部分を引く。

並び順・ラベル

  • ユースケース一覧のドメイン並びを踏襲し、最後に横断(プロダクト共通機能)群を並べる。
  • 元 UC が [フェーズ2] の機能には [フェーズ2] を付ける。

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

アクター一覧の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本システムに関わるすべての人間アクター(関係者)を一覧化する文書。TOGAFのActor Catalog相当。BRDの下流に位置する成果物。後続の成果物であるプロダクト要求仕様書やユーザーストーリー一覧、C4モデルレベル1、C4モデルレベル2、L1シーケンス、L2シーケンスなど、様々な成果物から参照される。BRD策定後、アクター整理の段階で呼び出す。

The English summary is being prepared. Showing the original description.

Acceler-Digital/karura8Updated Sep 26, 2026

ビジネス要件定義書(BRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)の中でも最上流に位置する成果物であり、ドメイン定義書・プロダクト要求仕様書(PRD)本体・ドメイン要求仕様書群すべての根拠となる業務観点の要求文書。新規プロジェクト立ち上げ時の最初の成果物作成、戦略・スコープの大きな変更、KPI見直しのタイミングで呼び出す。

The English summary is being prepared. Showing the original description.

Acceler-Digital/karura8Updated Sep 26, 2026

ドメイン共通要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)が方針・概念を扱うのに対し、本書は **3 ドメイン以上で横断的に効く具体的な要求(水準・方針・原則)** を集約する文書。**ドメイン要求仕様書群(個別)とは並列の関係にあり、横断的な水準・方針・原則は本書が単独で責務を持つ(=厳密な MECE。個別ドメインで言い換えない)。** 機能要求・非機能要求・UI/UX 方針・セキュリティ要求・データアクセス要求・法務/コンプライアンス要求 の各節を持つ。PRD・アクター一覧・ドメイン定義書 を上流とし、PRD策定後、ドメイン要求仕様書群(個別)の作成前に呼び出す。

The English summary is being prepared. Showing the original description.

Acceler-Digital/karura8Updated Sep 26, 2026

ドメイン定義書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本プロダクトを構成する業務領域(ドメイン)を網羅・分類する文書。問題空間(プロダクトが扱う業務領域)の整理であり、DDDにおけるBounded Context(解空間としての実装上の境界)とは別レイヤーで扱う。BRDの下流に位置する成果物。後続のプロダクト要求仕様書、ドメイン要求仕様書群(各ドメインごとに1つ)など、様々な成果物から参照される。BRD策定後、ドメイン整理の段階で呼び出す。

The English summary is being prepared. Showing the original description.

Acceler-Digital/karura8Updated Sep 26, 2026

ドメイン要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)を親文書とし、ドメイン定義書で定義された各ドメインごとに1冊作成される。**ドメイン共通要求仕様書(横断的な水準・方針・原則)とは並列の関係にあり、当該ドメイン固有の業務ルール・業務状態遷移・業務運用(イレギュラー対応)のみを扱う(共通要求と内容が重なる要求は本書に書かない=厳密な MECE)。** PRD・ドメイン定義書の策定後、ドメインごとの業務要求を具体化する段階で呼び出す。下流のユーザーストーリー一覧・ユースケース一覧・機能一覧(D2)・画面要件群(D2)・L1/L2シーケンス図の起点となる。

The English summary is being prepared. Showing the original description.

Acceler-Digital/karura8Updated Sep 26, 2026

プロダクト要求仕様書(PRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、方針・概念・体験設計・制約・受け入れ基準を扱う文書。具体的な横断要求(機能要求・非機能要求・UI/UX・セキュリティ・法務 等)は独立成果物のドメイン共通要求仕様書に集約し、PRD は要求 ID を持たない。BRD・アクター一覧・ドメイン定義書 を上流とし、BRD策定後、ドメイン共通要求仕様書の作成前に呼び出す。

The English summary is being prepared. Showing the original description.

Acceler-Digital/karura8Updated Sep 26, 2026

See all skills by Acceler-Digital

Report a problem with this skill