| name | requirement-analyzer |
| description | Use when collecting business requirements, decomposing goals into functional requirements, classifying them into 13 categories, mapping to business value via BMAD, defining metrics, and establishing traceability. This skill unifies L1→L2 derivation (D1 Value Derivation Domain) and replaces business-requirements-collector, business-value-mapper, requirement-classifier, value-decomposer, metrics-definer, and requirements-to-code-docs. |
Requirement Analyzer
Overview
The unified entry point for all L1→L2 derivation work. This skill:
- Collects and structures business requirements from stakeholders
- Decomposes business goals into measurable functional requirements
- Classifies requirements into 13 ISO/IEC 25010:2023 categories
- Maps requirements to business value using the BMAD framework
- Defines metrics for tracking business and technical success
- Establishes traceability between business goals, functional requirements, and downstream artifacts
Replaces (consolidated from 6 skills):
business-requirements-collector
business-value-mapper
requirement-classifier
value-decomposer
metrics-definer
requirements-to-code-docs
When to Use
Starting a new project? ───────────────────┐
│
Need to clarify business goals? ───────────┤
│
Establishing requirements traceability? ───┼─► Use requirement-analyzer
│
Defining success metrics? ─────────────────┤
│
Classifying existing requirements? ────────┘
Use when:
- Beginning a new project or feature initiative
- Need to translate business goals into actionable functional requirements
- Want to establish bidirectional traceability from business goals to implementation
- Need to define measurable success criteria
- Classifying existing requirements into the 13-category framework
- Generating documentation from requirements
Don't use when:
- Only writing test cases (use
test-planner)
- Working on architecture decisions (use
architecture-planner)
- Doing detailed technical specification (use
spec-engineer)
Core Pattern
L1→L2 Derivation Pipeline
Business Goals (L1)
│
├──► [1] Collect & Clarify (business-requirements-collector)
│ │
│ ▼
│ Structured Requirements
│ │
│ ├──► [2] Classify by 13 categories (requirement-classifier)
│ │ │
│ │ ▼
│ │ Categorized Requirements
│ │ │
│ │ ├──► [3] BMAD Value Mapping (business-value-mapper)
│ │ │ │
│ │ │ ▼
│ │ │ Value Maps
│ │ │
│ │ ├──► [4] Decompose to FRs (value-decomposer)
│ │ │ │
│ │ │ ▼
│ │ │ Functional Requirements
│ │ │
│ │ └──► [5] Define Metrics (metrics-definer)
│ │ │
│ │ ▼
│ │ Measurable Criteria
│ │
│ └──► [6] Generate Docs (requirements-to-code-docs)
│ │
│ ▼
│ Documentation Set
│
▼
Functional Requirements (L2) with full traceability
13-Category Classification Framework (ISO/IEC 25010:2023)
All requirements are classified into one of 13 categories:
3 Source Categories:
| ID | Category | Description |
|---|
REQ-BUS | Business | High-level business goals and outcomes |
REQ-FUNC | Functional | Required system behaviors and features |
REQ-USER | User | User needs, personas, and journeys |
8 Quality Categories:
| ID | Category | ISO Characteristic |
|---|
REQ-PERF | Performance | Performance efficiency |
REQ-COMP | Compatibility | Compatibility |
REQ-USE | Usability | Usability |
REQ-REL | Reliability | Reliability |
REQ-SEC | Security | Security |
REQ-MAIN | Maintainability | Maintainability |
REQ-PORT | Portability | Portability |
REQ-COMP-FUNC | Functional Suitability | Functional suitability |
2 Architecture/Data Categories:
| ID | Category | Description |
|---|
REQ-ARCH | Architecture | Architectural constraints and decisions |
REQ-DATA | Data | Data model and lifecycle requirements |
Cross-Category Relationship Types
| Relation | Description |
|---|
drives | This requirement drives another |
constrains | Imposes constraints on another |
mandates | Mandatory dependency |
depends_on | Has a dependency on |
conflicts_with | Mutual exclusion or conflict |
trades_off | Trade-off relationship |
validates | Validates or verifies |
supports | Provides support for |
enables | Enables another |
influences | Influences design or behavior |
Input Format
requirement_request:
project:
name: "Aether Platform"
context: "Greenfield SaaS product"
stakeholders:
- {role: "Product Owner", name: "Alice"}
- {role: "Tech Lead", name: "Bob"}
initial_signals:
- "Reduce user onboarding time by 50%"
- "Support 10K concurrent users"
- "GDPR compliance required"
existing_requirements:
- id: "BR-001"
description: "Users should be able to sign up with email"
source: "stakeholder-interview-2025-01-15"
classification:
framework: "ISO-25010-2023"
required_categories: ["REQ-BUS", "REQ-FUNC", "REQ-PERF", "REQ-SEC"]
metrics:
baseline_window: "30d"
target_window: "90d"
traceability:
enabled: true
storage: ".aether/state/traceability/"
Output Format
requirement_analysis_result:
project: "Aether Platform"
timestamp: "2026-06-02T10:00:00Z"
business_goals:
- id: "BG-001"
statement: "Reduce user onboarding time by 50%"
success_metric: "Time-to-first-value < 5 minutes"
priority: "must"
category: "REQ-BUS"
classified_requirements:
- id: "REQ-FUNC-001"
category: "Functional"
iso_subcharacteristic: "Functional completeness"
statement: "Email/password signup with verification"
priority: "must"
traceability:
source: "BG-001"
relationships: [{target: "REQ-PERF-001", type: "constrains"}]
acceptance_criteria:
- "User submits email and password"
- "System sends verification email within 30s"
- "User clicks verification link, account activated"
value_maps:
- business_goal: "BG-001"
metric: "Onboarding completion rate"
current: 0.65
target: 0.85
action: "Implement streamlined signup flow"
data: ["signup_events", "verification_events"]
functional_requirements:
- id: "FR-001"
derived_from: "REQ-FUNC-001"
statement: "POST /api/v1/auth/signup with email/password validation"
api_contract:
request: {email: "string", password: "string"}
response_2xx: {user_id: "uuid", verification_token: "string"}
response_4xx: [{code: 400, error: "invalid_email"}]
test_criteria:
- "Valid input creates user and returns 201"
- "Duplicate email returns 409"
- "Invalid email format returns 400"
metrics:
business_metrics:
- name: "Onboarding completion rate"
formula: "verified_users / signup_started"
target: 0.85
current: 0.65
collection: "events.signup_completed / events.signup_started"
technical_metrics:
- name: "Signup API p95 latency"
target: 200ms
current: "TBD"
collection: "http_server_requests_seconds_bucket"
traceability_matrix:
BG-001 → [REQ-FUNC-001, REQ-PERF-001] → [FR-001, FR-002]
coverage:
functional: "100% (3/3 FRs traced)"
business: "100% (2/2 goals traced)"
orphans: []
documentation:
- path: ".aether/docs/requirements/business-goals.md"
type: "goals"
- path: ".aether/docs/requirements/functional-requirements.md"
type: "functional"
- path: ".aether/docs/requirements/traceability-matrix.md"
type: "traceability"
Implementation
Step 1: Collect & Clarify Business Goals
Use the standard 6-question framework to clarify each business goal:
def clarify_business_goal(goal: str) -> dict:
"""Apply 6 clarifying questions to a business goal."""
return {
"who": who_benefits_from_this(goal),
"what": what_outcome_is_expected(goal),
"when": when_is_success_measured(goal),
"where": where_in_user_journey(goal),
"why": why_is_this_important(goal),
"how_much": what_is_the_target_metric(goal),
}
Common business goal patterns:
| Pattern | Typical Decomposition |
|---|
| Grow user base | Multi-channel signup, onboarding, referral program |
| Increase revenue | Pricing tiers, payment integration, upsell flows |
| Reduce costs | Automation, performance optimization, caching |
| Improve UX | User research, A/B testing, accessibility |
| Ensure compliance | Audit trails, data governance, security controls |
| Scale operations | Load balancing, async processing, microservices |
Step 2: Classify Requirements
Apply the 13-category framework to each requirement:
def classify_requirement(requirement: dict) -> dict:
"""Classify a requirement into one of 13 categories."""
pass
Classification rules:
- Each requirement gets exactly one primary category
- Detect cross-category relationships (
drives, constrains, etc.)
- Validate against ISO/IEC 25010:2023 subcharacteristics
- Flag ambiguous requirements for human review
Step 3: BMAD Value Mapping
For each business goal, build a BMAD matrix:
bmad_matrix:
- business_goal: "Reduce onboarding time"
metric: "Time-to-first-value"
current: 12min
target: 5min
actions:
- "Streamline signup (3 fields → 2)"
- "Add social login (Google, GitHub)"
- "Skip email verification for known domains"
data_sources:
- "events.signup_started"
- "events.first_action_completed"
Step 4: Decompose to Functional Requirements
Each requirement (especially REQ-FUNC) becomes one or more functional requirements with API contracts:
functional_requirement:
id: "FR-001"
derived_from: "REQ-FUNC-001"
statement: "System shall provide POST /api/v1/auth/signup endpoint"
api_contract:
method: POST
path: "/api/v1/auth/signup"
request_schema: {email: "string", password: "string"}
response_2xx: {user_id: "uuid", verification_token: "string"}
response_4xx: [{status: 400, error: "validation_failed"}]
response_5xx: [{status: 500, error: "internal_error"}]
test_criteria: [...]
priority: "must"
estimated_effort: "M"
Step 5: Define Metrics
For each functional requirement, define:
- Business metric: KPI tied to business goal
- Technical metric: SLO/SLI for service quality
- Collection method: Where the metric data comes from
metrics:
business:
- name: "Onboarding completion rate"
formula: "verified_users / signup_started"
target: 0.85
collection: "events"
technical:
- name: "Signup API p95 latency"
target: "200ms"
collection: "prometheus"
- name: "Error rate"
target: "<0.1%"
collection: "prometheus"
Step 6: Generate Documentation & Traceability
Generate three artifacts:
- Per-category requirement files in
.aether/docs/requirements/{category}.md
- Traceability matrix in
.aether/state/traceability/matrix.yml
- Summary report in
.aether/docs/requirements/README.md
Validation Rules
- ✅ Each functional requirement traces to at least one business goal
- ✅ Each business goal has at least one measurable metric
- ✅ Priorities are
must / should / could / won't
- ✅ "Must" priority items have explicit acceptance criteria
- ✅ Cross-category relationships are detected and validated
- ✅ No orphan requirements (untraced to goals)
- ✅ No goal coverage gaps (each goal has at least one FR)
Integration with Aether.go Methodology
- Input from: Stakeholders, business context, existing documentation
- Output to:
architecture-planner (L2 design)
spec-engineer (L3 specification)
test-planner (L4 test strategy)
- Part of: D1 Value Derivation Domain
- Principle alignment:
- P1 Purpose-Driven: Every FR traces to a business goal
- P7 Context-First: Goal clarification precedes implementation
- P9 Recursive-Optimization: Metrics feedback drives improvement
Examples
Example 1: New E-commerce Project
project: "Online marketplace"
business_goals:
- "Increase seller signups by 200% in Q3"
- "Reduce cart abandonment by 30%"
functional_requirements_count: 24
metrics_defined: 12
traceability_coverage: "100%"
Example 2: Classifying Legacy Requirements
input: 47 existing requirements from Confluence export
classified:
REQ-FUNC: 18
REQ-PERF: 6
REQ-SEC: 8
REQ-USER: 7
REQ-DATA: 4
REQ-ARCH: 4
cross_category_relations: 23
orphan_requirements: 0
coverage_gaps: []
Migration Notes
This skill consolidates the following previously separate skills:
business-requirements-collector — Phase 1 collection
business-value-mapper — Phase 3 BMAD
requirement-classifier — Phase 2 13-category
value-decomposer — Phase 4 L1→L2 derivation
metrics-definer — Phase 5 metrics
requirements-to-code-docs — Phase 6 docs
For backward compatibility, the following keywords in skill-invocation context are still recognized:
- "collect requirements" → invokes Phase 1
- "classify" → invokes Phase 2
- "BMAD" / "value map" → invokes Phase 3
- "decompose" / "FR" → invokes Phase 4
- "define metric" / "KPI" → invokes Phase 5
- "generate docs" / "trace" → invokes Phase 6