k2works/analyzing-requirements
.agents/skills/analyzing-requirements/SKILL.md
RDRA 2.0 に基づく体系的な要件定義を支援。システム価値→外部環境→境界→内部構造の 4 層で要件を整理。「要件定義を始めたい」「システムの要求を整理したい」「RDRA で分析したい」「業務フローを整理したい」「システムコンテキストを作りたい」といった場面で発動する。要件を体系的に整理することで、開発フェーズでの「何を作ればいいかわからない」問題を防ぐ。
tools
Updated Apr 16, 2026
$ install --global
skillsauthnpx skillsauth add k2works/getting-started-tdd analyzing-requirementsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 16, 2026, 5:24 PM4.6s1 file scanned
SKILL.md
- name:
- analyzing-requirements
- description:
- RDRA 2.0 に基づく体系的な要件定義を支援。システム価値→外部環境→境界→内部構造の 4 層で要件を整理。「要件定義を始めたい」「システムの要求を整理したい」「RDRA で分析したい」「業務フローを整理したい」「システムコンテキストを作りたい」といった場面で発動する。要件を体系的に整理することで、開発フェーズでの「何を作ればいいかわからない」問題を防ぐ。
要件定義
RDRA 2.0（リレーションシップ駆動要件分析）に基づき、システム価値→外部環境→境界→内部構造の 4 層で要件を体系的に整理する。
RDRA の価値は、要件を「何となくの要望リスト」ではなく「なぜそれが必要か」の根拠付きで構造化できること。各層の出力が次の層の入力になるため、トレーサビリティが自然に確保される。
参照ドキュメントとテンプレート
| 種類 | パス | 備考 |
|------|------|------|
| ガイド | @docs/reference/要件定義ガイド.md | RDRA 2.0 の進め方詳細 |
| テンプレート | @docs/template/要件定義.md | 編集禁止。コピーして使用する |
| 入力 | @docs/strategy/business_architecture.md | ビジネスアーキテクチャ分析書 |
| 入力 | @docs/strategy/inception-deck.md | インセプションデッキ |
| 成果物 | docs/requirements/requirements_definition.md | テンプレートを基に作成 |
RDRA の 4 層構造
各層は上から下に向かって具体化されていく。上位層が曖昧だと下位層の定義がブレるため、この順序で進めることが重要。
層 1: システム価値
「なぜこのシステムが必要か」を明確にする。インセプションデッキの「なぜやるのか」をシステムの文脈で具体化する。
- システムコンテキスト図: システムとアクター（人・外部システム）の関係を PlantUML で図示
- 要求モデル: ステークホルダーの要求を構造化して一覧化
層 2: システム外部環境
「どのような業務の中でシステムが使われるか」を整理する。ビジネスアーキテクチャ分析書のバリューストリームや組織マップが入力になる。
- ビジネスコンテキスト: 業務の全体像とシステムの位置づけ
- ビジネスユースケース: 業務レベルのユースケース識別
- 業務フロー: 業務プロセスの可視化（PlantUML アクティビティ図）
- 利用シーン: ユーザーがシステムを使う具体的な場面
層 3: システム境界
「システムの内と外の接点は何か」を定義する。外部環境の分析結果から、システムが担う範囲を確定する。
- ユースケース複合図: システムユースケースとアクターの関係
- 画面・帳票モデル: ユーザーインターフェースの概要定義
- イベントモデル: システムが受け取る・発信するイベント
層 4: システム内部構造
「システム内部でどのような情報をどう扱うか」を設計する。後続のデータモデル設計・ドメインモデル設計の基礎になる。
- 情報モデル: システムが扱う主要なエンティティとリレーション
- 状態モデル: 主要エンティティの状態遷移
作成の進め方
新規作成
- 入力ドキュメント（ビジネスアーキテクチャ分析書、インセプションデッキ）の有無を確認する。なければ基本情報をヒアリングする
- テンプレート（@docs/template/要件定義.md）を読み込む
- 層 1 から順に 4 層を作成する。各層で PlantUML を活用して視覚化する
docs/requirements/requirements_definition.mdとして出力する
途中から再開・更新
既存の docs/requirements/requirements_definition.md がある場合は、まずその内容を確認する。不足している層や更新が必要な部分のみを修正する。
Example:
ユーザー: 「システムコンテキストは作った。業務フローを整理したい」
回答: 層 2（システム外部環境）の業務フロー作成に進む。
既存のシステムコンテキスト図のアクターを起点に、
各アクターの業務プロセスを PlantUML アクティビティ図で可視化する。
注意事項
- 入力ドキュメントが未作成でも、プロジェクト情報から直接作成可能。完璧な入力を待つより進める方が効果的
- テンプレートは編集禁止。コピーして成果物を作成する
- 各層の成果物には PlantUML を活用し、テキストだけでなく図で表現する
- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
関連スキル
analyzing-business-architecture— 前段のビジネスアーキテクチャ分析analyzing-inception-deck— 前段のインセプションデッキanalyzing-usecases— 後続のユースケース・ユーザーストーリー詳細化orchestrating-analysis— 分析フェーズ全体のワークフロー案内
Related Skills
k2works/validating-iteration-plan
tools
VerifiedTrustedCommunity
イテレーション計画と上流設計ドキュメント群（ユーザーストーリー、ドメインモデル、データモデル、UI 設計）との整合性を検証する。「イテレーション計画を検証したい」「計画の整合性をチェックして」「イテレーション計画を作成した」「計画と設計ドキュメントの不整合を確認したい」といった場面で発動する。planning-releases でイテレーション計画を作成した直後にも積極的に使用すること。計画作成後に必ず本検証を実施することで、開発着手前にドキュメント間の不整合を検知・修正できる。
SKILL.mdUpdated Apr 16, 2026
k2works/tracking-progress
tools
VerifiedTrustedCommunity
プロジェクトの開発進捗を多角的に分析しレポートを生成。イテレーション達成度、技術実装状況、品質メトリクスを確認し、計画ドキュメントを自動更新する。「進捗を確認したい」「プロジェクトの状態を知りたい」「イテレーションの達成度を分析したい」「進捗ドキュメントを更新したい」といった場面で発動する。定期的な進捗可視化により、遅延や品質低下を早期に発見しプロジェクトの透明性を確保する。
SKILL.mdUpdated Apr 16, 2026
k2works/syncing-github-project
testing
VerifiedTrustedCommunity
リリース計画を GitHub Project・Issue・Milestone に反映し一元管理。初回の一括同期から差異検出・自動同期まで対応する。「GitHub Project に同期したい」「Issue を作成したい」「計画と GitHub の差異を確認したい」「Milestone を設定したい」といった場面で発動する。計画ドキュメントを Single Source of Truth とし GitHub に自動反映することで、二重管理の手間と不整合を排除する。
SKILL.mdUpdated Apr 16, 2026
k2works/practicing-getting-start-tdd
development
VerifiedTrustedCommunity
テスト駆動開発から始めるプログラミング入門」の対話式チュートリアル。FizzBuzz を題材に TDD の Red-Green-Refactor サイクルを 14 言語で体験する。「TDD を練習したい」「FizzBuzz で TDD を学びたい」「テスト駆動開発の入門をしたい」「Java で TDD を体験したい」「Python で TDD を始めたい」「プログラミング入門チュートリアルをやりたい」「getting-start-tdd をやりたい」「TDD のハンズオンがしたい」「Red-Green-Refactor を体験したい」といった場面で発動する。TDD チュートリアルやプログラミング入門の要望があれば積極的に使用すること。
SKILL.mdUpdated Apr 16, 2026