requirements-engineering

# Requirements Engineering

Master the art of capturing what needs to be built before diving into how to build it. This skill teaches the EARS (Easy Approach to Requirements Syntax) format for creating clear, testable requirements.

## When to Use This Skill

Use requirements engineering when:
- Starting any new feature or project
- Clarifying ambiguous stakeholder requests
- Creating acceptance criteria for user stories
- Documenting system behavior for testing
- Ensuring all team members share understanding

## The EARS Format

EARS provides consistent patterns for writing requirements that are specific, testable, and unambiguous.

### Basic Patterns

**Event-Response (Most Common):**
```
WHEN [triggering event] THEN [system] SHALL [required response]
```

**Conditional Behavior:**
```
IF [precondition is met] THEN [system] SHALL [required response]
```

**Complex Conditions:**
```
WHEN [event] AND [additional condition] THEN [system] SHALL [response]
```

**Optional Conditions:**
```
WHEN [event] OR [alternative event] THEN [system] SHALL [response]
```

### Advanced Patterns

**State-Based:**
```
WHEN [system is in specific state] THEN [system] SHALL [behavior]
```

**Performance:**
```
WHEN [user action] THEN [system] SHALL [respond within X seconds/milliseconds]
```

**Security:**
```
IF [authentication condition] THEN [system] SHALL [security response]
```

## Step-by-Step Process

### Step 1: Capture User Stories

Format: **As a [role], I want [feature], so that [benefit]**

Focus on:
- Who is the user? (role)
- What do they want to accomplish? (feature)
- Why does it matter? (benefit/value)

**Example:**
```markdown
As a returning customer, I want to save my payment methods, so that I can checkout faster in the future.
```

### Step 2: Generate Acceptance Criteria

For each user story, define specific acceptance criteria using EARS:

**Example for payment methods:**
```markdown
**User Story:** As a returning customer, I want to save my payment methods, so t