# Requirements Defining

> EARS記法を用いた要件定義書（requirements.md）を作成・編集します。ユーザーストーリーの作成、受入基準の定義、非機能要件の整理が必要な場合に使用してください。

- Skill: `majiayu000/requirements-defining-2` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/requirements-defining-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/requirements-defining-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/requirements-defining-2

---


# 要件定義スキル

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

## 概要

このスキルは、以下の成果物を作成・管理します：
- **docs/requirements.md**: ユーザーストーリーと受入基準（EARS記法）

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

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

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

## EARS記法ガイド

### 基本パターン

| パターン | 形式 | 使用場面 |
|---------|------|----------|
| 基本 | `システムは〜しなければならない` | 常時適用される要件 |
| イベント | `〜の時、システムは〜しなければならない` | イベント駆動要件 |
| 条件 | `もし〜ならば、システムは〜しなければならない` | 状態依存要件 |
| 継続 | `〜の間、システムは〜しなければならない` | 継続的要件 |
| 場所 | `〜において、システムは〜しなければならない` | コンテキスト固有要件 |

### 要件の例

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

### 避けるべき表現

| 避けるべき | 推奨 |
|-----------|------|
| 「〜すべきである」 | 「〜しなければならない」 |
| 「〜することが望ましい」 | 「〜しなければならない」 |
| 「高速に」「使いやすく」 | 具体的な数値（「2秒以内」「3クリック以内」） |
| 複数の「しなければならない」 | 要件を分割 |

## ドキュメント構造

```markdown
# 要件定義

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

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

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

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

## ワークフロー

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

## 検証チェックリスト

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

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

### 情報分類プロセス

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

**明示された情報**:
- ユーザーが明確に述べた要件、仕様、制約

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

### 確認が必要な場面

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

### 確認の形式

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

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

【不明/要確認の情報】
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`