8.0 KiB
8.0 KiB
argument-hint, description, allowed-tools
| argument-hint | description | allowed-tools | ||||
|---|---|---|---|---|---|---|
| <タスク名> | 機能要件と非機能要件の詳細仕様を作成 |
|
詳細要件仕様書を作成します
タスクの機能要件と非機能要件を詳細化し、specification.md を生成します。
【対象タスク名】 $ARGUMENTS
実行手順
0. ステアリングドキュメントの読み込み
以下のステアリングドキュメントを読み込み、プロジェクトのコンテキストを把握：
specs/_steering/product.md- プロダクト方針、ビジネス目標specs/_steering/tech.md- 技術標準specs/_steering/structure.md- プロジェクト構造
ステアリングドキュメントが存在しない場合:
- 警告メッセージを表示: 「⚠️ ステアリングドキュメントが見つかりません。先に
/sdd:steeringを実行することを推奨します。」
1. タスクディレクトリの確認
タスク名が指定されている場合:
specs/[taskname]/ディレクトリの存在を確認specs/[taskname]/overview.mdが存在するか確認
タスク名が指定されていない場合:
specs/ディレクトリ内の利用可能なタスクをリスト表示- AskUserQuestionツールを使用してどのタスクについて作業するかユーザーに選択を求める
2. 既存ドキュメントの読み込み
以下のドキュメントを読み込み、要件定義に必要な情報を抽出：
specs/[taskname]/overview.md- プロジェクト概要、主要機能specs/_steering/product.md- プロダクトの Non-Goals、Business Objectivesspecs/_steering/tech.md- 技術的制約
3. 非機能要件の確認
以下の非機能要件について、ユーザーに必要かどうかを確認してください：
AskUserQuestionツールを使用して、以下を確認：
以下の非機能要件について、このタスクで必要なものを選択してください（複数選択可）：
□ パフォーマンス要件（レスポンスタイム、同時接続数、データ処理量など）
□ 可用性要件（稼働率目標、ダウンタイム許容範囲、障害復旧時間など）
□ 保守性要件（コード品質基準、ドキュメント要件、技術的負債の管理など）
□ ユーザビリティ要件（UI/UX要件、アクセシビリティ、多言語対応など）
□ 制約条件（技術的制約、ビジネス的制約、法的・規制上の制約など）
□ テスト戦略（テストの種類、カバレッジ目標など）
□ 開発環境（必要なツール、セットアップ手順など）
注: セキュリティ要件は常に含まれます
4. specification.mdの生成
specs/[taskname]/specification.md を生成：
# 詳細仕様書
## 機能要件
[overview.mdの主要機能を詳細化]
### 機能1: [機能名]
- **概要**: [1-2行で機能を説明]
- **優先度**: High/Medium/Low
- **実装Phase**: Phase N（plan-phasesで決定後に追加）
- **入出力定義**:
- **入力**:
- パラメータ名: 型、説明
- パラメータ名: 型、説明
- **出力**:
- レスポンス形式
- 成功時の戻り値
- エラー時の戻り値
- **制約・注意事項**（必要な場合のみ）:
- [制約事項や注意点]
### 機能2: [機能名]
...
## 非機能要件
### セキュリティ（必須）
- **認証・認可要件**: [steering/tech.mdから関連する標準を参照]
- **データ暗号化**: [要件]
- **監査ログ**: [要件]
- **セキュリティ標準**: [steering/tech.mdのセキュリティ要件を参照]
[ユーザーが選択した非機能要件のみ以下に含める]
### パフォーマンス（選択時のみ）
- **レスポンスタイム要件**: [具体的な数値]
- **同時接続数**: [具体的な数値]
- **データ処理量**: [具体的な数値]
- **スループット目標**: [具体的な数値]
### 可用性（選択時のみ）
- **稼働率目標**: [例: 99.9%]
- **ダウンタイム許容範囲**: [例: 月間43分以内]
- **障害復旧時間**: [RTO/RPO]
- **監視要件**: [監視項目]
### 保守性（選択時のみ）
- **コード品質基準**: [steering/tech.mdの品質標準を参照]
- **ドキュメント要件**: [要求されるドキュメント]
- **技術的負債の管理**: [方針]
- **リファクタリング方針**: [方針]
### ユーザビリティ（選択時のみ）
- **UI/UX要件**: [要件]
- **アクセシビリティ**: [WCAG準拠レベルなど]
- **多言語対応**: [対応言語]
- **レスポンシブデザイン**: [対応デバイス]
## データ要件
### データモデル概要
[主要なデータエンティティとその関係]
### データ保持期間
[データ種別ごとの保持期間]
### データ移行要件
[既存データからの移行が必要な場合]
## インターフェース要件
### 外部システム連携
[連携する外部システム]
### API仕様概要
[APIの概要、詳細はtechnical-details.mdで定義]
### データフォーマット
[JSON, XML, CSVなど]
## 制約条件（選択時のみ）
### 技術的制約
[steering/tech.mdから関連する制約を参照]
### ビジネス的制約
[steering/product.mdから関連する制約を参照]
### 法的・規制上の制約
[GDPR, 個人情報保護法など]
生成時の注意点:
- ⚠️ 重要: 詳細であれば詳細であるほど良いわけではない。必要な部分だけを必要なだけ書くこと
- ⚠️ 重要: 推測される開発期間、工数、見積もり時間などは一切記載しないこと
- ⚠️ 重要: 「将来的に必要になる」「今後〜が必要」といった適当な推測に基づいた記述は禁止
- 不明なところは勝手に決めずに「不明」と明記し、複数の案（案A、案B、案Cなど）を記述すること
- ステアリングドキュメントの情報を積極的に参照・活用すること
- 実装Phase番号は空欄にする（plan-phasesで決定後に追加）
5. 完了報告
✅ 詳細要件仕様書を作成しました
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📍 作成先: specs/[taskname]/specification.md
📝 機能要件: [N]件
💡 次のアクション:
- 技術詳細化: `/sdd:define-technical [taskname]`
- 不明点の明確化: `/sdd:clarify-spec [taskname]`
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
注意事項
- ⚠️ 重要: ステアリングドキュメントを必ず参照し、プロジェクトの方針や標準に準拠すること
- 不明なところは勝手に決めずに「不明」と明記すること
- ユーザーが選択しなかった非機能要件セクションは含めないこと
- specification.mdは機能要件の詳細を記述する場所（技術実装の詳細はtechnical-details.mdで記述）
内部品質チェック
重要: 以下のチェックはコマンド内部で実施し、生成されるspecファイルには結果を記載しません。
ステアリングドキュメントレビュー（内部処理）
ドキュメント生成後、内部的にステアリングドキュメントとの整合性を確認：
- product.mdのビジネス目標・ターゲットユーザーとの整合性
- tech.mdのセキュリティ要件との整合性
- structure.mdのプロジェクト構造との整合性
問題がある場合のみユーザーに修正を促す。準拠している場合は何も出力しない。
矛盾チェック（内部処理）
ドキュメント生成後、内部的に仕様書間の矛盾を確認：
- overview.mdとspecification.mdの機能定義の整合性
- データ要件と機能要件の整合性
矛盾がある場合のみユーザーに警告を表示。問題がなければ何も出力しない。