requirements-elicitation

What this skill does

# Requirements Elicitation

## Core Principle

**The quality of requirements is determined by the quality of questions asked, viewed through multiple
stakeholder lenses, and verified across all dimensions of completeness.** This workflow transforms
incomplete descriptions into actionable, comprehensive specifications.

## When to Use This Workflow

-   Receiving brief notes or incomplete descriptions
-   Gathering requirements for new features or systems
-   Reviewing existing specifications for completeness
-   Requirements have gaps between stated need and actionable specification
-   Unclear stakeholder intent or missing cross-functional requirements
-   Temptation to "fill in" gaps with assumptions
-   Before starting implementation of any significant feature

## Workflow Overview

This workflow orchestrates these atomic skills:

-   `pre-task-checkpoint` - Problem framing and analysis before elicitation
-   `clarifying-questions` - Reactive response to ambiguity
-   `specification-elicitation` - Proactive 5-level question framework
-   `stakeholder-analysis` - Multi-perspective analysis (8 stakeholder types)
-   `information-completeness` - 9-dimension information gathering
-   `conceptual-analysis` - Understanding true intent beyond literal statements
-   `framing-skepticism` - Challenging embedded assumptions
-   `deliverable-completeness` - 6-dimension specification verification
-   `documentation-quality` - Ensuring specifications add value
-   `evidence-reasoning` - Evidence-based validation

## Progressive Depth Paths

This workflow supports three depth levels based on complexity and stakes:

### Quick Path (Simple Features, Low Risk)

```
Entry → Phase 1 → Phase 2 (L1-L2) → Phase 3 (Quick stakeholder check) →
Phase 4 (Dimensions 1-3) → Phase 5 (Exit)
```

**Use when:**

-   Single-stakeholder feature (e.g., internal tool)
-   Well-understood domain
-   Low operational complexity
-   Minimal cross-system integration

**Time:** 30-60 minutes

### Standard Path (Most Features)

```
Entry → Phase 1 → Phase 2 (L1-L4) → Phase 3 (Core stakeholders) →
Phase 4 (All 6 dimensions) → Phase 5 (Quality checks) → Phase 6 (Exit)
```

**Use when:**

-   Multi-stakeholder impact
-   Moderate complexity
-   Some integration concerns
-   Standard operational requirements

**Time:** 2-4 hours

### Comprehensive Path (Complex/High-Stakes)

```
Entry → Phase 1 → Phase 2 (L1-L5) → Phase 3 (All 8 stakeholders) →
Phase 4 (All 6 dimensions) → Phase 4.5 (Information completeness 9D) →
Phase 5 (Quality gates) → Phase 6 (Evidence validation) → Phase 7 (Exit)
```

**Use when:**

-   Mission-critical features
-   High operational risk
-   Complex multi-system integration
-   Regulatory/compliance requirements
-   Novel or experimental features

**Time:** 1-2 days

## Phase 1: Entry Point & Problem Framing

**Invoke: `pre-task-checkpoint`**

Before starting elicitation, establish foundation:

```
□ Checkpoint 1: Problem Framing
  - What PROBLEM does this feature solve? (not "what feature to build")
  - Is the request a solution masquerading as a requirement?
  - Can the underlying need be addressed differently?
  - What business outcome is the stakeholder trying to achieve?

□ Checkpoint 2: Familiarity Check
  - Have I implemented similar features before? → RED FLAG
  - Familiar domain = higher risk of assumption-driven gaps
  - Similar ≠ same (different context = different requirements)

□ Checkpoint 3: Framework Selection
  - Complexity level? → Choose depth path
  - Which atomic skills will this workflow need?

□ Checkpoint 4: Initial Scope Assessment
  - Is this a new feature, enhancement, or system?
  - What's explicitly stated vs implicitly assumed?
  - Who are the likely affected stakeholders?

□ Checkpoint 5: Resource Allocation
  - PARSIMONY: What's the simplest elicitation approach?
  - SCOPE: Are we gathering actual needs or hypothetical ones?
  - INFORMATION ECONOMY: What existing documentation exists?
```

