SDD Requirements Generation

Generate comprehensive, EARS-formatted requirements documents that integrate with the SDD (Spec-Driven Development) workflow.

Prerequisites

Before generating requirements:

1. Feature must be initialized with

   sdd-init

   MCP tool
2. Check current phase with

   sdd-status

   MCP tool
3. Review project steering documents in

   .spec/steering/

Workflow

Step 1: Gather Context

1. Use

   sdd-status

   MCP tool to verify feature exists and check current phase
2. Read project context from

   .spec/steering/product.md

   if available
3. Review the feature description from

   .spec/specs/{feature}/spec.json

Step 2: Analyze Requirements

Identify and document:

• Primary user goal: What problem are we solving?
• Target users: Who will use this feature?
• Core functionality: What must the system do?
• Success criteria: How do we know it works?

Step 3: Generate EARS-Formatted Requirements

Use the EARS (Easy Approach to Requirements Syntax) format for all requirements.

EARS Patterns

The <system> SHALL <action>

WHEN <trigger> THEN the <system> SHALL <action>

WHILE <state> THE <system> SHALL <action>

WHERE <feature enabled> THE <system> SHALL <action>

IF <condition> THEN the <system> SHALL <action>

Examples

## FR-1: User Authentication
WHEN a user submits valid credentials
THEN the system SHALL authenticate the user and return a session token

## FR-2: Session Management
WHILE a user session is active
THE system SHALL maintain the session for up to 24 hours of inactivity

## NFR-1: Performance
The system SHALL respond to authentication requests within 200ms

Step 4: Structure the Document

Generate requirements.md with this structure:

# Requirements: {Feature Name}

## Overview
Brief description of the feature and its purpose.

## Functional Requirements

### FR-1: {Requirement Name}
**Objective:** As a {user type}, I want {goal}, so that {benefit}

**EARS Specification:**
WHEN {trigger}
THEN the system SHALL {action}

**Acceptance Criteria:**
1. {Specific, testable criterion}
2. {Specific, testable criterion}

### FR-2: {Next Requirement}
...

## Non-Functional Requirements

### NFR-1: Performance
{Performance requirements with specific metrics}

### NFR-2: Security
{Security requirements aligned with OWASP guidelines}

### NFR-3: Scalability
{Scalability requirements if applicable}

## Constraints
{Technical or business constraints}

## Assumptions
{Assumptions made during requirements gathering}

Step 5: Validate and Save

After generating requirements:

1. Ensure all requirements are testable
2. Verify EARS format is correctly applied
3. Save to

   .spec/specs/{feature}/requirements.md

4. Use

   sdd-approve

   MCP tool to mark phase complete when ready

MCP Tool Integration

This skill works with these MCP tools:

sdd-status

sdd-validate-gap

sdd-approve

Quality Checklist

Before completing requirements:

• All requirements use EARS format
• Each requirement is independently testable
• Acceptance criteria are specific and measurable
• Security requirements align with OWASP Top 10
• Performance requirements have specific metrics
• Requirements are traceable to user stories
• No ambiguous terms (avoid "should", "may", "might")
• Each FR has clear acceptance criteria

Steering Document References

Apply these steering documents during requirements generation:

.spec/steering/principles.md

Key Principles for Requirements:

• KISS: Keep requirements simple and unambiguous
• YAGNI: Only specify what's actually needed now
• Single Responsibility: Each requirement addresses one concern