# Requirements Defining

> 【非推奨】requirement-management に統合された。新規の要件定義には requirement-management を使用すること。既存の docs/sdd/requirements/ を保守・参照する場合にのみ使用する。EARS記法によるMarkdownの要件定義書（ユーザーストーリー・受入基準・非機能要件）を作成・編集する。Do NOT use for 新規プロジェクトの要件定義（requirement-management を使用すること）。

- Skill: `windschord/requirements-defining` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add windschord/requirements-defining`
- Raw SKILL.md: https://api.skillmd.com/api/skills/windschord/requirements-defining/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: windschord (https://skillmd.com/u/windschord)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/windschord/requirements-defining

---


# 要件定義スキル（非推奨）

> **⚠️ このスキルは非推奨です。**
>
> 要件定義の機能は `requirement-management` に統合されました。要求の矛盾・欠落を機械検証できる同スキルを新規利用では使用してください。
>
> | | 非推奨（本スキル） | 移行先 |
> |---|---|---|
> | 保存形式 | Markdown（`docs/sdd/requirements/`） | YAML（`docs/requirements/`） |
> | 整合性チェック | 人手のレビュー | `reqctl.py validate` による機械検証 |
> | 理由の記録 | 任意 | 必須（`rationale.why`） |
> | 検証手段 | 受入基準の文章 | テストIDへの紐付け（`verification`） |
>
> 移行手順は `sdd/requirement-management/references/migration_from_sdd_ja.md` を参照してください。
> 既存の `docs/sdd/requirements/` を保守・参照する場合にのみ、以下の手順を使用します。

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

## 概要

このスキルは、以下の成果物を作成・管理します：
- **docs/sdd/requirements/index.md**: 要件一覧（目次）
- **docs/sdd/requirements/stories/US-XXX.md**: ユーザーストーリー詳細
- **docs/sdd/requirements/nfr/*.md**: 非機能要件（カテゴリ別）

## ドキュメント構成

```text
docs/sdd/requirements/
├── index.md                 # 目次・概要・要件サマリ
├── stories/
│   ├── US-001.md           # ユーザーストーリー詳細
│   ├── US-002.md
│   └── ...
└── nfr/
    ├── performance.md      # 性能要件
    ├── security.md         # セキュリティ要件
    └── usability.md        # ユーザビリティ要件
```

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

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

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

EARS記法の詳細は `references/ears_notation_ja.md` を参照。

## ワークフロー

### 新規作成フロー

1. **情報収集**: プロジェクトの目的、対象ユーザー、主要機能を確認
2. **ディレクトリ作成**: `docs/sdd/requirements/stories/` と `docs/sdd/requirements/nfr/` を作成
3. **index.md作成**: 目次テンプレートを使用して概要を記述
4. **ユーザーストーリー作成**: 各ストーリーを `stories/US-XXX.md` として作成
5. **非機能要件作成**: カテゴリ別に `nfr/*.md` を作成
6. **index.md更新**: 作成した各ドキュメントへのリンクを追加
7. **レビュー**: チェックリストで品質確認
8. **ユーザー確認**: 承認を得て完了

### ストーリー追加フロー

1. **新規ファイル作成**: `stories/US-XXX.md` を作成
2. **EARS記法で要件定義**: ユーザーストーリーテンプレートに従う
3. **index.md更新**: ストーリー一覧テーブルにリンクを追加
4. **関連ドキュメント更新**: 関連する既存ストーリーに相互リンクを追加

## 検証チェックリスト

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

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

### 情報分類プロセス

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

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

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

### 確認が必要な場面

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

### 確認の形式

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

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

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

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

## 後続スキルとの連携

docs/sdd/requirements/の作成完了後：
- ~~software-designing~~（非推奨）: 設計は実装時にPR本文へ記載する
- **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` | - |