mcpField
R
requirement-analyzer

requirement-analyzer

github.com/masanao-ohba開発249 回インストール33 週間前に更新
リポジトリ

requirement-analyzer について

requirement-analyzer は、技術を問わずソフトウェア要件を分析・文書化するスキルです。品質、優先度、ステークホルダー、リスク、トレーサビリティの整理を支援します。

主な機能

  1. 01機能要件と非機能要件の分類
  2. 02ユーザーストーリーと仕様の整理
  3. 03MoSCoW と Kano による優先順位付け
  4. 04要件の品質と完全性の確認
  5. 05ステークホルダー、リスク、依存関係の整理
  6. 06トレーサビリティと受け入れ基準の作成

活用シーン

  1. 01曖昧なニーズを分類済み要件に変換
  2. 02MoSCoW または Kano で範囲を優先付け
  3. 03要件の不足や曖昧さを点検
  4. 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]"

ベストプラクティス

  1. ステークホルダーの関与:早い段階からすべてのステークホルダーを参加させます
  2. 明確なコミュニケーション:曖昧さのない言葉を使用します
  3. 測定可能な基準:定量化できる成功指標を定義します
  4. 反復的な改善:要件は変化するため、変更を見越して計画します
  5. トレーサビリティ:要件から実装への関連付けを維持します
  6. リスクに基づく重点化:リスクと価値に基づいて優先順位を付けます
  7. 文書化:要件を最新の状態に保ち、アクセスしやすくします

汎用的な適用

このスキルは、次のものに適用できます。

  • Web アプリケーション
  • モバイルアプリケーション
  • デスクトップソフトウェア
  • 組み込みシステム
  • API とサービス
  • クラウドプラットフォーム
  • IoT ソリューション
  • エンタープライズシステム
  • 機械学習プロジェクト
  • あらゆるソフトウェア開発プロジェクト

このスキルは変更ではなく設定によってプロジェクトのニーズに適応するため、さまざまなテクノロジースタックやドメインで再利用できます。

コメント