authoring-requirements

# Authoring Requirements

## Overview

Write technology-agnostic functional requirements, identify edge cases, and define measurable success criteria. Focus on WHAT the system does and WHY, never HOW it's implemented.

## When to Use

- Starting a new feature specification
- Documenting acceptance criteria for user stories
- Defining API contracts at the business logic level
- Creating requirements for stakeholder review
- When existing requirements are vague or missing structure
- Translating informal feature requests into formal requirements

## When NOT to Use

- **Implementation planning** - Use design docs or architecture decisions instead
- **Technical architecture decisions** - Use ADRs or technical design documents
- **When requirements already exist and are validated** - Don't duplicate work
- **API endpoint specifications** - Use `humaninloop:patterns-api-contracts` instead
- **Data model design** - Use `humaninloop:patterns-entity-modeling` instead
- **User story authoring** - Use `humaninloop:authoring-user-stories` instead (this skill focuses on the underlying requirements)

## Functional Requirements Format

Write requirements using the FR-XXX format with RFC 2119 keywords:

```markdown
## Functional Requirements

- **FR-001**: System MUST [specific capability]
- **FR-002**: Users MUST be able to [specific action]
- **FR-003**: System SHOULD [recommended behavior]
- **FR-004**: System MAY [optional capability]
```

### RFC 2119 Keywords

| Keyword | Meaning |
|---------|---------|
| **MUST** | Absolute requirement; no exceptions |
| **SHOULD** | Recommended; valid exceptions may exist |
| **MAY** | Optional; implementation choice |

See [RFC-2119-KEYWORDS.md](references/RFC-2119-KEYWORDS.md) for detailed usage guidance.

### FR Numbering Rules

1. Sequential numbering: FR-001, FR-002, FR-003...
2. No gaps in sequence
3. Three-digit padding (001, not 1)
4. Group related requirements together

### Writing Technology-Agnostic Requirements

**Good (what):*