**Invoke: `framing-skepticism`**

Challenge the task framing:

```
□ How has the stakeholder framed this request?
  - Is it framed as a solution? ("Add feature X")
  - Or as a problem? ("Users can't accomplish Y")

□ Separate observation from interpretation:
  - Observation: What's the stated request?
  - Interpretation 1: Accept framing as-is
  - Interpretation 2: Question underlying assumption
  - Root cause: What's the actual need?

□ Question embedded constraints:
  - What constraints are implicit in the framing?
  - Must solution follow suggested approach?
  - Are there alternative framings to explore?
```

**Exit Criteria:** Problem framing established, depth path selected, assumptions surfaced

## Phase 2: Question-Driven Elicitation

**Invoke: `specification-elicitation`**

Apply 5-level question framework systematically. Depth depends on path selected.

### Level 1: Surface Clarification (ALL PATHS)

_Addresses obvious gaps in stated requirements_

```
Questions to generate:
✅ What are the explicit inputs/outputs?
✅ What file types/formats/sizes are involved?
✅ What are the basic acceptance criteria?
✅ What does success look like?
✅ What are the core user actions?

Anti-patterns:
❌ Assuming "reasonable defaults" without validation
❌ Filling gaps with "industry standard" practices
❌ Moving forward with open questions
```

### Level 2: Edge Case Exploration (QUICK+ PATHS)

_Probes boundaries and failure modes_

```
Questions to generate:
✅ What happens if operation fails? Retry policy?
✅ What if user input is invalid/malicious?
✅ What if external dependencies are unavailable?
✅ What are the rate limits/quotas?
✅ What if operation takes too long? Timeout? User cancellation?
✅ What if it's the FIRST time? LAST time? ONLY one?

Edge case discovery framework:
- What if it's ALREADY done? (idempotency)
- What if it's CONCURRENT? (race conditions)
- What if it FAILS HALFWAY? (partial state, recovery)
- What if there are MANY? (performance, pagination)
```

### Level 3: Constraint Discovery (STANDARD+ PATHS)

_Surfaces hidden requirements and quantified targets_

```
Questions to generate:
✅ What are the performance requirements?
  - Latency: p50, p95, p99 targets?
  - Throughput: requests/sec, data volume?
  - Concurrent users: expected scale?

✅ What are the data requirements?
  - Volume: how much data?
  - Growth: expected growth rate?
  - Retention: how long to keep?

✅ What are the availability requirements?
  - Uptime SLA?
  - Acceptable downtime window?
  - Disaster recovery: RPO, RTO?

✅ What are the security requirements?
  - Data sensitivity classification?
  - Compliance needs (GDPR, HIPAA, etc.)?
  - Encryption requirements?
```

### Level 4: Cross-Cutting Concerns (STANDARD+ PATHS)

_Systematic gap checking across operational dimensions_

```
Questions to generate by category:

AUTHENTICATION & AUTHORIZATION:
✅ Who can access this feature?
✅ What's the permission model?
✅ Session management approach?
✅ API authentication mechanism?

ERROR HANDLING:
✅ What error categories exist?
✅ User-facing vs system error messages?
✅ Retry/recovery strategies?
✅ Error logging requirements?

MONITORING & DEBUGGING:
✅ What metrics should we track?
✅ What alerts should fire?
✅ What logging is needed for debugging?
✅ Distributed tracing requirements?

AUDIT & COMPLIANCE:
✅ What actions need audit logs?
✅ What data retention policies apply?
✅ What regulatory requirements exist?
```

### Level 5: Stakeholder Perspective Shift (COMPREHENSIVE PATH)

_Multi-role analysis to uncover role-specific requirements_

```
For each affected stakeholder type:
✅ From Ops perspective: What are monitoring/scaling/reliability needs?
✅ From Security perspective: What's the threat model?
✅ From Support perspective: What are debugging/troubleshooting needs?
✅ From QA perspective: How is this testable? What are test scenarios?
✅ From Analytics perspective: What events should we track?
✅ From Developer perspective: What integration points exist?
```

**Question Formulation Best Pr