mcpField
R
requirements-from-brief

requirements-from-brief

github.com/mattjmdesign開発48 回インストール
リポジトリ

requirements-from-brief について

インターフェース案を選ぶ前に、製品ブリーフをテスト可能な機能・非機能要件へ整理するスキルです。範囲や依存関係を明確にしたいチーム向けで、前提、未解決の質問、次の作業案も示します。

主な機能

  1. 01目標と制約の抽出
  2. 02テスト可能な機能要件の作成
  3. 03非機能要件の検討
  4. 04範囲と依存関係の特定
  5. 05前提と未解決事項の整理
  6. 06受け入れ基準とフロー計画の提案

活用シーン

  1. 01初期の製品ブリーフを要件化
  2. 02API、データ、認証の依存関係を明確化
  3. 03初回リリースの対象外を定義
  4. 04受け入れ基準とユーザーフローを準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mattjmdesign/dengskills --skill requirements-from-brief

インストール後、Claude Code で/requirements-from-briefを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yamlevals/evals.json

詳細

要件ブリーフ

このスキルを使うと、インターフェースの解決策を選ぶ前に、プロダクトの意図を要件に落とし込めます。要件では、どのコンポーネントを使うかではなく、ユーザーとシステムに必要なことを記述します。

プロセス

  1. ユーザーの目標、ビジネス目標、制約、データ／API／認証の依存関係を抽出します。
  2. 機能要件を FR-XX: The system shall [action] when [condition] so that [outcome]. の形式で記述します。
  3. 関連する場合は、パフォーマンス、アクセシビリティ、レスポンシブ対応、ブラウザーサポート、セキュリティ／プライバシー、国際化に関する非機能要件を記述します。
  4. v1 で明示的に対象外とする項目を特定します。
  5. 前提条件と未解決の質問を特定します。
  6. 次のステップとして、受け入れ基準、サイトマップ、またはユーザーフローのマッピングを提案します。

出力形式

## Requirements

### Functional requirements
FR-01: The system shall ... when ... so that ...

### Non-functional requirements
NFR-01: ...

### Dependencies
- Data/API:
- Auth/permissions:
- Design system:

### Out of scope for v1
- [item]

### Assumptions
- [item]

### Open questions
- [item]

**Recommended next step:**

実例

要件

機能要件

FR-01: ユーザーがダッシュボードを開いたとき、システムは直近30日間のアクティビティを表示し、移動せずに最近の作業を確認できるようにします。 FR-02: システムは選択した期間フィルターを URL に保持し、ビューを共有したりブックマークしたりできるようにします。

非機能要件

NFR-01: ダッシュボードの初回読み込みでは、4G モバイル環境で LCP が 2.5 秒未満になる必要があります。 NFR-02: ダッシュボードのすべてのコントロールにキーボードでアクセスでき、コントラストに関する WCAG 2.2 AA に準拠する必要があります。

依存関係
  • データ／API：アクティビティ API は存在します。レート制限は文書化されていません。
  • 認証／権限：ロールベースです。管理者はすべてのチームを閲覧できます。
  • デザインシステム：まだありません
v1 の対象外
  • カスタムレポートビルダー、CSV のスケジュール設定、モバイルプッシュ通知
前提条件
  • アクティビティデータはサーバー側に保存され、日付範囲でクエリできます。
未解決の質問
  • 30日より前のデータはどう扱いますか。ページネーションにしますか、それとも要約ビューにしますか。

次のおすすめステップ： アプリシェルとダッシュボードのルートについてサイトマップを計画します。

よくある間違いと防止策

  • 要件を UI の解決策として書かないでください。「20項目を比較する」は要件ですが、「テーブルを表示する」は解決策の候補です。
  • ユーザーが機能だけを説明した場合でも、非機能要件を省略しないでください。
  • 認証、権限、API の依存関係を曖昧な表現に隠さないでください。

適用範囲

  • アイデアがまだ曖昧な場合は使わないでください。先に $product-intent-clarifier を実行してください。
  • 要件がすでにあり、未解決の質問が IA に関する場合は使わないでください。$sitemap-planner を使用してください。
  • 要件を UI の解決策として書かないでください。テーブルは解決策であり、項目の比較が要件です。

最終確認

  • すべての FR がテスト可能であること。
  • 明らかに無関係でない限り、アクセシビリティとレスポンシブ対応を NFR として検討していること。
  • 不明点が前提条件または未解決の質問として明示されていること。

関連項目

コメント

Markdown 対応