feature-requirements

要件

概要

要件の発見、実用的なスコープ設定、明確で実用的な表現による統合要件ドキュメントの作成を順に進めることで、要件ドキュメントの作成を支援する構造化されたコマンドです。

確立された機能開発プロセスに従って、要件ドキュメントを作成します。まず、@~/.local/share/dotfiles/ai/guides/feature-development-process.md にある機能開発ガイドと、@vision.md にあるビジョンドキュメントを読み、機能のスコープとドキュメントの進め方を把握してください。

注：プロジェクトに @project/guides/feature-development-process.md にあるガイドのローカルコピーがある場合は、プロジェクト固有の変更を反映したそのガイドを参照してもかまいません。

重要：最初に、要件作成の3フェーズを管理するためのTODOリストを作成してください。最初のフェーズを「in_progress」、残りのフェーズを「pending」に設定してください。

要件ドキュメントの構成

単一の統合ドキュメント（requirements.md）には、以下を含めます。

ユーザーストーリーとビジネスニーズ：

• 役割ごとに整理されたユーザーストーリー
• ビジネス機能とユーザーワークフロー
• システムが提供しなければならない中核的な機能

ビジネスデータとルール：

• ビジネスエンティティとデータ要件（エンティティ、関係、ビジネスレベルの属性と制約）
• システムの動作を規定するビジネスロジックとルール
• ユーザーエクスペリエンス要件

品質特性と制約：

• パフォーマンス、セキュリティ、信頼性、スケーラビリティの要件
• コンプライアンスとプライバシーの制御
• 技術的な制約と制限

統合と成功：

• 既存システムとの統合ポイント
• 開発およびテストのアプローチ
• 成功基準と受け入れ基準
• 制約と前提条件

要件の識別形式

仕様、計画、議論で簡単に相互参照できるよう、すべての要件に体系的なIDプレフィックスを使用してください。

プレフィックス	用途	番号付け
US-X.X.X	ユーザーストーリー	セクション.サブセクション.項目
REQ-X.X.X	要件	セクション.サブセクション.項目
SC-X	成功基準	連番

形式の例：

**US-1.1.1**: As a staff member, I want to view custom field data...

**REQ-2.1.1**: The system must render form controls dynamically based on...

**SC-1**: Staff can view custom field values on detail pages.

番号付けルール：

• 番号はドキュメントのセクション階層に従います（セクション2.1 → REQ-2.1.x）
• セクション1.1のユーザーストーリーには、US-1.1.1、US-1.1.2などを使用します
• セクション3.2の要件には、REQ-3.2.1、REQ-3.2.2などを使用します
• 成功基準には、SC-1からSC-Nまでの単純な連番を使用します

考慮すべき既存システムのパターン

要件を収集する際は、既存のシステム機能を適用できるか確認してください。

• 検索：全文検索機能
• ファイル添付：ドキュメント／ファイルのアップロードと管理
• 監査証跡：変更の追跡と履歴
• マルチテナント：組織／テナントごとのデータ分離
• 権限：ロールベースのアクセス制御
• タグ付け：分類およびカテゴリ分けシステム
• カスタムフィールド：拡張可能なデータフィールド

早い段階で、次のように質問してください。「これらの既存機能のうち、この機能に適用できるものはどれですか？」

プロセス：以下の3つのフェーズを順番に進めます

フェーズ 1：要件の把握

要件をすべて洗い出すため、焦点を絞った質問をします（この段階では分類しません）。

• システムにはどのような具体的な機能が必要ですか？
• 管理する必要があるビジネスエンティティ（主要な概念、関係性、ビジネスレベルの属性）は何ですか？
• 保存する必要があるデータと、ビジネス上の制約は何ですか？
• どのようなビジネスルールを適用する必要がありますか？
• 利用者にはどのような人々がいますか（スタッフ、会員、一般の人々、管理者など）？
• 利用者ごとに要件はどのように異なりますか？
• 各利用者は何を閲覧し、何を実行できる必要がありますか？
• ユーザーはシステムをどのように利用しますか？
• データがない場合はどうなりますか？（スタッフ向けと会員向けの空の状態）
• データはどのように表示しますか？（フィード形式、テーブル、カードなど）
• どのようにすれば、技術的な習熟度にかかわらず、誰もがこの機能を使いやすくなりますか？
• セキュリティと権限に関する要件は何ですか？
• どのようなパフォーマンスが求められますか？
• 既存のシステムとの連携は必要ですか？
• 適用されるコンプライアンス要件やプライバシー要件はありますか？

質問は一度に 1 つだけ — 次に進む前に回答を待ちます。

フェーズ 2：実用性の重視と将来計画

洗い出した各要件について、次の点を質問します。

• 現在のスコープですぐに実現できますか？
• 現在の要件に含めるべきですか、それとも後のフェーズに向けて future.md に記載すべきですか？
• 明確で簡潔な言葉で表現できますか？
• 現在のフェーズに適切な範囲ですか？
• テスト可能で、測定可能ですか？

