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:
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.
1---2name: requirements-gathering3description: Guides comprehensive requirements gathering and analysis including stakeholder interviews, user story creation, use case documentation, acceptance criteria, requirements prioritization, and traceability. Produces requirements documents, user stories, use cases, and development roadmaps. Use when gathering requirements, writing user stories, creating acceptance criteria, analyzing stakeholder needs, prioritizing features, or when users mention requirements analysis, business analysis, user stories, use cases, or requirements documentation.4---5
6# Requirements Gathering
7
8## Overview
9
10This skill guides you through systematic requirements gathering and documentation for software projects, from initial stakeholder analysis to detailed specifications and acceptance criteria.
11
12## Requirements Gathering Workflow
13
14## 1. Planning & Stakeholder Analysis
15
16**Identify Stakeholders:**
17
18- Map stakeholder categories: executives, users, developers, operations
19- Assess influence, interest, and availability
20- Plan engagement strategy for each stakeholder group
21
22**Select Elicitation Techniques:**
23
24- **Interviews**: One-on-one discussions for deep insights (see [elicitation-techniques.md](references/elicitation-techniques.md))
25- **Workshops**: Collaborative sessions for alignment
26- **Document Analysis**: Review existing systems and documentation
27- **Observation**: Job shadowing to understand workflows
28- **Surveys**: Gather input from large user groups
29- **Prototyping**: Validate requirements with mockups
30
31### 2. Requirements Elicitation
32
33**Conduct Stakeholder Sessions:**
34
35- Prepare structured interview questions
36- Focus on current pain points and desired outcomes
37- Document business context, goals, and constraints
38- Capture exact quotes for later reference
39- Follow up with clarifications as needed
40
41**Key Questions to Ask:**
42
43- What problems are you trying to solve?
44- What does success look like?
45- Who will use this system and how?
46- What are your constraints (budget, timeline, technical)?
47- What are must-have vs nice-to-have features?
48
49### 3. Requirements Analysis & Documentation
50
51**Document Requirements:**
52
53Choose format based on project methodology:
54
55**For Agile Projects** - Use user stories (see [agile-requirements.md](references/agile-requirements.md)):
56
57```
58As a [role]
59I want [capability]
60So that [business value]
61
62Acceptance Criteria:
63- Given [context]
64- When [action]
65- Then [outcome]
66```
67
68**For Traditional Projects** - Use structured specifications:
69
70- Business Requirements Document (BRD): High-level business needs
71- Functional Requirements: What system must do
72- Non-Functional Requirements: Performance, security, usability
73- Use Cases: Detailed user-system interactions
74
75**Classify Requirements:**
76
77- Functional vs Non-Functional
78- Business vs Technical vs User
79- Must-Have vs Should-Have vs Could-Have vs Won't-Have (MoSCoW)
80
81### 4. Requirements Prioritization
82
83**Apply Prioritization Framework** (see [prioritization-frameworks.md](references/prioritization-frameworks.md)):
84
85- **MoSCoW**: Must/Should/Could/Won't have (good for stakeholder alignment)
86- **Value vs Effort**: Plot on 2×2 matrix (quick wins vs long-term investments)
87- **RICE**: Reach × Impact × Confidence / Effort (data-driven scoring)
88- **Kano Model**: Basic/Performance/Delight features (user satisfaction focus)
89
90### 5. Validation & Refinement
91
92**Review Requirements Quality:**
93
94- [ ] **Clear**: Unambiguous, easy to understand
95- [ ] **Complete**: All necessary information included
96- [ ] **Consistent**: No contradictions
97- [ ] **Testable**: Can verify when implemented
98- [ ] **Feasible**: Technically and economically viable
99- [ ] **Traceable**: Linked to business goals
100
101**Get Stakeholder Sign-Off:**
102
103- Review with each stakeholder group
104- Address conflicts and gaps
105- Document approvals and changes
106- Maintain requirements traceability matrix
107
108## Key Deliverables
109
110**Depending on project needs, produce:**
111
112- **Stakeholder Analysis**: Categories, needs, engagement plan
113- **Interview Summaries**: Key findings and quotes
114- **User Stories/Use Cases**: Detailed functionality descriptions
115- **Requirements Document**: BRD, SRS, or PRD
116- **Requirements Traceability Matrix**: Links requirements to business goals, design, tests
117- **Product Roadmap**: Prioritized feature timeline
118
119## Reference Files
120
121Load these on demand based on specific needs:
122
123### Process Guidance
124
125- **[elicitation-techniques.md](references/elicitation-techniques.md)** - Detailed interview techniques, workshop facilitation, and observation methods
126- **[agile-requirements.md](references/agile-requirements.md)** - User story writing, backlog management, sprint planning, and acceptance criteria
127- **[prioritization-frameworks.md](references/prioritization-frameworks.md)** - MoSCoW, RICE, Kano, Value/Effort frameworks with examples
128- **[requirements-gathering-process.md](references/requirements-gathering-process.md)** - End-to-end process from initiation to sign-off
129- **[best-practices.md](references/best-practices.md)** - Quality standards, common pitfalls, and validation checklists
130
131### Documentation Templates
132
133- **[requirements-traceability-matrix.md](references/requirements-traceability-matrix.md)** - Template and examples for tracking requirements
134- **[use-case-overview.md](references/use-case-overview.md)** - Use case structure and examples
135
136## Best Practices Summary
137
138**Avoid Common Pitfalls:**
139
140- ❌ Solution-focused: "Use React framework" → ✅ "Provide responsive web interface"
141- ❌ Vague language: "System should be fast" → ✅ "System responds within 2 seconds for 95% of requests"
142- ❌ Gold plating: Focus on business value, not nice-to-haves
143- ❌ Assuming knowledge: Document all assumptions and define terms
144- ❌ Skipping validation: Always review and get stakeholder sign-off
145
146**Requirements Quality:**
147Every requirement must be clear, complete, consistent, testable, feasible, necessary, prioritized, and traceable.
majiayu000