simplerick0/requirements-engineering

Requirements Engineering

Capture, structure, and refine product ideas into implementable specifications.

Idea Capture Process

1. Problem Statement

Start every feature with the problem, not the solution:

PROBLEM: [What pain point exists?]
WHO: [Who experiences this?]
IMPACT: [What happens if unsolved?]

2. Solution Exploration

PROPOSED SOLUTION: [High-level approach]
ALTERNATIVES CONSIDERED: [Other options]
WHY THIS APPROACH: [Decision rationale]

3. Success Criteria

Define measurable outcomes before building:

• What does "done" look like?
• How will we know it's working?
• What metrics indicate success?

User Story Format

Standard Template

AS A [user type]
I WANT TO [action/goal]
SO THAT [benefit/value]

ACCEPTANCE CRITERIA:
- GIVEN [context] WHEN [action] THEN [outcome]
- GIVEN [context] WHEN [action] THEN [outcome]

Example

AS A registered user
I WANT TO reset my password via email
SO THAT I can regain access when I forget my credentials

ACCEPTANCE CRITERIA:
- GIVEN a valid email, WHEN I request reset, THEN I receive a link within 2 minutes
- GIVEN a reset link, WHEN I click it after 24 hours, THEN it shows expired
- GIVEN a valid reset link, WHEN I submit a new password, THEN I can log in immediately

Story Quality Checklist

• [ ] Independent (can be built separately)
• [ ] Negotiable (not overly prescriptive)
• [ ] Valuable (delivers user/business value)
• [ ] Estimable (can assess complexity)
• [ ] Small (fits in one iteration)
• [ ] Testable (clear pass/fail criteria)

Prioritization Frameworks

MoSCoW Method

| Category | Definition | Rule | |----------|------------|------| | Must | Critical for launch, non-negotiable | ~60% of effort | | Should | Important but not critical | ~20% of effort | | Could | Nice-to-have enhancements | ~20% of effort | | Won't | Explicitly out of scope (this time) | Document for later |

RICE Scoring

RICE Score = (Reach × Impact × Confidence) / Effort

Reach: Users affected per quarter (number)
Impact: 3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal
Confidence: 100%=high, 80%=medium, 50%=low
Effort: Person-weeks (or points)

Priority Matrix (Quick)

         High Impact    Low Impact
Low      ┌─────────────┬───────────┐
Effort   │  DO FIRST   │  FILL-IN  │
         ├─────────────┼───────────┤
High     │  SCHEDULE   │   DROP    │
Effort   └─────────────┴───────────┘

MVP Scoping

MVP Definition Questions

1. What is the smallest thing that proves/disproves our hypothesis?
2. What's the core value proposition?
3. What can users NOT do without?
4. What would we be embarrassed to ship without?

Scope Reduction Techniques

• Time-box: "What can we ship in 2 weeks?"
• User-limit: "What do our first 10 users need?"
• Feature-limit: "If we could only ship 3 features..."
• Manual-first: "What can we do manually before automating?"

MVP vs V1 Distinction

MVP: Validates the core assumption
- Minimum features to test hypothesis
- May use manual processes
- Focused on learning

V1: First real product
- Complete core workflows
- Production-ready quality
- Focused on delivering value

Requirements Document Template

# [Feature/Product Name]

## Overview
One paragraph explaining what this is and why it matters.

## Problem Statement
- Who has this problem?
- What is the current pain?
- What's the cost of not solving it?

## Proposed Solution
High-level description of the approach.

## User Stories
[List stories with acceptance criteria]

## Scope

### In Scope (MVP)
- [Must-have 1]
- [Must-have 2]

### In Scope (V1)
- [Should-have 1]
- [Could-have 1]

### Out of Scope
- [Won't-have with rationale]

## Open Questions
- [Unresolved decision 1]
- [Unresolved decision 2]

## Dependencies
- [External dependency or blocker]

## Success Metrics
- [Measurable outcome 1]
- [Measurable outcome 2]

Refinement Checklist

Before considering requirements "ready":

• [ ] Problem clearly articulated
• [ ] Target user identified
• [ ] Acceptance criteria defined
• [ ] Edge cases considered
• [ ] Scope boundaries explicit
• [ ] Dependencies identified
• [ ] Success metrics defined
• [ ] Technical feasibility validated