Requirements Defining

要件定義スキル

EARS記法（Easy Approach to Requirements Syntax）を用いて、明確でテスト可能な要件定義書を作成します。

概要

このスキルは、以下の成果物を作成・管理します：

• docs/requirements.md: ユーザーストーリーと受入基準（EARS記法）

このスキルを使用する場面

新規作成時

• 新規プロジェクトで要件定義書が必要な場合
• ユーザーストーリーを明確に定義したい場合
• テスト可能な受入基準を作成したい場合
• 非機能要件（性能、セキュリティ等）を整理したい場合

既存ドキュメントの修正時

• docs/requirements.mdに新しい要件を追加する場合
• 既存の要件をEARS記法に変換・修正する場合
• 要件のレビュー・改善が必要な場合

EARS記法ガイド

基本パターン

要件の例

- REQ-001: ユーザーが「カートに追加」をクリックした時、システムは500ms以内に商品を追加しなければならない
- REQ-002: カートが空の場合、システムは「カートは空です」と表示しなければならない
- REQ-003: 決済処理中、システムは進捗インジケーターを表示しなければならない
- NFR-001: システムは性能劣化なしに1000人の同時ユーザーを処理できなければならない

避けるべき表現

ドキュメント構造

# 要件定義

## 概要
[機能/システムの高レベルの目的と目標を記載]

## ユーザーストーリー
### ストーリー1: [タイトル]
**私は** [ユーザータイプ]として
**〜したい** [目標]
**なぜなら** [価値/利点]

#### 受入基準（EARS記法）
- REQ-001: [イベント]の時、システムは[振る舞い]しなければならない
- REQ-002: もし[条件]ならば、システムは[振る舞い]しなければならない

## 非機能要件
- NFR-001: システムは[性能/セキュリティ/ユーザビリティ要件]を満たさなければならない

ワークフロー

1. 情報収集: プロジェクトの目的、対象ユーザー、主要機能を確認
2. ユーザーストーリー作成: 「私は〜として、〜したい、なぜなら〜」形式で記述
3. 受入基準定義: EARS記法で各ストーリーの受入基準を作成
4. 非機能要件整理: 性能、セキュリティ、ユーザビリティ要件を追加
5. レビュー: チェックリストで品質確認
6. ユーザー確認: 承認を得て完了

検証チェックリスト

• ユーザーストーリーが明確に定義されている
• すべての要件がEARS記法に従っている
• 要件IDが一意である（REQ-XXX、NFR-XXX）
• 各要件がテスト可能である
• 非機能要件が含まれている
• 曖昧な表現が排除されている

ユーザーとの対話ガイドライン

情報分類プロセス

ユーザーの指示を受け取ったら、まず以下を分類：

明示された情報:

• ユーザーが明確に述べた要件、仕様、制約

不明な情報:

• ユーザーが言及していないが、要件定義に必要な情報
• 「おそらく〜だろう」と推測が必要な項目

確認が必要な場面

• プロジェクトの種類や目的
• 対象ユーザー
• 主要な機能
• 非機能要件の具体的な値（性能、セキュリティなど）
• ユーザーストーリーの優先順位

確認の形式

要件定義の前に、以下の点を確認させてください：

【明示された情報】
- [ユーザーから明示的に指定された内容]

【不明/要確認の情報】
1. [項目1]: [選択肢A] / [選択肢B] / その他
2. [項目2]: [具体的な質問]

上記の不明点について教えていただけますか？

後続スキルとの連携

requirements.mdの作成完了後：

• software-designing: requirements.mdを基に技術設計を行う
• task-planning: 要件に基づきタスクを分解

後続スキルで整合性の確認が行われます。

リソース

• テンプレート: assets/templates/requirements_template_ja.md
• EARS記法リファレンス: references/ears_notation_ja.md