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

markdown

**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:

code

Given a logged-in [role]
When they [perform action] with valid [inputs]
Then [expected success outcome]
And [side effects if any]

Validation Error:

code

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:

code

Given a user without [permission]
When they attempt to [perform action]
Then the system returns 403 Forbidden
And [logs the unauthorized attempt]

Edge Case:

code

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
Email	string	Yes	Valid email, Unique	Contact email
Status	enum	Yes	Active/Inactive	Current state

Process Flow Template

markdown

## 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

code

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-modeling skill

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