---

name: requirements-elicitation description: Structured process for gathering, clarifying, documenting, and planning software requirements. Use when starting a new project, feature, or task that needs requirements gathering, when user needs are unclear, when creating specifications or user stories, or when planning implementation from vague requests.

Requirements Elicitation

Systematic approach to understanding what needs to be built before building it.

Process Overview

Copy1. GATHER    → Understand the problem and context
2. CLARIFY   → Ask targeted questions to fill gaps
3. DOCUMENT  → Create structured requirements
4. VALIDATE  → Confirm understanding with stakeholder
5. PLAN      → Break down into actionable tasks

Phase 1: Gather

Initial Information Collection

Start by extracting all available information from the request:

Ask yourself:

• What is the user trying to accomplish? (Goal)
• Who will use this? (Users/Actors)
• What triggered this need? (Context)
• What does success look like? (Acceptance criteria)
• What constraints exist? (Technical, timeline, budget)

Information Extraction Template

Copy## Initial Understanding

**Goal**: [What the user wants to achieve]
**Context**: [Why this is needed now]
**Users**: [Who will interact with this]
**Scope**: [What's included/excluded]

## Known Requirements
- [Explicit requirement 1]
- [Explicit requirement 2]

## Assumptions
- [Assumption that needs validation]

## Open Questions
- [Question about unclear aspect]

Phase 2: Clarify

Question Categories

Ask questions in priority order:

1. Functional Requirements (What it does)

• "What actions should users be able to perform?"
• "What happens when [trigger event]?"
• "What information needs to be displayed/stored?"
• "What are the inputs and outputs?"

2. User Requirements (Who uses it)

• "Who are the primary users?"
• "What is their technical skill level?"
• "How frequently will they use this?"
• "What problems are they currently facing?"

3. Business Requirements (Why it matters)

• "What business problem does this solve?"
• "How will success be measured?"
• "What's the priority relative to other work?"
• "What's the cost of not doing this?"

4. Non-Functional Requirements (How it performs)

• "What performance expectations exist?"
• "What security requirements apply?"
• "What accessibility needs exist?"
• "What devices/browsers must be supported?"

5. Constraints & Dependencies

• "What existing systems does this interact with?"
• "What technical constraints exist?"
• "What timeline constraints exist?"
• "What budget constraints exist?"

Question Techniques

Open-ended questions for exploration:

• "Tell me more about..."
• "What does [term] mean in your context?"
• "Walk me through a typical scenario..."

Closed questions for confirmation:

• "Should X happen before or after Y?"
• "Is [specific behavior] correct?"
• "Does this need to support [specific case]?"

Scenario questions for edge cases:

• "What happens if the user does X?"
• "What if [error condition] occurs?"
• "How should this behave when [boundary case]?"

Avoid Question Overload

Batch questions strategically:

• Ask 2-4 questions maximum per interaction
• Group related questions together
• Prioritize blocking questions first
• Save nice-to-know questions for later

Phase 3: Document

Requirements Document Structure

Copy# [Feature/Project Name] Requirements

## Overview
Brief description of what's being built and why.

## Goals
- Primary goal
- Secondary goals

## Users
| User Type | Description | Key Needs |
|-----------|-------------|-----------|
| Primary   | ...         | ...       |
| Secondary | ...         | ...       |

## Functional Requirements

### FR-1: [Requirement Name]
**Description**: [What the system should do]
**Acceptance Criteria**:
- [ ] Given [context], when [action], then [result]
- [ ] ...
**Priority**: Must Have / Should Have / Nice to Have

### FR-2: [Requirement Name]
...

## Non-Functional Requirements

### NFR-1: Performance
- [Specific performance requirement]

### NFR-2: Security
- [Specific security requirement]

## Constraints
- [Technical constraint]
- [Timeline constraint]

## Out of Scope
- [Explicitly excluded item]

## Open Questions
- [Remaining uncertainty]

## Assumptions
- [Assumption being made]

User Story Format

For agile contexts, use user stories:

Copy**As a** [user type]
**I want** [goal/action]
**So that** [benefit/reason]

**Acceptance Criteria:**
- Given [context], when [action], then [expected result]
- Given [context], when [action], then [expected result]

**Notes:**
- [Additional context]
- [Edge case handling]

MoSCoW Prioritization

Categorize requirements:

• Must Have: Critical for delivery, non-negotiable
• Should Have: Important but not critical
• Could Have: Desirable if time permits
• Won't Have: Explicitly out of scope for now

Phase 4: Validate

Confirmation Checklist

Before proceeding, confirm:

• Stakeholder agrees with documented requirements
• Acceptance criteria are clear and testable
• Scope is explicitly defined (including exclusions)
• Priorities are agreed upon
• Constraints are understood
• Dependencies are identified
• Open questions are resolved or acknowledged

Validation Techniques

Summarize back: "Let me confirm my understanding..."

Prototype early: "Here's a rough outline/mockup..."

Walk through scenarios: "If a user wants to X, they would..."

Confirm priorities: "So the most important feature is X, followed by Y?"

Phase 5: Plan

Task Breakdown

Convert requirements to implementation tasks:

Copy## Implementation Plan

### Phase 1: Foundation
- [ ] Task 1.1: [Description] - Implements FR-1
- [ ] Task 1.2: [Description]

### Phase 2: Core Features
- [ ] Task 2.1: [Description] - Implements FR-2, FR-3
- [ ] Task 2.2: [Description]

### Phase 3: Polish
- [ ] Task 3.1: [Description]
- [ ] Task 3.2: [Description]

### Dependencies
- Task 2.1 depends on Task 1.1
- Task 3.1 depends on Task 2.2

Estimation Factors

Consider when breaking down work:

• Complexity of implementation
• Integration with existing code
• Testing requirements
• Documentation needs
• Review/feedback cycles

Quick Reference

Minimum Viable Requirements

For any feature, capture at minimum:

1. What: Clear description of the functionality
2. Who: Target user(s)
3. Why: Business/user value
4. How to verify: Acceptance criteria
5. Priority: Relative importance

Red Flags to Address

Stop and clarify if you encounter:

• Vague terms ("make it better", "user-friendly")
• Conflicting requirements
• Unstated assumptions
• Missing user context
• No success criteria
• Scope creep indicators ("and also...")

Templates Quick Access

• references/requirements-template.md - Full requirements document template
• references/user-story-template.md - User story templates
• references/question-bank.md - Categorized clarifying questions