requirements-elicitation

name	requirements-elicitation
description	Stakeholder interview techniques, requirement types, prioritization frameworks, and acceptance criteria patterns. Activate when: eliciting requirements, writing user stories, interviewing stakeholders, prioritizing features, defining acceptance criteria, building a requirements document.

Requirements Elicitation

Stakeholder Interview Techniques

Structured Interview

Prepare questions in advance grouped by topic. Best for extracting specific information.

Interview Template:
1. Context Setting (5 min)
   - "Walk me through your typical day using [system/process]."
   - "What is your role in relation to this project?"

2. Problem Discovery (15 min)
   - "What are the top 3 pain points you experience?"
   - "How much time/money does this cost you?"
   - "What happens when it goes wrong?"

3. Current Workflow (10 min)
   - "Show me step-by-step how you do [task] today."
   - "Where do things slow down or break?"
   - "What workarounds have you built?"

4. Desired Outcome (10 min)
   - "If you could wave a magic wand, what would change?"
   - "What does success look like in 6 months?"
   - "How would you measure improvement?"

5. Constraints (5 min)
   - "What cannot change?"
   - "What regulatory/compliance requirements apply?"
   - "What are the budget and timeline boundaries?"

Contextual Inquiry

Observe users in their actual work environment. Record what they do, not what they say they do.

Observation Checklist:
- Physical workspace setup
- Tools and systems used
- Sequence of actions for key tasks
- Error recovery behaviors
- Collaboration and handoff points
- Workarounds and sticky notes (literal or figurative)
- Interruptions and context switches

Focus Group

Bring 5-8 stakeholders together to surface shared concerns and conflicting needs.

