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

Documentation Templates

• [requirements-traceability-matrix.md](references/requirements-traceability-matrix.md) - Template and examples for tracking requirements
• [use-case-overview.md](references/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.

Agile Requirements Management Guide

This guide covers requirements management in Agile environments, including user stories, backlog management, refinement, and sprint planning.

Agile Requirements Principles

Agile Manifesto Values Applied to Requirements

1. Individuals and interactions over processes and documentation

• Favor conversations over lengthy specs
• Collaborate continuously with stakeholders
• Embrace changing requirements

2. Working software over comprehensive documentation

• Document just enough to build
• Use working prototypes to validate
• Let code serve as documentation where appropriate

3. Customer collaboration over contract negotiation

• Involve customers throughout development
• Frequent demonstrations and feedback
• Adjust priorities based on learnings

4. Responding to change over following a plan

• Welcome requirement changes
• Short iterations enable flexibility
• Prioritize based on current business value

Agile Requirements Best Practices

• Write requirements just in time
• Keep requirements at appropriate level of detail
• Focus on outcomes over outputs
• Validate requirements frequently
• Maintain a prioritized backlog
• Involve the whole team
• Use acceptance test-driven development

User Story Framework

Anatomy of a User Story

# User Story Structure

**As a** [user role]
**I want** [capability or feature]
**So that** [business value or benefit]

## Example 1: Simple Format
**As a** customer
**I want** to save items to a wishlist
**So that** I can purchase them later

## Example 2: Detailed Format
**As a** registered customer
**I want** to receive email notifications when wishlist items go on sale
**So that** I can purchase items at the best price and save money

**Acceptance Criteria**:
- Given I have items in my wishlist
  When any item goes on sale
  Then I receive an email within 1 hour
  
- Given I receive a sale notification
  When I click the item link
  Then I am taken directly to the item page with sale price displayed

**Priority**: Medium
**Story Points**: 5
**Sprint**: Sprint 23
**Dependencies**: Email service, Price monitoring system

INVEST Criteria

Independent

• Stories should not depend on other stories
• Can be developed in any order
• Reduces coordination overhead

# ❌ Bad - Dependent Stories
Story 1: Create user registration form
Story 2: Add email field to registration form (depends on Story 1)

# ✅ Good - Independent Stories  
Story 1: Create user registration with name, email, and password fields
Story 2: Add social media login option to registration

Negotiable

• Details are not fixed
• Allows for team creativity
• Encourages collaboration

# ❌ Bad - Prescriptive
As a user, I want a blue Submit button at the bottom right
that uses Arial 14pt font and has a 10px border radius

# ✅ Good - Negotiable
As a user, I want to submit my form easily
so that I can complete my registration quickly

Valuable

• Delivers value to user or business
• Not a technical task
• Tied to business outcome

# ❌ Bad - Technical Task
As a developer, I want to refactor the database schema

# ✅ Good - Valuable
As a customer support agent, I want to search customers by multiple criteria
so that I can find customer records faster and handle more support requests

Estimable

• Team can estimate effort
• Has enough detail
• Team understands what to build

# ❌ Bad - Not Estimable
As a user, I want an improved dashboard

# ✅ Good - Estimable
As a sales manager, I want to see top 10 sales opportunities on my dashboard
sorted by deal value, so that I can focus on the biggest deals

Small

• Can be completed in one sprint
• Typically 1-13 story points
• Can be split if too large

# ❌ Bad - Too Large (Epic)
As a customer, I want a complete e-commerce platform

# ✅ Good - Appropriately Sized
As a customer, I want to add items to my shopping cart
so that I can purchase multiple items in one order

Testable

• Clear acceptance criteria
• Can verify when done
• Observable outcomes

# ❌ Bad - Not Testable
As a user, I want the system to be fast

# ✅ Good - Testable
As a user, I want search results to appear within 2 seconds
so that I can find products quickly

Acceptance Criteria:
- Search completes in < 2 seconds for 95% of queries
- Search works with up to 100,000 products
- Results are sorted by relevance

User Story Formats

1. Standard Format

As a [role]
I want [feature]
So that [benefit]

2. Job Story Format

When [situation]
I want to [motivation]
So I can [expected outcome]

Example:
When I'm browsing products on my mobile phone during my commute
I want to quickly save interesting items
So I can review them later on my desktop and make a purchase decision

3. Feature Injection Format

In order to [achieve value]
As a [role]
I want [feature]

Example:
In order to increase repeat purchases by 15%
As an e-commerce business owner
I want to send personalized product recommendations to customers

Story Mapping

Story Map Structure

                    User Activity 1        User Activity 2       User Activity 3
                    ↓                      ↓                     ↓
Backbone    →    Browse Products    →   Add to Cart    →    Complete Purchase
                    |                      |                     |
                    ↓                      ↓                     ↓
Walking     →    Search Products        View Cart            Enter Shipping
Skeleton           View Details          Update Quantity      Enter Payment
(MVP)              Filter Results        Apply Coupon         Review Order
                   Compare Items                              Confirm Purchase
                    |                      |                     |
                    ↓                      ↓                     ↓
Later          Save to Wishlist         Share Cart           Save Payment Info
Releases       Product Reviews          Gift Wrapping        Order Tracking
               Recommendations          Bulk Discounts       Wishlist to Cart

Creating a Story Map

Step 1: Identify User Activities High-level tasks users need to accomplish

- Discover products
- Research products
- Make purchase decision
- Complete transaction
- Receive order
- Post-purchase support

Step 2: Break Down into User Tasks Specific actions within each activity

Discover Products:
- Browse by category
- Search by keyword
- View promotions
- Get recommendations

Research Products:
- View product details
- Read reviews
- Compare products
- Check availability

Step 3: Identify MVP (Walking Skeleton) Minimum viable path through the map

MVP Release:
- Search products
- View product details
- Add to cart
- Checkout
- Email confirmation

Step 4: Plan Subsequent Releases Add features in priority order

Release 2:
- User accounts
- Order history
- Wishlist
- Product reviews

Release 3:
- Recommendations
- Advanced search
- Gift wrapping
- Loyalty points

Backlog Management

Product Backlog Structure

# Product Backlog

## Epics (Large Features)
├── Epic 1: User Management
│   ├── Story: User Registration
│   ├── Story: User Login
│   ├── Story: Password Reset
│   └── Story: Profile Management
│
├── Epic 2: Shopping Cart
│   ├── Story: Add to Cart
│   ├── Story: Update Quantities
│   ├── Story: Apply Coupons
│   └── Story: Save Cart
│
└── Epic 3: Checkout Process
    ├── Story: Shipping Information
    ├── Story: Payment Processing
    ├── Story: Order Review
    └── Story: Order Confirmation

## Backlog Prioritization
1. [Must Have] User Registration & Login
2. [Must Have] Browse & Search Products
3. [Must Have] Shopping Cart
4. [Must Have] Basic Checkout
5. [Should Have] Wishlist
6. [Should Have] Product Reviews
7. [Could Have] Recommendations
8. [Could Have] Social Sharing

## Technical Debt
- Refactor authentication module
- Optimize database queries
- Update deprecated dependencies

## Bugs
- [Critical] Payment gateway timeout
- [High] Search returns incorrect results
- [Medium] Email formatting issues

Backlog Refinement (Grooming)

Purpose: Prepare stories for upcoming sprints

Activities:

1. Review: Examine upcoming backlog items 2. Detail: Add acceptance criteria and details 3. Estimate: Assign story points 4. Split: Break large stories into smaller ones 5. Clarify: Answer questions and remove ambiguity 6. Order: Re-prioritize based on current knowledge

Refinement Meeting Structure:

Duration: 1-2 hours per week
Attendees: Product Owner, Scrum Master, Development Team
Frequency: Mid-sprint

Agenda:
1. Review top 10-15 backlog items (30 min)
   - PO presents stories
   - Team asks clarifying questions
   - Discuss implementation approach

2. Estimate stories (30 min)
   - Planning poker for story points
   - Identify dependencies
   - Flag risks

3. Split large stories (20 min)
   - Identify stories > 13 points
   - Break into smaller stories
   - Maintain vertical slices

4. Update backlog (10 min)
   - Refine acceptance criteria
   - Add technical notes
   - Update priorities

Definition of Ready (DoR)

Stories are ready for sprint planning when:

# Definition of Ready Checklist

User Story Quality:
□ Written in user story format (As a... I want... So that...)
□ Has clear business value
□ Is independent (or dependencies identified)
□ Is small enough to complete in one sprint
□ Has detailed description

Acceptance Criteria:
□ Clear, testable acceptance criteria defined
□ Edge cases and error conditions documented
□ Performance requirements specified (if applicable)
□ Security requirements identified (if applicable)

Design & UX:
□ Wireframes or mockups available (if UI changes)
□ UX considerations documented
□ Accessibility requirements noted

Technical:
□ Technical approach discussed
□ Dependencies identified
□ APIs or services needed are documented
□ Test strategy outlined

Team Understanding:
□ Product Owner available for questions
□ Team understands the story
□ Story has been estimated
□ Team commits to delivering the story

Documentation:
□ Links to related documents provided
□ Previous work or context referenced
□ Risks and assumptions documented

Sprint Planning

Sprint Planning Meeting

Duration: 2-4 hours for 2-week sprint

Part 1: What? (1-2 hours)

Purpose: Select stories for sprint

Activities:
1. Review sprint goal
2. Review team capacity
3. Review prioritized backlog
4. Select stories that fit capacity
5. Confirm Definition of Ready

Output:
- Sprint Goal
- Committed stories
- Sprint backlog

Part 2: How? (1-2 hours)

Purpose: Create execution plan

Activities:
1. Break stories into tasks
2. Estimate tasks in hours
3. Identify technical approach
4. Assign initial owners
5. Identify blockers

Output:
- Task breakdown
- Hour estimates
- Technical approach
- Identified risks

Sprint Goal

Good Sprint Goal Characteristics:

• Focused on business value
• Inspiring to the team
• Achievable within sprint
• Guides decision-making

# ❌ Bad Sprint Goals
- Complete 15 story points
- Finish user authentication
- Fix bugs

# ✅ Good Sprint Goals
- Enable users to create and manage their profiles
- Launch MVP shopping cart functionality
- Improve checkout conversion rate by reducing friction

Story Point Estimation

Planning Poker Process:

1. Product Owner presents story
2. Team asks clarifying questions
3. Each team member privately selects estimate
4. All reveal simultaneously
5. Discuss differences (especially high/low)
6. Re-estimate until consensus

Story Point Scale (Modified Fibonacci):
1 - Very simple, a few hours
2 - Simple, less than a day
3 - Medium, 1-2 days
5 - Complex, 3-5 days
8 - Very complex, full sprint
13 - Epic, needs splitting
20, 40, 100 - Way too large, definitely split

Estimation Examples:

1 Point Stories:
- Add a new field to existing form
- Update text on a page
- Add validation to existing field

3 Point Stories:
- Create simple CRUD form
- Implement basic search
- Add new report with existing data

5 Point Stories:
- Create complex form with validation
- Implement search with filters
- Add new API endpoint with tests

8 Point Stories:
- Implement OAuth integration
- Create complex reporting feature
- Build new dashboard page

13+ Point Stories:
- These should be split into smaller stories
- Usually indicates unclear requirements
- May contain multiple features

Acceptance Criteria

Given-When-Then Format (Gherkin)

# User Story: Product Search

As a customer
I want to search for products by keyword
So that I can quickly find what I'm looking for

## Acceptance Criteria

Scenario 1: Successful search
Given I am on the home page
When I enter "laptop" in the search box
And I click the search button
Then I should see a list of laptops
And the results should be sorted by relevance
And I should see at least 10 results per page

Scenario 2: No results found
Given I am on the search page
When I enter "xyzabc123" in the search box
And I click the search button
Then I should see "No products found" message
And I should see search suggestions
And I should see popular products

Scenario 3: Search with filters
Given I have performed a search for "laptop"
When I filter by price range $500-$1000
And I filter by brand "Dell"
Then I should see only Dell laptops priced between $500-$1000
And the filter selections should be visible
And I should be able to remove filters

Scenario 4: Search performance
Given I am on any page
When I perform a search
Then results should appear within 2 seconds
And the search should handle 100 concurrent users

Checklist Format

# User Story: User Registration

As a new user
I want to create an account
So that I can access personalized features

## Acceptance Criteria

Functional Requirements:
□ Registration form includes: email, password, name
□ Email validation checks for valid email format
□ Password must be minimum 8 characters
□ Password must contain uppercase, lowercase, and number
□ Email must be unique (no duplicates)
□ Confirmation email sent after registration
□ User can click link in email to verify account
□ User redirected to dashboard after successful registration

UI/UX Requirements:
□ Form displays clear error messages for invalid input
□ Password field has show/hide toggle
□ Password strength indicator displayed
□ "Already have an account?" link to login page
□ Form is mobile responsive
□ All form fields have proper labels and placeholders

Security Requirements:
□ Password is hashed before storage
□ HTTPS required for registration page
□ CAPTCHA prevents bot registrations
□ Rate limiting prevents brute force attacks

Performance Requirements:
□ Registration completes in < 3 seconds
□ Confirmation email sent within 1 minute
□ Form validates input in real-time (< 500ms)

Agile Ceremonies for Requirements

Daily Standup

Duration: 15 minutes
Purpose: Sync on progress and impediments

Questions related to requirements:
- Did requirements become clearer yesterday?
- Any requirements questions blocking you?
- Need clarification from Product Owner?

Sprint Review (Demo)

Duration: 1-2 hours
Purpose: Demonstrate completed work

Activities:
1. Review sprint goal
2. Demo completed stories
3. Get feedback from stakeholders
4. Discuss what to do next
5. Update backlog based on feedback

Requirements Focus:
- Validate against acceptance criteria
- Get feedback on implementation
- Identify new requirements
- Adjust priorities based on learnings

Sprint Retrospective

Duration: 1.5 hours
Purpose: Improve the process

Questions:
- Were requirements clear enough?
- Did we have enough detail to start?
- What requirements issues slowed us down?
- How can we improve requirements quality?

Managing Changing Requirements

Change Request Process

# Change Request Template

## Change Details
- **Requested By**: [Stakeholder name]
- **Date**: [Request date]
- **Priority**: [Critical/High/Medium/Low]
- **Type**: [New Feature/Enhancement/Bug Fix]

## Current Functionality
[Describe how it works now]

## Requested Change
[Describe the requested change]

## Business Justification
[Why is this change needed?]
[What business value does it provide?]
[What happens if we don't make this change?]

## Impact Analysis

### Effort Estimate
- Development: [X story points / Y hours]
- Testing: [X hours]
- Documentation: [X hours]
- Total: [X hours]

### Affected Components
- [ ] Frontend
- [ ] Backend API
- [ ] Database
- [ ] Mobile app
- [ ] Documentation

### Dependencies
- Depends on: [Other stories/features]
- Blocks: [Other stories/features]

### Risks
- Technical risks
- Schedule risks
- Resource risks

## Decision
- [ ] Approved - Add to backlog with priority: _______
- [ ] Approved - Add to current sprint
- [ ] Deferred - Add to future release: _______
- [ ] Rejected - Reason: _______

**Decided By**: [Name]
**Date**: [Decision date]

Handling Mid-Sprint Changes

Options:

1. Add to Backlog (Preferred)

• Most changes go here
• Prioritize for future sprints
• Maintain sprint commitment

2. Swap with Equal Story

• Remove uncompleted story
• Add new story of equal size
• Team must agree
• Happens rarely

3. Emergency Change

• Critical production issues only
• Stop sprint and address
• Document impact
• Adjust sprint goal

Requirements Documentation in Agile

Lightweight Documentation

Just Enough Documentation:

Required:
- User stories with acceptance criteria
- Sprint planning notes
- Definition of Done
- Key technical decisions

Optional (as needed):
- Architecture diagrams
- Data models
- API specifications
- User journey maps
- Wireframes/mockups

Living Documentation

Code as Documentation:

// Self-documenting code
class UserRegistrationService {
  async registerUser(email, password, name) {
    this.validateEmail(email);
    this.validatePasswordStrength(password);
    
    const hashedPassword = await this.hashPassword(password);
    const user = await this.createUser(email, hashedPassword, name);
    await this.sendVerificationEmail(user);
    
    return user;
  }
}

Automated Tests as Documentation:

describe('User Registration', () => {
  it('should create user with valid email and password', async () => {
    // Acceptance criteria documented in test
  });
  
  it('should reject registration with invalid email', async () => {
    // Edge case documented in test
  });
  
  it('should send verification email after registration', async () => {
    // Behavior documented in test
  });
});

Best Practices

1. Keep Stories Vertical

# ❌ Bad - Horizontal slices (by layer)
Story 1: Create database tables for user management
Story 2: Create API endpoints for user management
Story 3: Create UI for user management

# ✅ Good - Vertical slices (by feature)
Story 1: As a user, I want to register an account
Story 2: As a user, I want to login to my account
Story 3: As a user, I want to reset my password

2. Split Stories Effectively

Splitting Techniques:

By Workflow Steps:
- Story 1: Add items to cart
- Story 2: Apply coupon to cart
- Story 3: Proceed to checkout

By Business Rules:
- Story 1: Calculate shipping for domestic orders
- Story 2: Calculate shipping for international orders

By Data Variations:
- Story 1: Search products by name
- Story 2: Search products by category
- Story 3: Search products by price range

By Operations (CRUD):
- Story 1: Create user profile
- Story 2: Edit user profile
- Story 3: Delete user profile

3. Maintain Backlog Health

• Groom regularly (weekly)
• Keep top 2-3 sprints ready
• Archive completed items
• Remove obsolete stories
• Consolidate duplicates
• Update estimates as you learn

4. Collaborate Continuously

• PO available daily for questions
• Team attends refinement
• Include QA in story creation
• Share demos frequently
• Adjust based on feedback

5. Balance Detail

• Too little: Team can't build
• Too much: Wastes time, reduces flexibility
• Rule: Add detail just in time
• If unsure, add acceptance test

Common Anti-Patterns

Anti-Pattern 1: Writing Technical Tasks as User Stories

# ❌ Bad
As a developer, I want to implement caching
so that the application is faster

# ✅ Good
As a user, I want search results to appear within 2 seconds
so that I can find products quickly

Anti-Pattern 2: Too Much Detail Up Front

# ❌ Bad
Writing 200-page requirements document
before starting development

# ✅ Good
High-level epics → Stories with acceptance criteria
→ Detail emerges through conversation and testing

Anti-Pattern 3: No Acceptance Criteria

# ❌ Bad
As a user, I want better search

# ✅ Good
As a user, I want to search products by keyword
Acceptance Criteria:
- Search returns results in < 2 seconds
- Results are sorted by relevance
- Search handles typos and suggests corrections

Anti-Pattern 4: Stories That Are Really Epics

# ❌ Bad
As a customer, I want a complete e-commerce platform

# ✅ Good
Break into smaller stories:
- Browse products by category
- Add products to cart
- Checkout and pay
- Track order status

Anti-Pattern 5: Ignoring Non-Functional Requirements

# ❌ Bad
Only focus on features

# ✅ Good
Include NFRs in Definition of Done or as separate stories:
- Performance: < 2 second response time
- Security: All data encrypted at rest
- Scalability: Support 10,000 concurrent users
- Accessibility: WCAG 2.1 AA compliance

Tools for Agile Requirements

Backlog Management:

• Jira
• Azure DevOps
• Trello
• Asana
• Monday.com

User Story Mapping:

• Miro
• Mural
• Storiesonboard
• Cardboard

Acceptance Testing:

• Cucumber (BDD)
• SpecFlow
• Behave
• JBehave

Collaboration:

• Confluence
• Notion
• Google Docs
• Microsoft Teams

Best Practices

Requirements Quality Checklist

• [ ] Clear: Unambiguous and easy to understand
• [ ] Complete: All necessary information included
• [ ] Consistent: No contradictions with other requirements
• [ ] Testable: Can verify when implemented correctly
• [ ] Feasible: Technically and economically possible
• [ ] Necessary: Directly supports business goals
• [ ] Prioritized: Classified by importance
• [ ] Traceable: Linked to source and downstream artifacts

Common Pitfalls to Avoid

1. Solution-Focused: Describing HOW instead of WHAT

• ❌ "System must use React framework"
• ✅ "System must provide responsive web interface"

2. Vague Language: Using ambiguous terms

• ❌ "System should be fast"
• ✅ "System must respond within 2 seconds"

3. Gold Plating: Including unnecessary features

• Focus on business value
• Apply 80/20 rule
• Challenge "nice to have" features

4. Assuming Knowledge: Not documenting obvious things

• Document all assumptions
• Define acronyms and terminology
• Provide context

5. Skipping Validation: Not confirming understanding

• Review requirements with stakeholders
• Create prototypes for complex features
• Get sign-off before development

Requirements Elicitation Techniques

This guide provides comprehensive techniques for gathering requirements from stakeholders, users, and other sources.

Interview Techniques

Structured Interviews

Purpose: Gather specific, predetermined information

Best For:

• Compliance requirements
• Technical specifications
• Data requirements
• Process documentation

Structure:

# Structured Interview Template

## Pre-Interview Preparation
1. Research stakeholder's role and responsibilities
2. Review existing documentation
3. Prepare specific questions
4. Set clear objectives
5. Schedule adequate time (45-90 minutes)

## Opening (5-10 minutes)
- Introduce yourself and project
- Explain interview purpose
- Set expectations for time
- Ask for permission to record/take notes
- Build rapport

## Question Categories

### Current State Questions
1. What is your role in the organization?
2. What are your primary responsibilities?
3. What tools/systems do you currently use?
4. Walk me through a typical day/workflow
5. What data do you work with?

### Pain Points
6. What are the biggest challenges you face?
7. How much time do these issues cost you?
8. What workarounds have you developed?
9. What would make your job easier?
10. What frustrates you most about current processes?

### Future State
11. What is your vision for the ideal solution?
12. What features are must-haves vs. nice-to-haves?
13. How would you measure success?
14. What business outcomes are you hoping for?
15. What would make this project a failure?

### Technical Requirements
16. What systems need to integrate?
17. What data needs to be accessed?
18. Are there performance requirements?
19. What security/compliance requirements exist?
20. What browsers/devices must be supported?

### Constraints
21. What is the budget?
22. What is the timeline?
23. Who are the key decision-makers?
24. Are there any technical constraints?
25. What are the regulatory requirements?

## Closing (5 minutes)
- Summarize key points
- Confirm understanding
- Ask if anything was missed
- Request follow-up availability
- Ask for referrals to other stakeholders
- Thank them for their time

## Post-Interview
- Send notes within 24 hours
- Confirm key decisions
- Document requirements
- Identify gaps
- Schedule follow-ups if needed

Example Questions:

Process Questions:
- "Walk me through how you handle a customer order from start to finish"
- "What happens when an exception occurs?"
- "How do you handle rush orders?"

Data Questions:
- "What reports do you generate?"
- "Where does this data come from?"
- "How often is this data updated?"

Problem Questions:
- "On a scale of 1-10, how big is this problem?"
- "How much time/money does this cost?"
- "What would happen if this wasn't fixed?"

Future State Questions:
- "If you had a magic wand, what would the solution look like?"
- "What would success look like 6 months from now?"
- "How would this change your daily work?"

Semi-Structured Interviews

Purpose: Balance preparation with flexibility

Best For:

• Exploratory research
• User needs discovery
• Innovation ideation
• Complex domains

Structure:

# Semi-Structured Interview Approach

## Preparation
- Prepare key themes/topics
- Have core questions ready
- Allow room for exploration
- Be ready to follow interesting threads

## Flexible Question Flow

Start with open questions:
- "Tell me about your experience with..."
- "How do you typically..."
- "What challenges do you face when..."

Follow up with probing:
- "Can you tell me more about that?"
- "Why is that important?"
- "Can you give me an example?"
- "What would happen if..."

Adapt based on responses:
- Follow unexpected insights
- Dig deeper into pain points
- Explore mentioned workarounds
- Ask about edge cases

## Active Listening Techniques
- Pause before responding
- Summarize what you heard
- Ask clarifying questions
- Watch for non-verbal cues
- Note emotional responses

Five Whys Technique:

# Example: Understanding Root Cause

Problem: Sales team wants a faster quote system

Interview dialogue:
Q: "Why do you need a faster quote system?"
A: "Because customers are waiting too long for quotes"

Q: "Why are customers waiting too long?"
A: "Because it takes 2-3 days to generate a quote"

Q: "Why does it take 2-3 days?"
A: "Because we have to manually look up prices in multiple systems"

Q: "Why do you have to manually look up prices?"
A: "Because our CRM doesn't integrate with the pricing system"

Q: "Why doesn't the CRM integrate with pricing?"
A: "Because they're on different platforms with no API connection"

Root Cause Identified: Lack of system integration
Real Requirement: API integration between CRM and pricing system

Unstructured Interviews

Purpose: Explore unknown territory, build relationships

Best For:

• Initial discovery
• Understanding culture
• Building stakeholder relationships
• Innovative solutions

Approach:

# Unstructured Interview Guidelines

Start with broad, open questions:
- "Tell me about your work"
- "What's on your mind these days?"
- "What keeps you up at night?"

Let conversation flow naturally:
- Follow the stakeholder's lead
- Don't force your agenda
- Listen more than talk (80/20 rule)
- Observe their environment
- Note what they emphasize

Look for:
- Repeated themes
- Emotional reactions
- Workarounds they've created
- Wish lists and frustrations
- Contradictions

Workshop Techniques

Requirements Workshop

Purpose: Collaborative requirements definition with multiple stakeholders

Setup:

# Workshop Planning Checklist

□ Define clear objectives
□ Identify right participants (6-12 people)
□ Book appropriate space (in-person or virtual)
□ Schedule 2-4 hours
□ Prepare materials and tools
□ Send pre-read materials 2 days before
□ Arrange for refreshments (if in-person)
□ Set up virtual collaboration tools (if remote)

Participants Should Include:
- Business stakeholders (decision-makers)
- End users (actual system users)
- Technical representatives
- Business analyst (facilitator)
- Subject matter experts
- QA representative

Facilitation Techniques:

1. Round Robin

Purpose: Ensure all voices are heard

Process:
1. Pose a question
2. Go around the room
3. Each person shares one idea
4. No discussion yet
5. Repeat until ideas exhausted
6. Then discuss as group

Good for:
- Brainstorming features
- Identifying risks
- Gathering concerns

2. Silent Brainstorming

Purpose: Generate many ideas quickly

Process:
1. Present the prompt/question
2. Everyone writes ideas on sticky notes (5-10 minutes)
3. Post all sticky notes on wall
4. Group similar ideas
5. Discuss and prioritize

Benefits:
- Introverts can contribute
- No groupthink
- Many ideas quickly
- Democratic participation

3. Affinity Diagramming

Purpose: Organize large amounts of information

Process:
1. Collect all ideas (sticky notes)
2. Silently group related items
3. Name each group
4. Discuss groupings
5. Create hierarchy if needed

Example:
User Management
├── Registration
├── Login
├── Profile
└── Permissions

Product Catalog
├── Browse
├── Search
├── Details
└── Compare

4. Dot Voting

Purpose: Prioritize democratically

Process:
1. List all options on wall
2. Give each person 3-5 votes (dots)
3. People place dots on their priorities
4. Can put multiple dots on one item
5. Tally votes
6. Discuss results

Variations:
- Use different colored dots (Must Have, Should Have)
- Give stakeholders more votes
- Do multiple rounds

Design Thinking Workshop

Purpose: User-centered problem solving and ideation

5-Phase Process:

# Design Thinking Workshop (Full Day)

## Phase 1: Empathize (1 hour)
Understand user needs and pain points

Activities:
- Review user research
- Share user stories
- Create empathy maps
- Watch user videos

Output: Deep understanding of user problems

## Phase 2: Define (1 hour)
Frame the problem clearly

Activities:
- Synthesize research findings
- Identify patterns
- Create problem statements
- Define success criteria

Output: Clear problem definition
Example: "Sales reps need a way to generate quotes on-site 
because current 2-3 day turnaround causes lost deals"

## Phase 3: Ideate (1.5 hours)
Generate many solution ideas

Activities:
- Brainstorm solutions (quantity over quality)
- "How Might We" questions
- Crazy 8s exercise
- SCAMPER technique

Output: 30-50 solution ideas

## Phase 4: Prototype (2 hours)
Create low-fidelity prototypes

Activities:
- Paper prototyping
- Storyboarding
- Wireframing
- Create scenarios

Output: Testable prototypes

## Phase 5: Test (1.5 hours)
Get feedback on prototypes

Activities:
- User testing with prototypes
- Gather feedback
- Iterate based on learnings
- Refine requirements

Output: Validated requirements and concepts

How Might We Questions:

Problem: Sales reps can't access CRM in the field

Generate HMW questions:
- How might we make CRM accessible anywhere?
- How might we eliminate the need for desktop access?
- How might we enable offline CRM use?
- How might we sync data seamlessly?
- How might we simplify mobile data entry?

Each HMW becomes a potential solution direction

JAD (Joint Application Design) Sessions

Purpose: Intensive collaborative requirements definition

Structure:

# JAD Session Plan (2-5 days)

Day 1: Scope and Context
- Project overview
- Current state review
- Stakeholder presentations
- Define scope boundaries

Day 2: Requirements Elicitation
- Process modeling
- Use case development
- Data modeling
- Business rules

Day 3: Solution Design
- Prototype review
- Design alternatives
- Technology discussion
- Integration points

Day 4: Validation and Refinement
- Review all requirements
- Resolve conflicts
- Prioritize features
- Identify risks

Day 5: Documentation and Sign-off
- Finalize documentation
- Review action items
- Obtain approvals
- Plan next steps

Outputs:
- Comprehensive requirements document
- Process models
- Data models
- Prototypes
- Signed approvals

Observation Techniques

Job Shadowing

Purpose: Understand actual work practices

Process:

# Job Shadowing Plan

## Preparation
1. Identify representative users
2. Schedule 2-4 hour sessions
3. Explain shadowing purpose
4. Set expectations (minimal interruption)
5. Prepare observation checklist

## During Observation

What to Watch:
□ Actual vs. documented process
□ Workarounds being used
□ Pain points and frustrations
□ Time spent on tasks
□ Tools and systems used
□ Communication patterns
□ Decision-making process
□ Error handling
□ Context switching

Questions to Ask:
- "Why did you do that?"
- "How often does this happen?"
- "What happens when...?"
- "Is this the usual way?"
- "What would make this easier?"

What to Document:
- Screenshots of systems
- Workflow diagrams
- Time estimates
- Pain points
- Workarounds
- Quotes from users
- Environmental factors

## Post-Observation
1. Write up detailed notes
2. Create workflow diagrams
3. Identify requirements
4. Validate findings with user
5. Share insights with team

Example Observations:

# Job Shadowing Notes: Sales Representative

Date: January 14, 2026
User: Sarah, 5 years experience
Duration: 3 hours

Key Observations:

1. Manual Data Entry (30 min observed)
   - Copies data from emails to CRM
   - Uses 3 different tabs
   - Re-enters same customer info multiple times
   - Frequent typos, has to correct
   
   Requirement: Auto-populate from email integration

2. Quote Generation (45 min observed)
   - Opens Excel template
   - Manually looks up prices in separate system
   - Calculates discounts with calculator
   - Formats in Word
   - Emails to manager for approval
   
   Requirement: Integrated quote builder with approval workflow

3. Workarounds Noticed
   - Keeps sticky notes with common product codes
   - Has personal spreadsheet of customer preferences
   - Takes photos of handwritten meeting notes
   
   Requirement: Quick reference, note capture, OCR

4. Pain Points
   - Can't access CRM on phone (mentioned 3x)
   - Forgets to update records (loses information)
   - Doesn't know when quotes are approved
   
   Requirements: Mobile app, notifications, status tracking

Ethnographic Research

Purpose: Understand users in their natural environment

Techniques:

# Ethnographic Research Approach

## Immersion
- Spend extended time with users (days/weeks)
- Become part of their environment
- Observe natural behavior
- Understand culture and context

## Participant Observation
- Not just watching, but participating
- Experience the work firsthand
- Understand unspoken rules
- Feel the pain points personally

## Field Notes
- Detailed observations
- Context and environment
- User emotions and reactions
- Unexpected behaviors
- Cultural norms

## Artifacts Collection
- Take photos (with permission)
- Collect work samples
- Document tools and systems
- Note physical workspace setup

Contextual Inquiry

Purpose: Observe and interview simultaneously

Four Principles:

1. Context: Work in user's actual environment

- Go to their workspace
- Use their equipment
- Experience their interruptions
- Understand their constraints

2. Partnership: User as expert, analyst as apprentice

- Let user lead
- Ask questions as apprentice
- "Teach me how you do this"
- Validate understanding

3. Interpretation: Develop shared understanding

- Discuss observations together
- "It seems like you do X because Y, is that right?"
- Confirm or correct interpretations
- Build shared mental model

4. Focus: Keep inquiry goal-directed

- Stay aligned with project goals
- Explore relevant areas deeply
- Politely redirect tangents
- Balance breadth and depth

Example Session:

# Contextual Inquiry Session

User: Customer Service Representative
Location: Call center
Duration: 2 hours

Approach:
1. Observe rep handling calls
2. Ask questions between calls
3. Have rep explain their thinking
4. Validate interpretations

Sample Dialogue:
BA: "I noticed you had three screens open. Can you show me what each one is for?"
Rep: "This one is the CRM, this is the order system, and this is the knowledge base."

BA: "Why do you need three different systems?"
Rep: "The CRM doesn't have order info, and the order system doesn't have customer history."

BA: "How does that impact your work?"
Rep: "I have to switch between screens constantly. Sometimes I give customers wrong info because I'm looking at the wrong screen."

BA: "It sounds like having all information in one place would help. Is that right?"
Rep: "Yes! That would save me so much time and reduce errors."

Requirement Identified: Unified customer view with order history

Document Analysis

Types of Documents to Analyze

Business Documents:

- Business strategy documents
- Annual reports
- Market research
- Competitor analysis
- Customer feedback/surveys
- Support tickets
- Sales reports

Process Documents:

- Process maps and workflows
- Standard Operating Procedures (SOPs)
- Policy manuals
- Training materials
- Work instructions
- Audit reports

Technical Documents:

- System documentation
- API specifications
- Database schemas
- Architecture diagrams
- Technical specifications
- Change logs
- Incident reports

Regulatory Documents:

- Industry regulations
- Compliance requirements
- Legal contracts
- SLAs (Service Level Agreements)
- Privacy policies
- Security standards

Document Analysis Process

# Document Analysis Checklist

## 1. Collect Documents
□ Request from stakeholders
□ Search shared drives
□ Review previous projects
□ Check regulatory sources
□ Gather competitive intelligence

## 2. Review and Categorize
□ Skim for relevance
□ Organize by topic
□ Note version and date
□ Identify authors
□ Flag inconsistencies

## 3. Extract Requirements

Business Rules:
- "Orders over $1000 require manager approval"
- "Customers get 10% discount after 5 purchases"
- "Refunds must be processed within 48 hours"

Data Requirements:
- Customer: ID, Name, Email, Phone, Address
- Order: ID, Date, Status, Total, Items
- Product: SKU, Name, Description, Price, Stock

Process Steps:
1. Customer places order
2. System validates inventory
3. Payment is processed
4. Order is shipped
5. Customer receives confirmation

Constraints:
- Must comply with GDPR
- Must support 10,000 concurrent users
- Must integrate with SAP ERP
- Must be mobile-responsive

## 4. Validate Findings
□ Confirm with stakeholders
□ Check if still current
□ Resolve ambiguities
□ Update outdated info
□ Document assumptions

## 5. Document Gaps
□ Missing information
□ Unclear requirements
□ Conflicting information
□ Outdated content
□ Areas needing clarification

Prototyping

Prototype Fidelity Levels

1. Paper Prototypes (Low Fidelity)

Purpose: Quick exploration of concepts

Materials:
- Paper and markers
- Sticky notes
- Index cards
- Scissors

Benefits:
- Very fast to create (minutes)
- Easy to change
- No technical skills needed
- Forces focus on concepts
- Stakeholders feel comfortable giving feedback

Process:
1. Sketch screens on paper
2. Create interactive elements on sticky notes
3. Move pieces to simulate navigation
4. Have user "click" with finger
5. Change based on feedback

Best for:
- Initial concept validation
- Workshop exercises
- Rapid iteration
- Early stakeholder feedback

2. Wireframes (Low-Medium Fidelity)

Purpose: Define layout and functionality

Tools:
- Balsamiq
- Sketch
- Figma
- Adobe XD
- PowerPoint/Keynote

Characteristics:
- Grayscale or limited color
- Placeholder content
- Basic interactions
- Focus on structure, not style

Benefits:
- Clarifies functionality
- Defines information architecture
- Shows user flow
- Documents requirements visually

Best for:
- Defining page layouts
- User flow documentation
- Developer handoff
- Requirements validation

3. Mockups (High Fidelity)

Purpose: Show final visual design

Characteristics:
- Real colors and branding
- Actual content (or realistic)
- Detailed styling
- High visual polish

Benefits:
- Looks like real product
- Tests visual design
- Marketing and sales use
- Stakeholder buy-in

Tools:
- Figma
- Sketch
- Adobe XD
- Photoshop

Best for:
- Design approval
- Usability testing
- Documentation
- Marketing materials

4. Interactive Prototypes (High Fidelity)

Purpose: Simulate actual product

Tools:
- InVision
- Figma
- Adobe XD
- Axure
- Proto.io

Features:
- Clickable elements
- Navigation between screens
- Animations and transitions
- Form interactions
- Conditional logic

Benefits:
- Realistic user testing
- Demonstrates functionality
- Identifies usability issues
- Validates requirements

Best for:
- Usability testing
- Stakeholder demonstrations
- Requirements validation
- Developer reference

Prototyping Best Practices

# Prototype Creation Guidelines

## Start Low Fidelity
- Begin with sketches
- Test concepts quickly
- Fail fast and cheap
- Don't invest in wrong direction

## Increment Fidelity
- Add detail as you validate
- Match fidelity to certainty
- Don't polish prematurely

## Make It Realistic Enough
- Use real content when possible
- Reflect actual complexity
- Include edge cases
- Show error states

## Test Early and Often
- Get feedback on rough drafts
- Test with actual users
- Observe, don't explain
- Iterate based on learnings

## Use Appropriate Tools
- Match tool to fidelity level
- Don't over-engineer
- Learn tool before workshop
- Have backups ready

## Document Feedback
- Record test sessions
- Take notes on reactions
- Track common issues
- Prioritize changes

Survey and Questionnaire Techniques

Survey Design

# Survey Design Best Practices

## Define Objectives
- What do you need to know?
- Who should respond?
- How will you use results?

## Keep It Short
- Under 10 minutes to complete
- 10-15 questions maximum
- Progress indicator
- Save and return later option

## Question Types

1. Multiple Choice (Easy to analyze)
   How often do you use the mobile app?
   ○ Daily
   ○ 2-3 times per week
   ○ Weekly
   ○ Monthly
   ○ Rarely
   ○ Never

2. Rating Scale (Quantitative feedback)
   Rate your satisfaction with quote generation:
   1 ☆ - 2 ☆ - 3 ☆ - 4 ☆ - 5 ☆
   Very Dissatisfied ←→ Very Satisfied

3. Ranking (Prioritization)
   Rank these features by importance (1=most important):
   ___ Mobile access
   ___ Faster quotes
   ___ Better reporting
   ___ Email integration

4. Open-Ended (Rich feedback, harder to analyze)
   What is your biggest challenge with the current system?
   [text box]

## Question Writing Tips
- Use clear, simple language
- Avoid leading questions
- One concept per question
- Avoid negatives
- Provide "Other" options
- Include "N/A" when appropriate

## Question Order
1. Start with easy, engaging questions
2. Group related questions
3. Put demographics at end
4. Save sensitive questions for last

## Testing
- Pilot with 5-10 people
- Check for:
  - Confusing questions
  - Missing options
  - Technical issues
  - Appropriate length
  - Question flow

Survey Distribution

# Distribution Strategy

## Choose Right Channel
- Email (if you have addresses)
- In-app popup (current users)
- Website banner
- Social media
- QR codes (physical locations)

## Maximize Response Rate
- Explain purpose and value
- Estimate completion time
- Offer incentive if appropriate
- Send reminders (not too many)
- Thank respondents
- Share results

## Timing
- Avoid holidays and vacations
- Consider time zones
- Allow 1-2 weeks for responses
- Send mid-week, mid-morning

## Sample Size
- Aim for statistical significance
- Consider population size
- Calculate confidence level
- 100+ responses for most surveys

Elicitation Technique Selection Matrix

| Technique | Best For | Time Required | Stakeholder Involvement | Detail Level |
| ----------- | ---------- |---------------|------------------------|--------------|
| Structured Interview | Specific info, compliance | 1-2 hours | Low (1-2 people) | High |
| Semi-Structured Interview | Exploration, complex topics | 1-2 hours | Low (1-2 people) | Medium-High |
| Requirements Workshop | Consensus, prioritization | 2-4 hours | High (6-12 people) | Medium |
| Job Shadowing | Understanding workflows | 2-8 hours | Low (observe 1-2) | High |
| Survey | Large user base, quantitative | 1 week | High (many responses) | Low-Medium |
| Document Analysis | Existing rules, data models | 1-3 days | None (solo activity) | Medium-High |
| Prototyping | Design validation, usability | 1-2 weeks | Medium (review sessions) | Visual |
| Focus Group | Diverse perspectives | 2-3 hours | Medium (6-8 people) | Medium |

Best Practices Across All Techniques

1. Prepare Thoroughly

• Research beforehand
• Have clear objectives
• Prepare materials
• Test technology

2. Build Rapport

• Start with small talk
• Explain purpose clearly
• Show genuine interest
• Respect their time

3. Listen Actively

• Don't interrupt
• Ask clarifying questions
• Paraphrase to confirm
• Note non-verbal cues

4. Document Everything

• Take detailed notes
• Record if permitted
• Capture exact quotes
• Document context

5. Follow Up

• Send summary within 24 hours
• Confirm understanding
• Thank participants
• Share how input was used

6. Validate Continuously

• Confirm understanding
• Check with multiple sources
• Test with prototypes
• Iterate based on feedback

Prioritization Frameworks

MoSCoW Method

# MoSCoW Prioritization

Requirements Gathering Process

Follow this systematic approach for gathering and managing requirements:

Phase 1: Project Initiation & Stakeholder Analysis

1. Project Context Analysis

# Project Context Document

Requirements Traceability Matrix

# Requirements Traceability Matrix

| Req ID | Description | Source | Priority | User Story | Use Case | Test Case | Status |
| -------- | ------------- |--------|----------|------------|----------|-----------|--------|
| BR-1.1 | Mobile CRM Access | Stakeholder Interview | Must Have | US-001 | UC-001 | TC-001-010 | Approved |
| BR-1.2 | Offline Capability | Workshop | Must Have | US-002 | UC-001 | TC-011-015 | Approved |
| BR-2.1 | Quote Generation | Interview, Observation | Must Have | US-003 | UC-002 | TC-016-025 | Approved |
| BR-2.2 | Real-time Pricing | ERP Team | Must Have | US-004 | UC-002 | TC-026-030 | In Review |
| BR-3.1 | Customer 360 | Multiple Sources | Should Have | US-005 | UC-003 | TC-031-040 | Draft |
| BR-4.1 | Sales Dashboard | Sales Leadership | Should Have | US-006 | UC-004 | TC-041-050 | Draft |

Use Case Overview

• ID: UC-001
• Name: Generate Customer Quote
• Actor: Sales Representative
• Goal: Create and submit a quote for customer approval
• Preconditions:
• User is authenticated
• Customer exists in CRM
• Product catalog is available
• Postconditions:
• Quote is created and saved
• Approval request is submitted
• Customer is notified
• Priority: High
• Frequency: 50-100 times per day across all users