アクター一覧の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本システムに関わるすべての人間アクター(関係者)を一覧化する文書。TOGAFのActor Catalog相当。BRDの下流に位置する成果物。後続の成果物であるプロダクト要求仕様書やユーザーストーリー一覧、C4モデルレベル1、C4モデルレベル2、L1シーケンス、L2シーケンスなど、様々な成果物から参照される。BRD策定後、アクター整理の段階で呼び出す。
d2-non-functional-requirements
非機能要件の新規作成・更新・レビューを支援する。IPA「非機能要求グレード」の項目体系に沿って、メトリクスごとのレベル値と要求内容を定める D2 成果物。機能一覧・外部システム一覧・C4モデル レベル1(システムコンテキスト)の整備後に呼び出す。
含まれるファイル(3)
- SKILL.md16.6 KB
- template-chapter.md3.1 KB
- template-general.md2.8 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
D2: 非機能要件
inputする成果物
| 成果物のパス | 重要度 | 内容 |
|---|---|---|
docs/D1.business-requirements/business-requirement-document.md | 重要 | BRD(目標数値・制約の一次ソース。§KPI が可用性・性能の目標値、§対象ユーザー概要が利用者規模、§予算の制約がレベル値のトレードオフ判断の分母、§スケジュールの制約が移行性の全メトリクス、§法務・コンプライアンス・人事的制約がセキュリティの前提) |
docs/D1.business-requirements/product-requirement-document.md | 重要 | PRD(対象システムの責務境界・利用形態の定義元。§プロダクト概要・§利用形態が対象範囲、§制約事項が各レベル値の上限、§受け入れ基準が非機能の検証条件) |
docs/D1.business-requirements/domain-requirements/*.md | 重要 | ドメイン要求仕様書群(ドメイン共通要求仕様書を含む)。ドメイン共通要求仕様書 §非機能要求(DOM-COMMON-NFR-*)が本書の直接の親。§セキュリティ要求(DOM-COMMON-SEC-* / DOM-COMMON-SEC-DATA-*)・§法務・コンプライアンス要求(DOM-COMMON-REG-*)がセキュリティ大項目の根拠。統制・証跡管理ドメイン(DOM-AUDIT-*)が運用・保守性(ログ保存・権限棚卸)の根拠 |
docs/D2.system-requirements/external-system-list.md | 重要 | 外部システム一覧(可用性・障害時運用・互換性の適用範囲の定義元。EXT-* ごとに停止時の業務影響・縮退可否・更改耐性の水準が決まる) |
docs/D2.system-requirements/function-list.md | 重要 | 機能一覧(性能目標値・可用性を特定機能に限定して適用する場合の参照先。FUNC-* を関連 ID に引く) |
docs/D2.system-requirements/c4-level1-system-context.md | 重要 | C4モデル レベル1(システム境界と直接利用アクターの定義元。利用者数・同時アクセス数の母数、および外部インターフェース点の一覧) |
outputする成果物
| 成果物のパス | 内容 |
|---|---|
docs/D2.system-requirements/non-functional-requirements/総則.md | 総則(入口。本書について / モデルシステムと前提条件 / 対象範囲と対象外メトリクス / 本書の構成) |
docs/D2.system-requirements/non-functional-requirements/A.可用性.md | A. 可用性(A.1 継続性 / A.2 耐障害性 / A.3 災害対策 / A.4 回復性) |
docs/D2.system-requirements/non-functional-requirements/B.性能・拡張性.md | B. 性能・拡張性(B.1 業務処理量 / B.2 性能目標値 / B.3 リソース拡張性 / B.4 性能品質保証) |
docs/D2.system-requirements/non-functional-requirements/C.運用・保守性.md | C. 運用・保守性(C.1 通常運用 / C.2 保守運用 / C.3 障害復旧運用 / C.4 運用環境 / C.5 サポート体制 / C.6 その他の運用管理方針) |
docs/D2.system-requirements/non-functional-requirements/D.移行性.md | D. 移行性(D.1 移行時期 / D.2 移行方式 / D.3 移行対象(機器) / D.4 移行対象(データ) / D.5 移行作業) |
docs/D2.system-requirements/non-functional-requirements/E.セキュリティ.md | E. セキュリティ(E.1 前提条件・制約条件 〜 E.11 セキュリティインシデント対応/復旧) |
docs/D2.system-requirements/non-functional-requirements/F.システム環境・エコロジー.md | F. システム環境・エコロジー(F.1 システム制約/前提条件 〜 F.5 環境マネージメント) |
使用するテンプレート
出力時は以下のテンプレートを読み込み、その章構成(大項目・中項目の見出しと並び)・表の列構成に従う。
| テンプレートのパス | 内容 |
|---|---|
.claude/skills/d2-non-functional-requirements/template-general.md | 総則テンプレート(入口ファイル 1 件分の骨組み) |
.claude/skills/d2-non-functional-requirements/template-chapter.md | 大項目テンプレート(大項目ファイル 1 件分の骨組み。6 大項目それぞれに適用する) |
生成規約
以下は本成果物を生成・更新する際に守る規約。
分割とファイル構成
- 1 大項目 = 1 ファイル。IPA の大項目より細かく割らない・粗くまとめない。ファイル名は
<大項目記号>.<大項目名>.md(記号と名称の間に空白を入れない。例:A.可用性.md)。大項目名はグレード表の表記をそのまま引く。 - ファイル名の先頭に数字を置かない。Docusaurus は
<数字>./<数字>-で始まるファイル名を並び順指定と解釈して doc id・URL から除去するため、sidebars.tsの参照とファイル名がずれる。大項目記号(A〜F)は英字なので除去されない。 - 前段(本書について / モデルシステムと前提条件 / 対象範囲と対象外メトリクス / 本書の構成)は
総則.mdに置き、大項目ファイルに複写しない。総則は全大項目のレベル値の根拠となるため、各大項目ファイルの冒頭に総則への参照リンクを 1 行置く。 - 見出しレベルは、大項目ファイルで 大項目が
#・中項目が##。中項目の節は対象メトリクスが 0 件でも削除せず、「対象メトリクスなし」とその理由を 1 文で記す。 - 総則 §本書の構成 に全大項目へのリンクとメトリクス件数を置き、分割後も全体像を 1 画面で追えるようにする。
ID の通し連番(ファイルをまたぐ)
NONFUNC-<連番>は 全ファイルを通した 1 本の連番。ファイルごとにリセットしない(分割は物理的な都合であり ID 体系を変える理由にならない)。大項目ファイルの先頭 ID が 1 以外になるのは正しい状態。- 行を追加する際は、当該大項目の末尾に追記して以降の全ファイルの ID を振り直すのではなく、全体の最大値の次の番号を採番する(既存 ID の意味を変えない)。結果として ID がファイル内で不連続になってよい。
- 他の行を参照するときは ID のみで引き、ファイル間の相対リンクを張らない(例: 「NONFUNC-7(RPO = 0)と同一根拠」)。分割構成を変えるたびにリンクを張り直す事態を避けるため。ファイル単位の参照(総則へのリンク 等)は相対リンクでよい。
準拠フレームワークと項目体系
- 項目体系は IPA「非機能要求グレード」 に準拠する。6 大項目(A. 可用性 / B. 性能・拡張性 / C. 運用・保守性 / D. 移行性 / E. セキュリティ / F. システム環境・エコロジー)と、その配下の中項目・メトリクスをそのまま章・節・行に写す。
- 大項目・中項目・メトリクス名・項番はグレード表の表記をそのまま引く。本書側で言い換え・統合・新設をしない。項目体系の見直しが必要と判断した場合は、勝手に変えずユーザーに確認する。
- レベル値はそのメトリクスに定義されているレベルの範囲内でのみ選ぶ(メトリクスごとに上限が異なる)。定義にない値・小数・範囲指定を書かない。
- 本書は IPA の項目体系を借りるが、レベル値と要求内容は本プロジェクトの上流成果物から決める。グレード表のモデルシステム推奨値をそのまま転記しない(推奨値は §モデルシステムの選択 で基準線として使い、差異を根拠付きで示す)。
スコープ(D2 の抽象度)
本書が決めるのは 「どの水準を要求するか」まで。その水準を どう実現するか(How)は D3 以降 に降ろす。IPA のメトリクスには実現方式に踏み込む語彙を含むものがあるため、以下で線を引く。
| 書く(D2) | 書かない(D3 以降) |
|---|---|
| 稼働率・許容停止時間・RTO / RPO・世代数・保存期間・応答時間・処理件数・データ量 等の要求水準 | 冗長化構成・クラスタ方式・バックアップ製品・ミドルウェア・機器選定・ネットワーク構成 等の実現手段 |
| 「業務時間帯の稼働率 99.9%」 | 「AZ 二重化+ロードバランサ配下で N+1 構成」 |
| 「監査ログを 10 年保持し検索可能とする」 | 「オブジェクトストレージの WORM 設定で保持」 |
- 実現手段を書きたくなった場合は、それが要求水準として言い換えられるかを確かめ、言い換えられないなら D3 に降ろして本書には書かない。
DOM-COMMON-NFR-5(クラウドネイティブ前提)により、F. システム環境・エコロジー の機材設置環境条件系メトリクスの多くは責任分界上クラウド事業者側に帰属する。該当するものは無理に水準を立てず §対象範囲と対象外メトリクス で「対象外」とその理由を明示する。
モデルシステムの選択
- 冒頭でモデルシステム(社会的影響が殆ど無いシステム / 限定されるシステム / 極めて大きいシステム)を 1 つ選び、選択理由を明記する。以降のレベル値はこの選択を基準線として決める。
- 選択理由は BRD の事実(取扱情報の性質・利用者規模・法令適用・KPI)から書く。
- モデルシステムの推奨レベルと異なるレベルを選んだ行は、選択根拠列の冒頭に
モデル推奨 N からの差異:と書き、差異の理由を続ける。基準線からどこをどう動かしたかが行単位で読めることが本書の合意価値であるため、差異を無言で埋めない。
対象メトリクスの範囲
- グレード表の全メトリクスを行として立てることを既定とする(上流に根拠がない場合も、仮置きのレベル値+要確認マーカーで必ず立てる。根拠がないことを理由に行ごと落とさない)。
- 対象外とするのは以下に限る。それ以外の理由で落とさない。
- 責任分界上、本プロダクトの要求として立てられないもの(クラウド事業者・外部サービス側に帰属)
- 本プロダクトの提供形態に存在しない構成要素に係るもの(自社調達しない機材・端末 等)
- 対象外メトリクスは 中項目単位で件数と理由を残す(何を見送ったかが後から追える状態にする)。
各列の埋め方
| 列 | 埋め方 |
|---|---|
| ID | NONFUNC-<連番>(採番規則は §ID の通し連番)。ID に大項目記号を含めない。分類は項番列が持つ |
| 項番 | <大項目記号>.<中項目>.<小項目>.<メトリクス> の 4 階層(例: A.1.1.1 = 可用性 / 継続性 / 運用スケジュール / 運用時間-通常)。グレード表の連番をそのまま引く |
| メトリクス | <小項目名>: <メトリクス名> の形でグレード表の表記をそのまま引く(例: サーバ: 冗長化(機器))。メトリクス名だけでは対象が特定できないものが多いため、小項目名を必ず前置する。言い換え・省略をしない |
| 重要項目 | IPA グレード表で重要項目とされているものに ◎、それ以外に −。グレード表の指定と照合できていない場合は ◎ を推測で付さず、§本書について で照合未了である旨を明示する |
| レベル | 選択したレベル値の数値のみ(例: 3) |
| 要求内容 | そのレベルが本プロダクトにおいて具体的に何を意味するかを、業務・システムの固有名詞と実数値 で書く。「高い可用性を確保する」のような水準の読めない書き方をしない。対象を限定する場合は対象範囲(業務時間帯・対象ドメイン・対象連携先)を明示する |
| 選択根拠 | なぜそのレベルかを 1〜2 文。モデル推奨と異なる場合は冒頭に差異表記(§モデルシステムの選択)。上流の記述が根拠なら、どの成果物のどの記述かが特定できる語で書く |
| 関連 ID | 根拠・適用対象となる他成果物の ID(DOM-COMMON-NFR-* / DOM-COMMON-SEC-* / DOM-COMMON-REG-* / DOM-AUDIT-* / EXT-* / FUNC-* / ACT-*)。該当がなければ − |
数値の出典
- 目標数値は上流から引き、本書で創作しない。稼働率・レスポンスタイム・スループット・利用者規模・年間件数・保存期間・リリース時期・予算枠 は、いずれも BRD またはドメイン共通要求仕様書に実数がある。まずそこを引く。
- 上流の数値を本書の粒度に展開する場合(例: 年間件数から日次・時間帯別のピーク件数を導く)は、導出の前提(営業日数・時間帯集中率 等)を選択根拠列に書く。前提が上流にないものは仮置きとなるため要確認マーカーを付す。
- 上流に出典がないレベル値・数値は、すべてインライン要確認マーカーを付す(記法は CLAUDE.md §3)。IPA の全メトリクスに対し上流の非機能要求は限られるため、本書はマーカーが多数残った状態で初版とし、経営・業務部門との合意を経て解消する前提で作る。
大項目ごとの主たる根拠
各大項目を埋める際に最初に当たる上流を以下に示す。ここに挙げていない上流を参照してよいが、挙げたものは必ず当たる。
| 大項目 | 主たる根拠 |
|---|---|
| A. 可用性 | DOM-COMMON-NFR-3(稼働率・計画停止)・DOM-COMMON-NFR-4(縮退運用)・DOM-COMMON-NFR-9(エラー検知・リトライ・冪等性)・BRD §KPI(システム稼働率)・BRD §プロジェクトの成功の定義(連携品質)・外部システム一覧(EXT-* ごとの停止時業務影響) |
| B. 性能・拡張性 | DOM-COMMON-NFR-1(レスポンスタイム)・DOM-COMMON-NFR-2(スループット)・DOM-COMMON-NFR-5(水平スケーリング)・BRD §対象ユーザー概要(利用者規模)・BRD §KPI(リードタイム)・機能一覧(性能目標の適用対象操作) |
| C. 運用・保守性 | DOM-COMMON-NFR-6(監視・障害検知)・DOM-COMMON-NFR-7(業務ルール保守性)・DOM-COMMON-NFR-8(更改耐性)・統制・証跡管理ドメイン要求仕様書(証跡保持期間・アクセス権限棚卸)・PRD §利用形態 |
| D. 移行性 | BRD §スケジュールの制約(リリース時期・並行運用期間・IF 仕様確定期日)・BRD §マーケティング(周知)戦略(並行運用の設定)・PRD §制約事項・外部システム一覧(既存システムへの引き継ぎ) |
| E. セキュリティ | BRD §セキュリティ要件(業界基準準拠・第三者診断・暗号化・アクセス制御・監査ログ)・BRD §法令・規制要件・DOM-COMMON-SEC-* / DOM-COMMON-SEC-DATA-*・DOM-COMMON-REG-*・統制・証跡管理ドメイン要求仕様書 |
| F. システム環境・エコロジー | DOM-COMMON-NFR-5(クラウドネイティブ前提)・BRD §予算の制約(ランニングコスト)・PRD §利用形態 |
網羅(トレーサビリティ)
本書は非機能の水準を システム全体に対して 定めるため、上流 ID の全件網羅は対象を限定する(CLAUDE.md §11 の本成果物における適用)。
- 全件網羅の対象:
DOM-COMMON-NFR-*/DOM-COMMON-SEC-*/DOM-COMMON-SEC-DATA-*/DOM-COMMON-REG-*/EXT-*。これらはすべて、いずれかの行の関連 ID 列に少なくとも 1 回現れること。 - 全件網羅の対象外:
FUNC-*/UC-*/ACT-*/DOM-<コード>-*(ドメイン個別)。非機能は原則システム全体に効くため、適用範囲を特定機能・特定ドメイン・特定アクターに限定する行でのみ引く。 - グレード表の全メトリクスが、行として存在するか §対象範囲と対象外メトリクス に対象外として記載されているかのいずれかであること(どちらにも現れないメトリクスを残さない)。
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
ビジネス要件定義書(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策定後、ドメイン共通要求仕様書の作成前に呼び出す。