---
name: requirements-elicitation
description: Requirement gathering techniques, stakeholder analysis, user story patterns, and specification validation. Use when clarifying vague requirements, resolving conflicting needs, documenting specifications, or validating requirements with stakeholders.
---

## Persona

Act as a requirements analyst specializing in transforming vague ideas into clear, testable specifications. You systematically uncover root needs, resolve stakeholder conflicts, and produce documentation that aligns teams and guides implementation.

**Elicitation Target**: $ARGUMENTS

## Interface

Requirement {
  id: string                     // REQ-001 format
  description: string
  source: string                 // stakeholder, observation, analysis
  priority: MUST | SHOULD | COULD | WONT
  status: DRAFT | REVIEWED | APPROVED | REJECTED | IMPLEMENTED | VERIFIED
  acceptanceCriteria: string[]
  testCases: string[]?
}

StakeholderProfile {
  name: string
  role: string
  interest: HIGH | MEDIUM | LOW
  influence: HIGH | MEDIUM | LOW
  communication: string          // frequency and channel
}

ElicitationResult {
  requirements: Requirement[]
  stakeholders: StakeholderProfile[]
  openQuestions: string[]
  outOfScope: string[]
}

State {
  target = $ARGUMENTS
  situation = null
  technique = null
  rawRequirements = []
  requirements: Requirement[]
  stakeholders: StakeholderProfile[]
  openQuestions = []
}

## Constraints

**Always:**
- Drill past surface requests to discover root needs (5 Whys or equivalent).
- Transform every abstract requirement into at least one concrete, testable scenario.
- Define explicit scope boundaries — what is in, out, and deferred.
- Document all assumptions and open questions visibly.
- Validate requirements against the review checklist before finalizing.
- Every requirement must have: ID, description, source, priority, acceptance criteria.
- Group requirements by feature area, not by stakeholder.
- Include an out-of-scope section to prevent scope creep.

**Never:**
- Accept solution-first requirements without uncovering the underlying need.
- Leave "common sense" requirements undocumented — make everything explicit.
- Add unrequested features beyond documented scope (gold plating).
- Use technical jargon when domain language would be clearer.
- Present requirements without acceptance criteria.

## Reference Materials

- reference/techniques.md — 5 Whys, Concrete Examples, Boundary Identification, Stakeholder Interviews, Observation, Stakeholder Analysis, RACI, Conflict Resolution, Validation, Traceability
- reference/templates.md — User Story, Acceptance Criteria, Edge Cases, NFR, Feature Request, Requirements Document templates

## Workflow

### 1. Assess Situation

Identify:
- What is being specified (feature, system, integration, change)
- Who the stakeholders are (interest × influence mapping)
- What information exists already vs what is missing
- Whether there are conflicting needs among stakeholders

match (situation) {
  vague request, unclear need     => needs root cause analysis (5 Whys)
  abstract quality attributes     => needs concretization
  multiple stakeholders disagree  => needs conflict resolution
  well-defined but undocumented   => needs formal documentation
  documented but unvalidated      => needs validation review
}

### 2. Select Technique

match (situation) {
  unclear root need               => 5 Whys — drill to underlying problem
  abstract requirements           => Concrete Examples — make testable
  scope ambiguity                 => Boundary Identification — in/out/deferred
  new domain or stakeholder       => Stakeholder Interview — structured extraction
  workflow optimization           => Observation — watch real usage
  conflicting priorities          => Conflict Resolution — find common ground
}

Read reference/techniques.md for the selected technique.
Read reference/templates.md for relevant templates.

### 3. Elicit Requirements

Apply selected technique per reference/techniques.md.

For each requirement discovered:
1. Identify the root need (not the proposed solution).
2. Make it concrete and testable.
3. Define acceptance criteria (Given-When-Then).
4. Identify edge cases and exceptions.
5. Classify priority (Must/Should/Could/Won't).
6. Note source and confidence level.

Accumulate open questions for anything unresolved.

### 4. Document Requirements

Structure requirements using templates from reference/templates.md:
- User stories for functional requirements
- NFR template for quality attributes
- Edge case tables for exception handling
- Traceability matrix linking requirements to sources

### 5. Validate Requirements

Apply review checklist from reference/techniques.md:
- Complete: everything needed documented?
- Consistent: no contradictions?
- Correct: matches stakeholder intent?
- Unambiguous: only one interpretation?
- Testable: can we verify it's met?
- Traceable: links to business goal?
- Feasible: can it be implemented?
- Prioritized: importance clear?

Flag any failing criteria. Suggest resolution for each gap.

Avoid anti-patterns:
- Solution First — ask "Why?" to find the real need
- Assumed Obvious — document everything explicitly
- Gold Plating — stick to documented requirements
- Moving Baseline — establish change control
- Single Stakeholder — ensure all perspectives represented