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

Email string Yes Valid email, Unique Contact email

Status enum Yes Active/Inactive Current state

Process Flow Template

Process: [Process Name]

Actors

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