home / skills / eyadsibai / ltk / requirements-engineering

requirements-engineering skill

safe

/plugins/ltk-engineering/skills/requirements-engineering

This skill helps you capture clear outcomes with EARS and user stories, guiding product definition before design and development.

npx playbooks add skill eyadsibai/ltk --skill requirements-engineering

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

4.3 KB

---
name: requirements-engineering
description: Use when "requirements document", "acceptance criteria", "user stories", "EARS format", "specification", "feature spec", "product requirements"
version: 1.0.0
---

# Requirements Engineering

Structured approaches for capturing what to build before how to build it.

---

## Core Principle

**Specify WHAT, not HOW.** Requirements describe outcomes and behaviors, not implementation details.

---

## EARS Format

**Easy Approach to Requirements Syntax** - structured acceptance criteria.

| Pattern | Template | Use Case |
|---------|----------|----------|
| **Event-driven** | WHEN [event] THEN [system] SHALL [response] | User actions, triggers |
| **Conditional** | IF [condition] THEN [system] SHALL [response] | Business rules |
| **State-driven** | WHILE [state] [system] SHALL [response] | Ongoing behaviors |
| **Ubiquitous** | WHERE [feature] [system] SHALL [response] | Always-true rules |
| **Unconditional** | [system] SHALL [response] | Basic capabilities |

### Examples

| Type | Example |
|------|---------|
| Event | WHEN user clicks "Submit" THEN system SHALL validate all required fields |
| Conditional | IF user is not authenticated THEN system SHALL redirect to login |
| State | WHILE file is uploading system SHALL display progress indicator |
| Ubiquitous | WHERE data is displayed system SHALL use consistent date format |

---

## User Story Format

```
As a [role]
I want [capability]
So that [benefit]
```

### Good vs Bad

| Bad | Good |
|-----|------|
| As a user I want to login | As a returning customer I want to login with my email so that I can access my order history |
| As a user I want a button | As a content creator I want a publish button so that I can share my work publicly |

**Key concept**: The "so that" clause reveals the actual need - often the stated "want" isn't what's really needed.

---

## Requirements Document Structure

| Section | Content |
|---------|---------|
| **Problem Statement** | What problem are we solving? |
| **User Stories** | Who wants what and why? |
| **Acceptance Criteria** | How do we know it's done? (EARS) |
| **Non-Functional** | Performance, security, accessibility |
| **Out of Scope** | What we're NOT building |
| **Success Metrics** | How do we measure success? |

---

## Constitution (Governing Principles)

For complex projects, establish guiding principles before features:

| Element | Purpose |
|---------|---------|
| **Core Values** | What matters most (simplicity > cleverness) |
| **Technical Principles** | Architecture standards |
| **Decision Framework** | How to make trade-offs |
| **Quality Standards** | Testing, review requirements |

**Key concept**: Constitution prevents scope creep and ensures consistency across features.

---

## Clarification Techniques

Before implementation, resolve ambiguities:

| Technique | When to Use |
|-----------|-------------|
| **Ask "what if"** | Edge cases, error scenarios |
| **Present options** | Multiple valid approaches |
| **Challenge assumptions** | "Is this actually required?" |
| **Define boundaries** | What's in/out of scope |

### Questions to Ask

- What happens when [edge case]?
- What does success look like?
- What's the minimum viable version?
- What can we defer to later?

---

## Non-Functional Requirements

| Category | Questions to Answer |
|----------|---------------------|
| **Performance** | Response time? Throughput? Concurrent users? |
| **Security** | Authentication? Authorization? Data protection? |
| **Accessibility** | WCAG level? Screen reader support? |
| **Scalability** | Expected growth? Peak load? |
| **Reliability** | Uptime requirements? Recovery time? |

---

## Anti-Patterns

| Don't | Why |
|-------|-----|
| Specify implementation | "Use React" locks in decisions |
| Assume requirements | Validate with stakeholders |
| Skip edge cases | They become bugs later |
| Mix requirements with design | Conflates what with how |
| Write vague criteria | "System should be fast" is untestable |

---

## Testable vs Untestable

| Untestable | Testable |
|------------|----------|
| "Fast response" | "Response under 200ms" |
| "User-friendly" | "Task completable in <3 clicks" |
| "Secure" | "Passwords hashed with bcrypt" |
| "Scalable" | "Handles 10K concurrent users" |

**Key concept**: If you can't write a test for it, it's not a requirement - it's a wish.

Overview

This skill packages concise guidance and templates for writing clear, testable product requirements and acceptance criteria. It focuses on outcome-driven specifications, EARS acceptance patterns, and user story structure to help teams capture what to build without prescribing how to build it. Use it to produce requirements that are verifiable, scoped, and stakeholder-aligned.

How this skill works

The skill inspects a draft requirement or feature description and maps it to proven templates: EARS patterns for acceptance criteria, the user story format for intent, and a standard requirements document structure for organization. It identifies vague or implementation-bound language, suggests testable alternatives, and prompts clarifying questions for edge cases and non-functional needs. It also recommends governing principles (a project constitution) to keep requirements consistent across features.

When to use it

Drafting feature specs or product requirements before development
Writing acceptance criteria for user stories or tickets
Turning stakeholder requests into testable requirements
Reviewing requirements for ambiguity, scope creep, or hidden assumptions
Defining non-functional requirements like performance or security

Best practices

Specify WHAT, not HOW — avoid implementation details in requirements
Use EARS patterns (WHEN/IF/WHILE/WHERE/SHALL) for clear acceptance criteria
Include a concise problem statement and out-of-scope section to limit scope creep
Make non-functional requirements specific and measurable (e.g., 200ms response)
Use 'so that' in user stories to capture real user benefit and intent

Example use cases

Convert a stakeholder email into a user story with EARS-formatted acceptance criteria
Review a backlog of tickets to flag implementation language and propose testable rewrites
Create a requirements document with problem statement, success metrics, and out-of-scope items
Define security and performance requirements before handoff to engineering
Run a clarification checklist with product, design, and QA to resolve edge cases

FAQ

How do I decide between EARS patterns?

Choose the pattern that matches the trigger: Event-driven for user actions, Conditional for business rules, State-driven for ongoing behavior, Ubiquitous for always-true rules, and Unconditional for basic capabilities.

What if stakeholders insist on implementation details?

Capture the desired outcome as the requirement and note the suggested implementation in a separate design decision or technical appendix so the requirement stays implementation-agnostic.