Facilitation Guide:
- Set ground rules: no rank, everyone's input valued
- Use "round robin" to ensure all voices heard
- Use dot voting to surface priorities
- Capture exact language (don't paraphrase in session)
- Note areas of agreement AND disagreement
- Follow up individually on sensitive topics

Reverse Engineering

Analyze existing systems, reports, and documentation to extract implicit requirements.

Sources to mine:
- Existing system screenshots and workflows
- Support ticket themes (top 10 recurring issues)
- Error logs and exception reports
- User training materials (reveal expected behavior)
- Compliance documentation (non-negotiable requirements)
- Competitor product walkthroughs

Requirement Types

Functional Requirements

What the system must do — observable behaviors and capabilities.

Template: The system shall [action] [object] when [condition].

Examples:
- The system shall send a confirmation email within 30 seconds of order placement.
- The system shall allow users to filter search results by date range, category, and status.
- The system shall prevent duplicate submissions within a 5-second window.

Checklist for completeness:
- [ ] Inputs defined (source, format, validation)
- [ ] Processing logic specified (rules, calculations, transformations)
- [ ] Outputs defined (format, destination, timing)
- [ ] Error handling specified (what happens when things fail)
- [ ] State changes documented (what data is created/modified/deleted)

Non-Functional Requirements

Quality attributes — how the system must perform.

Performance:
- Response time: "95th percentile under 200ms"
- Throughput: "Handle 10,000 concurrent users"
- Batch processing: "Complete nightly ETL in under 2 hours"

Reliability:
- Availability: "99.9% uptime (8.7 hours downtime per year)"
- Recovery: "RPO < 1 hour, RTO < 15 minutes"
- Fault tolerance: "No data loss on single-node failure"

Security:
- Authentication: "MFA required for admin access"
- Authorization: "Role-based access control with audit logging"
- Data protection: "PII encrypted at rest and in transit"

Scalability:
- Horizontal: "Scale to 10x current load without architecture changes"
- Data growth: "Support 5TB data growth per year for 5 years"

Usability:
- Accessibility: "WCAG 2.1 AA compliance"
- Learnability: "New user productive within 30 minutes"
- Error prevention: "Confirmation dialogs for destructive actions"

Constraints

Non-negotiable boundaries imposed externally.

Types:
- Technical: "Must run on AWS", "Must use PostgreSQL"
- Regulatory: "GDPR compliance", "SOC 2 Type II"
- Business: "Launch before Q3", "Budget under $200K"
- Integration: "Must integrate with SAP via REST API"
- Organizational: "Must support SSO via company Okta"

Prioritization Frameworks

MoSCoW

Must Have   — Non-negotiable; system fails without it.
             Test: "Will the system be useless without this?"
Should Have — Important but not critical for launch.
             Test: "Can we launch without it and add it soon after?"
Could Have  — Desirable if time and budget allow.
             Test: "Would users notice if it's missing?"
Won't Have  — Explicitly out of scope for this release.
             Test: "Can it wait for a future release?"

Recommended split: 60% Must / 20% Should / 20% Could

RICE Scoring

Reach: How many users/events per quarter?
  - Use data: analytics, user counts, transaction volumes

Impact: How much does this move the needle per user?
  - 3 = Massive (fundamental improvement)
  - 2 = High (significant improvement)
  - 1 = Medium (noticeable improvement)
  - 0.5 = Low (minor improvement)

Confidence: How sure are we about estimates?
  - 100% = High (data-backed)
  - 80% = Medium (informed estimate)
  - 50% = Low (gut feeling)

Effort: Person-weeks to deliver
  - Include design, development, testing, deployment

Score = (Reach × Impact × Confidence) / Effort

Kano Model

Categories:
  Must-Be (Basic):
    - Expected by default; absence causes dissatisfaction
    - Presence doesn't increase satisfaction
    - Example: Login works, pages load, data saves correctly

  One-Dimensional (Performance):
    - More is better; linear relationship with satisfaction
    - Example: Faster load times, more storage, better search

  Attractive (Delighters):
    - Unexpected features that create delight
    - Absence doesn't cause dissatisfaction
    - Example: Smart autocomplete, proactive notifications

  Indifferent:
    - Users don't care either way
    - Don't waste effort here

  Reverse:
    - Feature some users actively dislike
    - Proceed with caution

Classification question pair:
  1. "How would you feel if this feature IS present?"
  2. "How would you feel if this feature is NOT present?"
  Answers: Like / Expect / Neutral / Tolerate / Dislike

User Story Mapping

Building a Story Map

Step 1: Identify the user's journey (backbone)
  Activities:   [Discover] → [Evaluate] → [Purchase] → [Use] → [Support]

Step 2: Break activities into user tasks (walking skeleton)
  Discover:     Search products | Browse categories | View recommendations
  Evaluate:     Read details | Compare items | Check reviews
  Purchase:     Add to cart | Enter payment | Confirm order
  Use:          Track order | Receive item | Rate experience
  Support:      Contact help | Return item | Get refund

Step 3: Slice horizontally for releases
  Release 1 (MVP):  Basic search | View details | Add to cart | Checkout
  Release 2:        Categories | Compare | Reviews | Order tracking
  Release 3:        Recommendations | Wishlists | Returns | Refunds

Story Splitting Patterns

When a story is too large, split using these patterns:

1. By workflow step:  "As a user I can register" →
   - Enter email and password
   - Verify email
   - Complete profile

2. By business rule:  "As a user I can apply discounts" →
   - Apply percentage discount
   - Apply fixed-amount discount
   - Apply buy-one-get-one discount

3. By data variation: "As a user I can pay" →
   - Pay with credit card
   - Pay with PayPal
   - Pay with bank transfer

4. By interface:      "As a user I can search" →
   - Search by keyword
   - Search with filters
   - Search with autocomplete

5. By quality:        "As a user I get results" →
   - Return results (basic)
   - Return results in under 200ms
   - Return results with typo tolerance

Acceptance Criteria Patterns

Given-When-Then (Gherkin)

Scenario: [Descriptive name]
  Given [initial context / precondition]
  And [additional context]
  When [action / trigger]
  And [additional action]
  Then [expected outcome]
  And [additional outcome]
  But [exception to outcome]

Example:
  Scenario: Successful login with valid credentials
    Given the user is on the login page
    And the user has a verified account
    When the user enters valid email and password
    And clicks the "Sign In" button
    Then the user is redirected to the dashboard
    And a welcome message displays the user's name

Checklist Style

Acceptance Criteria:
  ☐ [Capability]: [measurable outcome]
  ☐ [Capability]: [measurable outcome]
  ☐ [Edge case]: [expected behavior]
  ☐ [Error case]: [expected behavior]

Example:
  ☐ User can upload files up to 50MB
  ☐ Supported formats: PDF, PNG, JPG, DOCX
  ☐ Upload progress bar shows percentage
  ☐ Unsupported format shows error with accepted types listed
  ☐ Files over 50MB show error before upload begins
  ☐ Upload resumes after network interruption

Rule-Based

Rules:
  - IF [condition] THEN [outcome]
  - IF [condition] AND [condition] THEN [outcome]
  - IF NOT [condition] THEN [alternative outcome]

Example:
  - IF order total > $100 THEN free shipping applies
  - IF order total > $100 AND user is premium THEN express shipping is free
  - IF order total <= $100 THEN standard shipping rate of $9.99 applies

Requirements Traceability

Traceability Matrix:
| Req ID | Business Need | User Story | Test Case | Status |
|--------|--------------|------------|-----------|--------|
| R-001  | BN-003       | US-012     | TC-045    | Verified |
| R-002  | BN-001       | US-003     | TC-012    | In Progress |

Purpose:
- Track every requirement from origin to validation
- Ensure no requirement is orphaned (untested)
- Support impact analysis when requirements change
- Provide audit trail for compliance