requirements-gathering

Requirements Gathering

Table of Contents

• Overview
• When to Use
• Quick Start
• Reference Guides
• Best Practices

Overview

Effective requirements gathering establishes a shared understanding of what will be built, preventing misalignment and expensive changes later in the project.

When to Use

• Project kickoff and planning
• Feature development initiation
• Product roadmap planning
• System modernization projects
• Customer discovery
• Stakeholder alignment sessions
• Writing user stories and acceptance criteria

Quick Start

Minimal working example:

# Identify and analyze stakeholders
 
class StakeholderDiscovery:
    STAKEHOLDER_CATEGORIES = [

Reference Guides

Detailed implementations in the references/ directory:

Best Practices

✅ DO

• Engage all key stakeholders early
• Document requirements in writing
• Use specific, measurable language
• Define acceptance criteria
• Prioritize using MoSCoW method
• Get stakeholder sign-off
• Create traceability matrix
• Review requirements regularly
• Distinguish must-haves from nice-to-haves
• Document assumptions and constraints

❌ DON'T

• Rely on memory or verbal agreements
• Create requirements without stakeholder input
• Use ambiguous language (quickly, easily, etc.)
• Skip non-functional requirements
• Ignore constraints and dependencies
• Over-document trivial details
• Rush through requirements phase
• Build without stakeholder agreement
• Make scope changes without process
• Forget about edge cases and error conditions