rdd

name	rdd
description	EARS記法を用いた要件定義書を作成するスキル。要件定義書の作成のみを行い、実装計画や実装は含まない。以下の場合に使用:(1)機能追加や改修の要件を明確化したい時、(2)受け入れ条件やエッジケースを整理したい時
disable-model-invocation	true

EARS記法 要件定義書作成スキル

このスキルは、EARS記法（Easy Approach to Requirements Syntax）を用いて、明確で検証可能な要件定義書を作成します。

このスキルのスコープ

含まれるもの

• ✅ 要件の対話的なヒアリングと整理
• ✅ EARS記法を用いた要件定義書の作成
• ✅ 受け入れ条件とエッジケースの文書化

含まれないもの

• ❌ 実装計画・方針、設計の作成
• ❌ 実際の実装作業
• ❌ コード生成

このスキルは要件定義書の出力で完了します。 設計や実装に進む場合は、作成された要件定義書を基に別途実装を依頼してください。

EARS記法の概要

EARS記法は、6つのパターンで要件を記述する構造化手法です：

詳細パターンとサンプルは references/ears-patterns.md を参照してください。

実行フロー

Phase 0: コードベース分析（オプション）

コードベースに関連する要件（機能改修・新機能追加）の場合:

1. 分析対象の特定

   • ユーザーが言及した機能名やファイルパス
   • 関連しそうなディレクトリやモジュール

2. サブエージェントでコードベース分析を実行

   • model: claude sonnet or codex high or gemini pro
   • 分析内容:
     • 対象機能の既存実装パターン
     • 関連するインターフェース・依存関係
     • エラーハンドリングの既存パターン
     • テストの存在と構造

3. 分析結果を活用

   • Phase 1 のヒアリングで具体的な提案に活用
   • 既存の実装パターンに沿った受け入れ条件を提案
   • 既存コードから推測されるエッジケースを提示

Phase 1: 対話的確認

必須質問（以下の2つは必ず聞く）:

1. 受け入れ条件の確認

   • 「受け入れ条件は、次の案で問題ないですか？（必要なら追加・修正してください）」
     • 例: 「主要なユーザー操作が期待通り完了し、画面/通知に成功が明示される」
     • 例: 「不正な入力は拒否され、理由が表示される」
   • ユーザーの視点から見た成功基準を明確化

2. エッジケース・異常系の確認

   • 「想定すべき異常系は、次の案で十分ですか？（不足があれば追加してください）」
     • 例: ネットワーク断/タイムアウト
     • 例: 無効な入力/境界値
     • 例: 権限不足
     • 例: 同時実行/競合
   • 代表的な異常系を先に提示して補完を依頼

追加質問（必要に応じて）:

• 前提条件（WHILEパターン用）:
  • 「前提条件は、次の案で正しいですか？（追加・修正してください）」
    • 例: ログイン済み、対象データが存在
• トリガーイベント（WHENパターン用）:
  • 「トリガーは、次の案で正しいですか？（追加・修正してください）」
    • 例: ボタン押下、API呼び出し、スケジュール
• エラー処理（IFパターン用）:
  • 「エラー時の動作は、次の案で正しいですか？（追加・修正してください）」
    • 例: エラーメッセージ表示、リトライ、ロールバック
• オプション機能（WHEREパターン用）:
  • 「特定条件下でのみ有効な機能は、次の案で正しいですか？（追加・修正してください）」
    • 例: 権限、設定、フィーチャーフラグ
• 非機能要件（該当する場合）:
  • 「非機能要件は、次の案で問題ないですか？（追加・修正してください）」
    • 例: レスポンスタイム、可用性、監査ログ、暗号化

締めくくり:

• 「他に考慮すべきケースや懸念事項はありますか？」

Phase 2: 要件の整理

対話で得た情報をEARSパターンに分類します：

1. 基本動作 → Ubiquitous
2. イベント駆動 → Event-driven (WHEN)
3. 状態依存 → State-driven (WHILE)
4. オプション機能 → Optional (WHERE)
5. エラー・例外処理 → Unwanted (IF...THEN)
6. 複雑な組み合わせ → Complex

Phase 3: 要件定義書の生成

assets/requirements-template.md をベースに、以下の構成で要件定義書を生成します：

1. 概要

   • 目的
   • 対象システム
   • スコープ

2. 機能要件（EARSパターン別にセクション分け）

   • Ubiquitous要件
   • Event-driven要件
   • State-driven要件
   • Optional要件
   • Unwanted要件

3. 受け入れ条件

   • 機能が正しく動作したと判断できる条件

4. エッジケース・境界条件

   • 異常系シナリオ
   • 境界値テストケース

5. 非機能要件（該当する場合）

   • パフォーマンス
   • セキュリティ
   • 可用性など

Phase 4: 要件品質レビュー（オプション）

生成した要件定義書の品質を客観的にチェック:

1. サブエージェントで品質レビューを実行

   • model: claude haiku or gpt mini high or gemini flash
   • レビュー観点:
     • EARS記法への準拠（references/ears-patterns.md 参照）
     • 曖昧な表現の検出
     • 検証可能性の確認
     • 要件間の矛盾チェック
     • 1要件1責務の原則

2. レビュー結果に基づく修正

   • 問題があればユーザーに報告
   • 修正案を提示

要件記述のガイドライン

良い要件の特徴

• ✅ 明確: 曖昧さがなく、1つの解釈しかできない
• ✅ 検証可能: テストで確認できる
• ✅ 簡潔: 1つの要件に1つの責務
• ✅ 一貫性: 他の要件と矛盾しない
• ✅ 必要性: 実現すべき価値が明確

避けるべき表現

• ❌ 曖昧な表現: "適切に"、"十分に"、"なるべく"
• ❌ 実装詳細: "配列を使って"、"ループで処理"
• ❌ 複数の要件の混在: "AかつBかつC"は分割する

WHEN vs WHILE の使い分け

• WHEN: 一時的なイベント・トリガー（ボタン押下、メッセージ受信）
• WHILE: 継続的な状態（ログイン中、接続中、処理中）

詳細は references/ears-patterns.md を参照してください。

出力仕様

• ファイル名: <機能名-kebab-case>-requirements.md
• 出力先: カレントディレクトリ
• 言語: 日本語（EARSキーワードは英語のまま）
• フォーマット: Markdown

リファレンス

• references/ears-patterns.md
• assets/requirements-template.md

使用例

ユーザー: ログイン機能の要件定義書をEARS記法で作成したい
Claude: [Phase 1-3の対話的プロセスを実行]
出力: login-requirements.md

---

実行手順:

1. Phase 0: コードベース分析（該当する場合）
2. Phase 1: 必須質問を実行
3. Phase 2: 追加質問で詳細を確認し、要件を整理
4. Phase 3: 要件定義書を生成
5. Phase 4: 品質レビュー（オプション）

スキル完了後:

• 要件定義書がカレントディレクトリに出力されます
• 設計や実装に進む場合は、作成された要件定義書を基に実装を依頼してください