requirements-gathering

Requirements Gathering

Overview

This skill guides you through systematic requirements gathering and documentation for software projects, from initial stakeholder analysis to detailed specifications and acceptance criteria.

Requirements Gathering Workflow

1. Planning & Stakeholder Analysis

Identify Stakeholders:

• Map stakeholder categories: executives, users, developers, operations
• Assess influence, interest, and availability
• Plan engagement strategy for each stakeholder group

Select Elicitation Techniques:

• Interviews: One-on-one discussions for deep insights (see elicitation-techniques.md)
• Workshops: Collaborative sessions for alignment
• Document Analysis: Review existing systems and documentation
• Observation: Job shadowing to understand workflows
• Surveys: Gather input from large user groups
• Prototyping: Validate requirements with mockups

2. Requirements Elicitation

Conduct Stakeholder Sessions:

• Prepare structured interview questions
• Focus on current pain points and desired outcomes
• Document business context, goals, and constraints
• Capture exact quotes for later reference
• Follow up with clarifications as needed

Key Questions to Ask:

• What problems are you trying to solve?
• What does success look like?
• Who will use this system and how?
• What are your constraints (budget, timeline, technical)?
• What are must-have vs nice-to-have features?

3. Requirements Analysis & Documentation

Document Requirements:

Choose format based on project methodology:

For Agile Projects - Use user stories (see agile-requirements.md):

As a [role]
I want [capability]
So that [business value]

Acceptance Criteria:
- Given [context]
- When [action]
- Then [outcome]

For Traditional Projects - Use structured specifications:

• Business Requirements Document (BRD): High-level business needs
• Functional Requirements: What system must do
• Non-Functional Requirements: Performance, security, usability
• Use Cases: Detailed user-system interactions

Classify Requirements:

• Functional vs Non-Functional
• Business vs Technical vs User
• Must-Have vs Should-Have vs Could-Have vs Won't-Have (MoSCoW)

4. Requirements Prioritization

Apply Prioritization Framework (see prioritization-frameworks.md):

• MoSCoW: Must/Should/Could/Won't have (good for stakeholder alignment)
• Value vs Effort: Plot on 2×2 matrix (quick wins vs long-term investments)
• RICE: Reach × Impact × Confidence / Effort (data-driven scoring)
• Kano Model: Basic/Performance/Delight features (user satisfaction focus)

5. Validation & Refinement

Review Requirements Quality:

• Clear: Unambiguous, easy to understand
• Complete: All necessary information included
• Consistent: No contradictions
• Testable: Can verify when implemented
• Feasible: Technically and economically viable
• Traceable: Linked to business goals

Get Stakeholder Sign-Off:

• Review with each stakeholder group
• Address conflicts and gaps
• Document approvals and changes
• Maintain requirements traceability matrix

Key Deliverables

Depending on project needs, produce:

• Stakeholder Analysis: Categories, needs, engagement plan
• Interview Summaries: Key findings and quotes
• User Stories/Use Cases: Detailed functionality descriptions
• Requirements Document: BRD, SRS, or PRD
• Requirements Traceability Matrix: Links requirements to business goals, design, tests
• Product Roadmap: Prioritized feature timeline

Reference Files

Load these on demand based on specific needs:

Process Guidance

• elicitation-techniques.md - Detailed interview techniques, workshop facilitation, and observation methods
• agile-requirements.md - User story writing, backlog management, sprint planning, and acceptance criteria
• prioritization-frameworks.md - MoSCoW, RICE, Kano, Value/Effort frameworks with examples
• requirements-gathering-process.md - End-to-end process from initiation to sign-off
• best-practices.md - Quality standards, common pitfalls, and validation checklists

Documentation Templates

• requirements-traceability-matrix.md - Template and examples for tracking requirements
• use-case-overview.md - Use case structure and examples

Best Practices Summary

Avoid Common Pitfalls:

• ❌ Solution-focused: "Use React framework" → ✅ "Provide responsive web interface"
• ❌ Vague language: "System should be fast" → ✅ "System responds within 2 seconds for 95% of requests"
• ❌ Gold plating: Focus on business value, not nice-to-haves
• ❌ Assuming knowledge: Document all assumptions and define terms
• ❌ Skipping validation: Always review and get stakeholder sign-off

Requirements Quality: Every requirement must be clear, complete, consistent, testable, feasible, necessary, prioritized, and traceable.