requirement-analyzer について
requirement-analyzer は、技術を問わずソフトウェア要件を分析・文書化するスキルです。品質、優先度、ステークホルダー、リスク、トレーサビリティの整理を支援します。
主な機能
- 01機能要件と非機能要件の分類
- 02ユーザーストーリーと仕様の整理
- 03MoSCoW と Kano による優先順位付け
- 04要件の品質と完全性の確認
- 05ステークホルダー、リスク、依存関係の整理
- 06トレーサビリティと受け入れ基準の作成
活用シーン
- 01曖昧なニーズを分類済み要件に変換
- 02MoSCoW または Kano で範囲を優先付け
- 03要件の不足や曖昧さを点検
- 04要件とテストの対応関係を記録
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ masanao-ohba/ claude-manifests --skill requirement-analyzerインストール後、Claude Code で/requirement-analyzerを入力して読み込まれたか確認します。
詳細
汎用要件アナライザー
あらゆる種類のプロジェクトを対象に、ソフトウェア要件を分析、分類、文書化するためのテクノロジーに依存しないスキルです。
主な役割
1. 要件の分解
要件を次の汎用カテゴリに分類します。
Requirement Categories:
Functional:
- What the system must do
- User interactions
- Business logic
- Data processing
Non-Functional:
- Performance targets
- Security requirements
- Usability standards
- Reliability metrics
Constraints:
- Technical limitations
- Business rules
- Regulatory compliance
- Resource boundaries
2. 要件分析フレームワーク
汎用ユーザーストーリー形式:
User Story:
as_a: [user role/persona]
i_want: [feature/capability]
so_that: [business value/benefit]
Acceptance Criteria:
given: [initial context/state]
when: [action/trigger]
then: [expected outcome/result]
要件仕様テンプレート:
Requirement:
id: REQ-[number]
title: [brief description]
type: functional|non-functional|constraint
priority: must|should|could|wont
description: [detailed description]
rationale: [why this is needed]
source: [stakeholder/document]
acceptance_criteria:
- [measurable criterion 1]
- [measurable criterion 2]
dependencies:
- [related requirement ids]
risks:
- [potential risks]
assumptions:
- [underlying assumptions]
3. 優先順位付けフレームワーク
MoSCoW 法:
Must Have:
- Critical for launch
- System fails without it
- Legal/regulatory requirement
Should Have:
- Important but not vital
- Workaround exists
- High value for users
Could Have:
- Desirable but not necessary
- Nice to have
- Can be postponed
Won't Have (this time):
- Out of scope
- Future consideration
- Explicitly excluded
カノモデル:
Basic Needs:
- Expected by users
- Causes dissatisfaction if missing
Performance Needs:
- More is better
- Linear satisfaction
Excitement Needs:
- Delighters
- Unexpected features
- Competitive advantage
4. 要件の品質基準
SMART 要件:
Specific:
- Clear and unambiguous
- Well-defined scope
Measurable:
- Quantifiable success criteria
- Testable conditions
Achievable:
- Technically feasible
- Resource realistic
Relevant:
- Aligns with business goals
- Provides value
Time-bound:
- Has deadline/milestone
- Time constraints defined
完全性チェックリスト:
Requirement Completeness:
- [ ] Clear description
- [ ] Defined acceptance criteria
- [ ] Identified stakeholder
- [ ] Priority assigned
- [ ] Dependencies mapped
- [ ] Risks assessed
- [ ] Assumptions documented
- [ ] Traceability established
5. ステークホルダー分析
ステークホルダーマッピング:
Stakeholder Analysis:
identification:
- End users
- Business owners
- Technical team
- Regulatory bodies
- External partners
influence_interest_matrix:
high_influence_high_interest:
- Key players
- Manage closely
high_influence_low_interest:
- Keep satisfied
- Regular updates
low_influence_high_interest:
- Keep informed
- Regular communication
low_influence_low_interest:
- Monitor
- Minimal effort
6. 要件の検証
検証手法:
Review Methods:
walkthrough:
- Informal review
- Author-led
- Educational focus
inspection:
- Formal review
- Defined roles
- Defect detection
prototype_validation:
- Visual representation
- User feedback
- Early validation
7. 達成指標フレームワーク
達成指標の生成:
Achievement Indicator Structure:
functional_completeness:
- indicator: "All user stories completed"
measurable: "Story points delivered"
threshold: "100% of committed stories"
priority: high
- indicator: "API contracts fulfilled"
measurable: "Endpoint tests pass"
threshold: "All endpoints return expected data"
priority: high
quality_standards:
- indicator: "Code quality maintained"
measurable: "Lint score"
threshold: "> 90/100"
priority: medium
- indicator: "Test coverage adequate"
measurable: "Coverage percentage"
threshold: ">= 80%"
priority: high
performance_criteria:
- indicator: "Response time acceptable"
measurable: "95th percentile latency"
threshold: "< 200ms"
priority: medium
- indicator: "Throughput sufficient"
measurable: "Requests per second"
threshold: "> 1000 RPS"
priority: low
security_requirements:
- indicator: "Authentication secure"
measurable: "Security audit pass"
threshold: "No critical vulnerabilities"
priority: high
成功基準(達成目標)の生成:
Success Criteria Structure:
implementation_goals:
- objective: "Deliver core functionality"
success_criteria: "User can complete primary workflow"
measurement: "End-to-end test passes"
- objective: "Maintain system stability"
success_criteria: "No regression in existing features"
measurement: "Regression test suite passes"
quality_goals:
- objective: "Ensure maintainability"
success_criteria: "Code follows standards"
measurement: "Code review approval"
- objective: "Document adequately"
success_criteria: "All public APIs documented"
measurement: "Documentation coverage 100%"
business_goals:
- objective: "Meet user expectations"
success_criteria: "User acceptance criteria met"
measurement: "UAT sign-off received"
- objective: "Enable future growth"
success_criteria: "Architecture supports scaling"
measurement: "Load test validates 10x capacity"
受け入れ基準文書の生成テンプレート:
# Acceptance Criteria Document
# Generated: {timestamp}
# Project: {project_name}
# Task: {task_description}
# Size: {trivial|small|medium|large}
acceptance_criteria:
task_classification:
size: {estimated_size}
complexity: {low|medium|high}
risk_level: {low|medium|high}
indicators: # Achievement Indicators - What we measure
completeness:
- id: "AI-COMP-001"
indicator: {description}
measurement_method: {how_to_measure}
pass_threshold: {specific_value}
priority: {must|should|could}
verification_agent: {which_agent_verifies}
quality:
- id: "AI-QUAL-001"
indicator: {description}
measurement_method: {automated|manual}
pass_threshold: {metric_value}
priority: {level}
verification_agent: {agent_name}
performance:
- id: "AI-PERF-001"
indicator: {description}
measurement_method: {tool_or_process}
pass_threshold: {numeric_threshold}
priority: {level}
verification_agent: {agent_name}
objectives: # Success Criteria - What we aim to achieve
primary:
- id: "SC-PRIM-001"
objective: {clear_goal}
success_definition: {when_considered_achieved}
responsible_agent: {implementation_agent}
deadline: {if_applicable}
secondary:
- id: "SC-SEC-001"
objective: {supporting_goal}
success_definition: {criteria}
responsible_agent: {agent_name}
evaluation_protocol:
stage_1_pre_implementation:
- action: "Generate acceptance criteria document"
responsible: "goal-clarifier"
stage_2_implementation:
- action: "Use acceptance criteria as implementation guide"
responsible: "code-developer"
stage_3_evaluation:
- action: "Evaluate against achievement indicators"
responsible: "deliverable-evaluator"
input: "Acceptance criteria document"
stage_4_iteration:
- action: "If FAIL, return to stage 2 with feedback"
- max_iterations: 3
output_location: ".work/requirements/acceptance-criteria-{timestamp}.yaml"
検証基準:
Quality Attributes:
correctness:
- Accurately represents need
- Factually correct
consistency:
- No conflicts
- Uniform terminology
completeness:
- All aspects covered
- No gaps
feasibility:
- Technically possible
- Resource available
testability:
- Verifiable criteria
- Measurable outcomes
分析プロセス
ステップ 1:要件の収集
Sources:
- Stakeholder interviews
- Existing documentation
- Market research
- Competitive analysis
- User feedback
- Regulatory requirements
ステップ 2:分類
Classification:
1. Parse raw requirements
2. Identify requirement type
3. Assign categories
4. Group related items
5. Identify patterns
ステップ 3:分析
Analysis Activities:
1. Ambiguity resolution
2. Conflict identification
3. Gap analysis
4. Dependency mapping
5. Risk assessment
ステップ 4:文書化
Documentation Outputs:
- Requirement specification
- Traceability matrix
- Stakeholder matrix
- Risk register
- Assumption log
出力形式
要件仕様書
# Requirement Specification
## Executive Summary
[High-level overview of requirements]
## Functional Requirements
### FR-001: [Title]
- **Description**: [Detail]
- **Priority**: Must Have
- **Acceptance Criteria**:
1. [Criterion 1]
2. [Criterion 2]
## Non-Functional Requirements
### NFR-001: [Title]
- **Category**: Performance
- **Metric**: Response time < 2 seconds
- **Validation**: Load testing
## Constraints
### CON-001: [Title]
- **Type**: Technical
- **Description**: [Limitation details]
- **Impact**: [How it affects design]
## Dependencies
[Requirement dependency diagram]
## Risks and Assumptions
### Risks
- [Risk 1]: [Mitigation strategy]
### Assumptions
- [Assumption 1]: [Validation plan]
トレーサビリティマトリクス
Traceability:
REQ-001:
source: "User Interview #3"
design_element: "Component A"
test_case: "TC-001, TC-002"
implementation: "Module X"
REQ-002:
source: "Regulatory Doc Section 4.2"
design_element: "Security Layer"
test_case: "TC-010"
implementation: "Auth Module"
統合ポイント
プロジェクト設定との連携
# Project-specific configuration
requirement_config:
project_type: "web_application|mobile_app|api|system"
priority_framework: "moscow|kano|numerical"
requirement_categories:
- functional
- non-functional
- business
- technical
validation_requirements:
review_type: "formal|informal"
approval_levels: 2
compliance_standards:
- "ISO 27001"
- "GDPR"
テクノロジー固有のスキルとの連携
# Technology-specific extensions
tech_specific:
framework: "[Framework name]"
requirement_patterns:
- "[Framework-specific pattern]"
validation_rules:
- "[Technology-specific rule]"
ベストプラクティス
- ステークホルダーの関与:早い段階からすべてのステークホルダーを参加させます
- 明確なコミュニケーション:曖昧さのない言葉を使用します
- 測定可能な基準:定量化できる成功指標を定義します
- 反復的な改善:要件は変化するため、変更を見越して計画します
- トレーサビリティ:要件から実装への関連付けを維持します
- リスクに基づく重点化:リスクと価値に基づいて優先順位を付けます
- 文書化:要件を最新の状態に保ち、アクセスしやすくします
汎用的な適用
このスキルは、次のものに適用できます。
- Web アプリケーション
- モバイルアプリケーション
- デスクトップソフトウェア
- 組み込みシステム
- API とサービス
- クラウドプラットフォーム
- IoT ソリューション
- エンタープライズシステム
- 機械学習プロジェクト
- あらゆるソフトウェア開発プロジェクト
このスキルは変更ではなく設定によってプロジェクトのニーズに適応するため、さまざまなテクノロジースタックやドメインで再利用できます。
コメント
Markdown 対応