次の要件については、future.md を作成します。

• すばらしいアイデアですが、現在のスコープを超えているもの
• フェーズ 2／3 での実装が必要な複雑な機能
• 将来の検討に向けて残しておく価値のあるアイデア
• 初期の基盤を土台として拡張する高度な機能

現在の要件に含めるのは、次のものだけです。

• すぐに実現可能なもの
• 中核機能に不可欠なもの
• 明確で簡潔な言葉で記述されているもの

フェーズ 3：ドキュメントの作成

• 上記の要件識別形式に従って、すべてのユーザーストーリー（US-）、要件（REQ-）、成功基準（SC-）に ID プレフィックスを付けます
• 次の構成で、要件をまとめた単一の requirements.md ドキュメントを作成します：
  1. ユーザーストーリーとビジネスニーズ - 明確なビジネス機能を示し、役割ごとに整理
  2. システムの中核機能 - システムがユーザーに提供すべきもの
  3. ビジネスデータ要件 - エンティティ、関係性、ビジネスレベルの属性
  4. ビジネスルールとロジック - 動作を規定するルールと制約
  5. ユーザーエクスペリエンス要件 - システムがどのような操作感で、どのように動作すべきか
  6. 品質特性と制約 - パフォーマンス、セキュリティ、信頼性、スケーラビリティ
  7. 統合ポイント - 既存システムとの接続
  8. 開発およびテストのアプローチ - システムの構築と検証方法
  9. 成功基準 - 明確な受け入れ基準と成功の定義
  10. 制約と前提条件 - スコープの境界と基本的な前提
• 後回しにする要件について、ユーザーストーリーと技術フェーズごとに整理した future.md を作成します
• discussion-summary.md を更新または作成します：
  • フィーチャーディレクトリに discussion-summary.md があるか確認します
  • ある場合：「要件フェーズ」セクションを追加し、次の内容を含めます：
    • 要件フェーズでの技術的な議論と調査
    • 「ビジョンでの未解決事項の解決」サブセクション（未解決だった内容とその解決方法を示す表）
    • ビジョンフェーズから番号を続けて、新たな決定事項を決定ログに追加
    • 新たに参照したファイルを技術コンテキストに追加
  • ない場合：ビジョンフェーズのプレースホルダーを含む完全な構成で作成します
• すべてのドキュメントに適切なリンク付きの目次を含めます
• 正確な相互参照のため、体系的なセクション番号（1.1、1.2、2.1、2.2 など）を付けます
• ビジネスコンテキストについてはビジョンドキュメントを相互参照します
• 全体を通して、明確で実用的な表現を使用します
• フィーチャー開発プロセスの正確な構成に従います
• アーキテクチャに関する重要な決定（別ページにするかモーダルにするか、フィードにするかテーブルにするかなど）を記録する際は、その理由（リンク可能性、パフォーマンス、UX など）も記載します

ガイドライン

• 一度に質問するのは 1 つだけとし、回答を待ちます
• 各フェーズを完了したら TODO リストを更新します
• 企業向けの堅苦しい表現ではなく、明快で会話的な言葉遣いにします
• すぐに役立つ要件に焦点を当て、過剰な設計は避けます
• チーム全体に役立つ、論理的で読みやすい構成に要件を整理します
• ビジョンドキュメントとフィーチャー開発プロセスを参照します
• 実用性を保ち、読みやすく実行可能なドキュメントを作成します
• 要件レベルにとどめる：実装方法ではなく、何を、なぜ行うかに焦点を当てます
  • 良い例：「システムはイベントが下書きか公開済みかを追跡しなければならない」
  • 避ける例：「is_draft フィールドにブール値フラグを使用する」
  • 良い例：「イベントは 1 つの組織に属する」
  • 避ける例：「organization_id 外部キーを含める」
  • データ型、テーブル構造、フィールド名などの技術的な実装詳細は、仕様フェーズまで保留します
• 反復を前提とする：ユーザーが影響を検討するにつれて、要件が洗練されることはよくあります。これは正常で望ましいことです。新たな知見に基づいて要件を更新できるようにしてください
• 要件が大幅に変更された場合（任意から必須へ、機能の追加や削除など）、関連するすべてのセクションを一貫して更新します

開始手順

1. 3 フェーズの TODO リストをすぐに作成します
2. ユーザーに質問します：「作業しているフィーチャーディレクトリはどこですか？フルパスを指定してください（例：project/features/FT033-feature-name）」
3. ユーザーに質問します：「フィーチャーのスコープを把握できるよう、ビジョンドキュメントに @vision.md のタグを付けてください」
4. ディレクトリの存在を確認し、要件ドキュメントを作成する場所を確認します
5. フィーチャーの背景を把握するため、ビジョンドキュメントを確認します
6. 最初の要件発見の質問からフェーズ 1 を開始します
7. 質問は焦点を絞り、次の質問に進む前に回答を待ちます