requirements

要件

ルートの REQUIREMENTS.md を作成または更新してください。製品の概要、製品の機能、主な機能を記述してください。長期にわたって更新する製品ドキュメントとして維持してください。 1つの機能には /spec を、システムの技術的な決定には /architecture を使用してください。

プロセス

1. 依頼、リポジトリの指示、既存の要件、関連する根拠を確認します。すでに決定されている内容を再利用してください。
2. ユーザー、課題、望ましい結果、対象範囲、制約を特定します。明示されたニーズと仮定を分けてください。事実を把握するためにリポジトリを調べ、結果を左右する製品上の決定に必要な情報が不足している場合はユーザーに確認してください。
3. 以下の構成に沿って要件を記述します。各要件に一意で安定した REQ-n ID を付けてください。既存の ID を再利用したり、番号を振り直したりしないでください。
4. 要件間に矛盾がないこと、関連する失敗時の動作が網羅されていること、テスト可能であることを確認します。未解決の決定事項と、それがアーキテクチャやデリバリーを妨げるかどうかを記録してください。
5. 人によるレビューができる状態でドキュメントの作成を終えます。実装の設計、タスクの計画、コードの作成は行わないでください。

ドキュメントの構成

• 目的とユーザー： 課題、それを抱えているユーザー、必要としている成果。
• ユーザージャーニー： 複数の機能を連携させる必要がある場合、課題から望ましい結果に至る現実的な流れを示します。
• 根拠と仮定： 課題を裏付ける、提供された調査、フィードバック、既存の動作へのリンクを記載します。根拠を捏造しないでください。重要な仮定にはラベルを付け、検証方法を記載します。
• 主な機能と対象範囲： 主な機能、その価値、明示的な対象外事項。
• 要件： 観測可能な動作、ビジネスルール、権限、ユーザーに表示される失敗と復旧の動作。必要に応じてドメインの概念を定義します。
• 制約： 必要な互換性、セキュリティ、プライバシー、運用、パフォーマンスの制限。判明している場合は測定可能な基準を使用し、未確定の目標は未決事項として示します。
• 受け入れ基準： システムの機能に関する観測可能な条件。詳細な機能シナリオや確認項目は、その仕様書に記載してください。
• 成功指標： 指標を裏付ける根拠がある場合、デリバリー後に価値を判断する方法。実装の受け入れ基準とは分けてください。
• 未決事項： 不足している回答ごとに、妥当な場合は推奨する既定値と、今後の作業への影響を記載します。

この製品の定義に役立つセクションのみを使用してください。関連する項目はまとめ、有益な情報を加えないセクションは省略してください。

製品、主な機能、対象範囲、ビジネスルールが変わったときは、このドキュメントを更新してください。最新の状態に保ち、機能に関する決定の履歴は仕様書に残してください。機能の実装詳細は仕様書に記載してください。

要件に実装の選択肢を含めないでください。指定された技術は、制約として明示されている場合にのみ記載してください。ユーザー調査、目標、ビジネスルールを捏造しないでください。

返答

パス、行った決定、ブロッキングとなる質問を報告してください。