Requirements Engineering
Transform raw requirements into structured, testable specifications that guide development teams.
When to Use
- Creating feature requirements documents
- Writing user stories with acceptance criteria
- Defining business rules and constraints
- Documenting process flows
- Prioritizing features (MoSCoW, RICE)
- Analyzing stakeholder needs
Requirements Document Structure
A complete requirements document includes:
- Feature Overview - Business context and success metrics
- User Stories - Who, what, why format
- Acceptance Criteria - Given/When/Then scenarios
- Data Model - Fields, types, constraints
- Business Rules - BR-XXX format
- Permission Requirements - Role-based access
- Open Questions - Items needing clarification
Core Templates
User Story Format
**US-[XXX]: [Title]**
As a [role],
I want to [action],
So that [benefit].
**Acceptance Criteria:**
- [ ] Given [context], when [action], then [expected result]
- [ ] Given [context], when [action], then [expected result]
- [ ] Given [context], when [action], then [expected result]
**Priority**: Must Have | Should Have | Could Have | Won't Have
**Effort**: S (1-2 days) | M (3-5 days) | L (1-2 weeks) | XL (2+ weeks)
**Dependencies**: [List any dependent stories]Acceptance Criteria Patterns
Happy Path:
Given a logged-in [role]
When they [perform action] with valid [inputs]
Then [expected success outcome]
And [side effects if any]Validation Error:
Given a logged-in [role]
When they [perform action] with invalid [input type]
Then the system displays "[error message]"
And [the operation is not completed]Authorization:
Given a user without [permission]
When they attempt to [perform action]
Then the system returns 403 Forbidden
And [logs the unauthorized attempt]Edge Case:
Given [edge condition exists]
When [action is performed]
Then [graceful handling occurs]Business Rule Format
Full format: See domain-modeling skill for detailed patterns and categories.
Quick format for requirements:
| ID | Rule | Enforcement | Impact |
|---|---|---|---|
| BR-{CAT}-001 | [Rule description] | [Create/Update/Delete] | [Reject with error] |
Data Model Template
Full entity modeling: See domain-modeling skill for complete entity definitions with relationships, state transitions, and API access.
Quick format for requirements:
| Field | Type | Required | Constraints | Description |
|---|---|---|---|---|
| Id | Guid | Yes | PK | Unique identifier |
| Name | string | Yes | Max 100 chars | Display name |
| string | Yes | Valid email, Unique | Contact email | |
| Status | enum | Yes | Active/Inactive | Current state |
Process Flow Template
## Process: [Process Name]
### Actors
| Actor | Role | Responsibility |
|-------|------|----------------|
| [Role 1] | [Title] | [What they do] |
| [Role 2] | [Title] | [What they do] |
### Flow
1. **[Actor]** initiates [action]
2. **System** validates [criteria]
3. If valid:
a. [Success step 1]
b. [Success step 2]
c. [Notification/confirmation]
4. If invalid:
a. [Error handling]
b. [User feedback]
### Business Rules Applied
- BR-001: [Rule applied at step X]
- BR-002: [Rule applied at step Y]Prioritization Methods
MoSCoW Method
| Priority | Meaning | Guideline |
|---|---|---|
| Must Have | Critical for launch | ~60% of effort |
| Should Have | Important but not critical | ~20% of effort |
| Could Have | Nice to have | ~20% of effort |
| Won't Have | Out of scope for this release | Document for future |
RICE Scoring
RICE Score = (Reach × Impact × Confidence) / Effort
Reach: How many users affected per quarter (number)
Impact: Effect on each user (3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal)
Confidence: How sure are we (100%=high, 80%=medium, 50%=low)
Effort: Person-months to complete (number)Quality Checklist
Before finalizing requirements:
- At least 3 user stories defined
- Each story has 2+ acceptance criteria
- Acceptance criteria are testable (Given/When/Then)
- Data model includes all fields with types
- Business rules are numbered and documented
- Permissions align with existing roles
- Open questions are captured
- Priority assigned to each story
- Dependencies identified
Integration with Domain Modeling
When creating requirements, always consider domain impact:
- Before writing requirements: Review existing domain in
docs/domain/ - During analysis: Identify new/modified entities, rules, permissions
- After requirements: Create impact analysis using
domain-modelingskill
The business-analyst agent combines requirements-engineering with domain-modeling for complete analysis.
References
- references/user-story-examples.md - Real-world examples
- references/acceptance-criteria-patterns.md - Common patterns