要件定義スキル
EARS記法(Easy Approach to Requirements Syntax)を用いて、明確でテスト可能な要件定義書を作成します。
概要
このスキルは、以下の成果物を作成・管理します:
- docs/sdd/requirements/index.md: 要件一覧(目次)
- docs/sdd/requirements/stories/US-XXX.md: ユーザーストーリー詳細
- docs/sdd/requirements/nfr/*.md: 非機能要件(カテゴリ別)
ドキュメント構成
docs/sdd/requirements/
├── index.md # 目次・概要・要件サマリ
├── stories/
│ ├── US-001.md # ユーザーストーリー詳細
│ ├── US-002.md
│ └── ...
└── nfr/
├── performance.md # 性能要件
├── security.md # セキュリティ要件
└── usability.md # ユーザビリティ要件
このスキルを使用する場面
新規作成時
- 新規プロジェクトで要件定義書が必要な場合
- ユーザーストーリーを明確に定義したい場合
- テスト可能な受入基準を作成したい場合
- 非機能要件(性能、セキュリティ等)を整理したい場合
既存ドキュメントの修正時
- docs/sdd/requirements/に新しい要件を追加する場合
- 既存の要件をEARS記法に変換・修正する場合
- 要件のレビュー・改善が必要な場合
EARS記法ガイド
基本パターン
| パターン | 形式 | 使用場面 |
|---------|------|----------|
| 基本 | システムは〜しなければならない | 常時適用される要件 |
| イベント | 〜の時、システムは〜しなければならない | イベント駆動要件 |
| 条件 | もし〜ならば、システムは〜しなければならない | 状態依存要件 |
| 継続 | 〜の間、システムは〜しなければならない | 継続的要件 |
| 場所 | 〜において、システムは〜しなければならない | コンテキスト固有要件 |
要件の例
- REQ-001: ユーザーが「カートに追加」をクリックした時、システムは500ms以内に商品を追加しなければならない
- REQ-002: カートが空の場合、システムは「カートは空です」と表示しなければならない
- REQ-003: 決済処理中、システムは進捗インジケーターを表示しなければならない
- NFR-001: システムは性能劣化なしに1000人の同時ユーザーを処理できなければならない
避けるべき表現
| 避けるべき | 推奨 | |-----------|------| | 「〜すべきである」 | 「〜しなければならない」 | | 「〜することが望ましい」 | 「〜しなければならない」 | | 「高速に」「使いやすく」 | 具体的な数値(「2秒以内」「3クリック以内」) | | 複数の「しなければならない」 | 要件を分割 |
実行効率に関する注意
- テンプレートは使用直前に読み込む: 全テンプレートを事前に読み込まない。index.md作成時にindex用テンプレートのみ、ストーリー作成時にストーリー用テンプレートのみ読み込む
- リファレンス(EARS記法ガイド等)は必要時のみ参照: EARS記法に不慣れな場合や判断に迷う場合のみ読み込む
- 作業完了後は速やかに結果を報告: 長時間無応答にならないよう、作成したドキュメントの概要をユーザーに提示する
- 進捗をステップごとに出力する: 各処理ステップの開始時に進捗メッセージを出力する
進捗出力の例
[requirements-defining] ステップ 1/5: 入力要件を読み込み中...
[requirements-defining] ステップ 2/5: 情報を分類中(明示/不明)...
[requirements-defining] ステップ 3/5: EARS記法で要件を生成中...
[requirements-defining] ステップ 4/5: ユーザーストーリーを作成中...
[requirements-defining] ステップ 5/5: index.mdを作成中...
[requirements-defining] 完了: 5ファイル作成
情報分類の段階的処理
長文の要件説明を受け取った場合、一括分類を避け段階的に処理する:
- Phase 1: 必須情報のみ確認(プロジェクト名、目的、対象ユーザー)→ 不明点があればここで質問
- Phase 2: 機能要件の整理 → ユーザーストーリー作成
- Phase 3: 非機能要件の整理 → NFRドキュメント作成
ワークフロー
新規作成フロー
- 情報収集: プロジェクトの目的、対象ユーザー、主要機能を確認
- ディレクトリ作成:
docs/sdd/requirements/stories/とdocs/sdd/requirements/nfr/を作成 - index.md作成: 目次テンプレートを使用して概要を記述
- ユーザーストーリー作成: 各ストーリーを
stories/US-XXX.mdとして作成 - 非機能要件作成: カテゴリ別に
nfr/*.mdを作成 - index.md更新: 作成した各ドキュメントへのリンクを追加
- レビュー: チェックリストで品質確認
- ユーザー確認: 承認を得て完了
ストーリー追加フロー
- 新規ファイル作成:
stories/US-XXX.mdを作成 - EARS記法で要件定義: ユーザーストーリーテンプレートに従う
- index.md更新: ストーリー一覧テーブルにリンクを追加
- 関連ドキュメント更新: 関連する既存ストーリーに相互リンクを追加
検証チェックリスト
- [ ] ユーザーストーリーが明確に定義されている
- [ ] すべての要件がEARS記法に従っている
- [ ] 要件IDが一意である(REQ-XXX、NFR-XXX)
- [ ] 各要件がテスト可能である
- [ ] 非機能要件が含まれている
- [ ] 曖昧な表現が排除されている
ユーザーとの対話ガイドライン
情報分類プロセス
ユーザーの指示を受け取ったら、まず以下を分類:
明示された情報:
- ユーザーが明確に述べた要件、仕様、制約
不明な情報:
- ユーザーが言及していないが、要件定義に必要な情報
- 「おそらく〜だろう」と推測が必要な項目
確認が必要な場面
- プロジェクトの種類や目的
- 対象ユーザー
- 主要な機能
- 非機能要件の具体的な値(性能、セキュリティなど)
- ユーザーストーリーの優先順位
確認の形式
要件定義の前に、以下の点を確認させてください:
【明示された情報】
- [ユーザーから明示的に指定された内容]
【不明/要確認の情報】
1. [項目1]: [選択肢A] / [選択肢B] / その他
2. [項目2]: [具体的な質問]
上記の不明点について教えていただけますか?
後続スキルとの連携
docs/sdd/requirements/の作成完了後:
- software-designing: docs/sdd/requirements/を基に技術設計を行う
- task-planning: 要件に基づきタスクを分解
後続スキルで整合性の確認が行われます。
リソース
テンプレート
- 目次テンプレート:
assets/templates/requirements_index_template_ja.md - ユーザーストーリーテンプレート:
assets/templates/user_story_template_ja.md - 非機能要件テンプレート:
assets/templates/nfr_template_ja.md
リファレンス
- EARS記法リファレンス:
references/ears_notation_ja.md
命名規則
| ファイル種別 | 命名規則 | 例 |
|-------------|---------|-----|
| ユーザーストーリー | US-XXX.md | US-001.md, US-002.md |
| 性能要件 | performance.md | - |
| セキュリティ要件 | security.md | - |
| ユーザビリティ要件 | usability.md | - |
| 可用性要件 | availability.md | - |
| 保守性要件 | maintainability.md | - |
リンク形式
index.mdから個別ファイルへのリンクは、マークダウン形式と@形式の両方を記載:
| US-001 | タイトル | 高 | 承認済 | [詳細](stories/US-001.md) @stories/US-001.md |
- マークダウン形式:
[詳細](stories/US-001.md)- GitHub等での閲覧用 - @形式:
@stories/US-001.md- Claude Codeがファイルを参照する際に使用