Back to list
windschord

requirements-defining

by windschord

1🍴 1📅 Jan 25, 2026

SKILL.md


name: requirements-defining description: EARS記法を用いた要件定義書を作成・編集します。ユーザーストーリーの作成、受入基準の定義、非機能要件の整理が必要な場合に使用してください。 version: "1.0.0"

要件定義スキル

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

概要

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

  • docs/requirements/index.md: 要件一覧(目次)
  • docs/requirements/stories/US-XXX.md: ユーザーストーリー詳細
  • docs/requirements/nfr/*.md: 非機能要件(カテゴリ別)

ドキュメント構成

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

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

新規作成時

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

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

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

EARS記法ガイド

基本パターン

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

要件の例

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

避けるべき表現

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

ワークフロー

新規作成フロー

  1. 情報収集: プロジェクトの目的、対象ユーザー、主要機能を確認
  2. ディレクトリ作成: docs/requirements/stories/docs/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)
  • 各要件がテスト可能である
  • 非機能要件が含まれている
  • 曖昧な表現が排除されている

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

情報分類プロセス

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

明示された情報:

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

不明な情報:

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

確認が必要な場面

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

確認の形式

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

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

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

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

後続スキルとの連携

requirements.mdの作成完了後:

  • software-designing: requirements.mdを基に技術設計を行う
  • 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.mdUS-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がファイルを参照する際に使用

Score

Total Score

55/100

Based on repository quality metrics

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

+10
説明文

100文字以上の説明がある

0/10
人気

GitHub Stars 100以上

0/15
最近の活動

3ヶ月以内に更新がある

0/10
フォーク

10回以上フォークされている

0/5
Issue管理

オープンIssueが50未満

+5
言語

プログラミング言語が設定されている

0/5
タグ

1つ以上のタグが設定されている

0/5

Reviews

💬

Reviews coming soon