requirements-elicitation（需求启发）

Requirements Elicitation Methodology

Systematic techniques for transforming vague ideas into clear, testable specifications that align stakeholders and guide implementation.

When to Activate

• Gathering requirements for new features
• Clarifying vague or ambiguous requests
• Resolving conflicting stakeholder needs
• Documenting formal specifications
• Creating user stories with acceptance criteria
• Validating requirements before implementation

Elicitation Techniques

The 5 Whys

Drill past surface requests to discover root needs:

Surface Request: "We need a dashboard"

Why 1: Why do you need a dashboard?
→ "To see our metrics in one place"

Why 2: Why do you need to see metrics in one place?
→ "To identify problems quickly"

Why 3: Why do you need to identify problems quickly?
→ "Because slow response affects customer satisfaction"

Why 4: Why does customer satisfaction matter right now?
→ "We're losing customers and don't know why until it's too late"

Why 5: Why don't you know until it's too late?
→ "We only see issues in monthly reports"

Root Need: Real-time alerting for customer-impacting issues
(Not just a dashboard - the dashboard was a solution, not the need)

Concrete Examples

Transform abstract requirements into specific, testable scenarios:

Boundary Identification

Define what's explicitly in and out of scope:

Feature: User Registration

IN SCOPE:
✓ Email/password registration
✓ Email verification
✓ Password strength requirements
✓ Terms of service acceptance

OUT OF SCOPE:
✗ Social login (Google, Facebook)
✗ Two-factor authentication
✗ Password recovery (separate feature)

DEFERRED:
◐ SSO integration (planned for Q3)
◐ Biometric login (pending security review)

Stakeholder Interviews

Structured conversation to extract requirements:

Interview Structure (45 min):

1. CONTEXT (10 min)
   - What's your role in this project?
   - What does success look like for you?
   - What's driving this initiative?

2. CURRENT STATE (10 min)
   - How do you do this today?
   - What works well?
   - What are the pain points?

3. DESIRED STATE (15 min)
   - What would the ideal solution look like?
   - Walk me through a typical scenario...
   - What would make your job easier?

4. CONSTRAINTS (5 min)
   - What absolutely must be included?
   - What's definitely out of scope?
   - Any timeline or budget constraints?

5. WRAP-UP (5 min)
   - What haven't I asked that I should?
   - Who else should I talk to?
   - Can I follow up if I have questions?

Observation and Shadowing

Watch users perform tasks in their environment:

Observation Protocol:

PREPARE:
- Define what you're observing
- Get permission to observe
- Prepare note-taking template

OBSERVE:
- Note actions, not interpretations
- Record workarounds and pain points
- Note environmental factors
- Time key activities

DEBRIEF:
- "I noticed you did X, can you tell me more?"
- "What would make that easier?"
- "How often does this happen?"

Document:
┌─────────────────────────────────────────────────────────────┐
│ Observation: Order Processing                               │
├─────────────────────────────────────────────────────────────┤
│ Action: Copied customer email from order to support tool    │
│ Time: 15 seconds per order                                  │
│ Frequency: ~50 orders/day                                   │
│ Pain Point: Manual copy-paste, error-prone                  │
│ Opportunity: Direct integration between systems             │
└─────────────────────────────────────────────────────────────┘

Requirement Documentation

User Story Format

Format:
As a [role],
I want [capability],
So that [benefit].

Components:
- Role: Who benefits (be specific)
- Capability: What they can do (action, not solution)
- Benefit: Why it matters (business value)

Example:
As a customer service representative,
I want to see a customer's order history when they call,
So that I can resolve their issues without asking them to repeat information.

Acceptance Criteria (Given-When-Then)

Format:
Given [context/precondition]
When [action/event]
Then [expected outcome]

Example:
Feature: Order Cancellation

Scenario: Cancel order before shipping
Given an order in "confirmed" status
And the order has not been shipped
When the customer requests cancellation
Then the order status changes to "cancelled"
And the customer receives a cancellation confirmation email
And the payment is refunded within 3-5 business days

Scenario: Cannot cancel shipped order
Given an order in "shipped" status
When the customer requests cancellation
Then the cancellation is rejected
And the customer is directed to the returns process

Edge Cases and Exceptions

Document what happens when things go wrong:

Feature: Password Reset

Happy Path:
- User requests reset → Email sent → User clicks link → Sets new password

Edge Cases:
| Scenario | Expected Behavior |
|----------|-------------------|
| Email not found | Show same success message (security) |
| Link expired (>24h) | Show "link expired" with new reset option |
| Link already used | Show "link already used" message |
| Weak password | Show requirements, block submission |
| Same as old password | Show error, require different password |
| User locked out | Still send reset email (unlock flow) |

Non-Functional Requirements

Document quality attributes:

NFR Template:
┌─────────────────────────────────────────────────────────────┐
│ Category: Performance                                        │
├─────────────────────────────────────────────────────────────┤
│ Requirement: Response Time                                   │
│ Measure: 95th percentile page load time                     │
│ Target: < 2 seconds                                          │
│ Context: Desktop browser, 4G connection                     │
│ Priority: Must Have                                          │
└─────────────────────────────────────────────────────────────┘

Common Categories:
- Performance: Speed, throughput, latency
- Scalability: Users, data volume, geographic distribution
- Availability: Uptime, recovery time, disaster recovery
- Security: Authentication, authorization, encryption
- Usability: Accessibility, learnability, efficiency
- Maintainability: Modularity, testability, documentation

Stakeholder Management

Stakeholder Analysis

Identify and categorize stakeholders:

Stakeholder Map:

             High Influence
                   │
    ┌──────────────┼──────────────┐
    │   Manage     │    Partner   │
    │   Closely    │    With      │
    │              │              │
Low ├──────────────┼──────────────┤ High
Interest          │              Interest
    │   Monitor    │    Keep      │
    │   Only       │    Informed  │
    │              │              │
    └──────────────┼──────────────┘
                   │
             Low Influence

Stakeholder Register:
| Name | Role | Interest | Influence | Communication |
|------|------|----------|-----------|---------------|
| VP Sales | Sponsor | High | High | Weekly update |
| Dev Team | Implementer | High | Medium | Daily standup |
| Legal | Advisor | Low | High | As needed |

RACI Matrix

Define roles for each requirement:

R = Responsible (does the work)
A = Accountable (final decision maker)
C = Consulted (provides input)
I = Informed (kept updated)

| Requirement | Product | Dev | Design | Legal |
|-------------|---------|-----|--------|-------|
| User stories | R,A | C | C | I |
| UI mockups | C | I | R,A | I |
| API contracts | C | R,A | I | I |
| Privacy policy | C | I | I | R,A |

Conflict Resolution

When stakeholders disagree:

Resolution Process:

1. UNDERSTAND both positions
   - "Help me understand why X is important to you"
   - Identify underlying needs vs stated positions

2. FIND COMMON GROUND
   - What do both parties agree on?
   - What's the shared goal?

3. EXPLORE OPTIONS
   - Can we do both? (phased approach)
   - Is there a third option that addresses both needs?
   - What's the minimum viable for each?

4. ESCALATE if needed
   - Present options with trade-offs
   - Let decision-maker decide
   - Document the decision and rationale

Example:
Marketing wants: Launch by Q1 with all features
Engineering says: Can't do all features by Q1

Resolution: Launch Q1 with core features (MVP), Phase 2 in Q2
Documented: ADR-2024-03: MVP Scope Decision

Validation Techniques

Requirements Review Checklist

Prototype Validation

Use prototypes to validate understanding:

Prototype Levels:

Low Fidelity (Paper/Whiteboard):
- Quick to create (minutes)
- Good for: Overall flow, major screens
- Validate: "Is this the right approach?"

Medium Fidelity (Clickable mockups):
- Moderate effort (hours)
- Good for: Detailed interactions, UI layout
- Validate: "Does this workflow make sense?"

High Fidelity (Functional prototype):
- Significant effort (days)
- Good for: Complex interactions, performance
- Validate: "Will this actually work?"

Acceptance Criteria Review

Validate with stakeholders before implementation:

Review Format:

"Here's my understanding of [feature]. Please correct me if I'm wrong."

[Read each scenario aloud]

Questions:
- "Is this what you expected?"
- "What did I miss?"
- "What edge cases should we handle?"
- "Is the priority right?"

Document changes and get sign-off.

Traceability

Traceability Matrix

Link requirements to their sources and verification:

| Req ID | Description | Source | Priority | Status | Test Cases |
|--------|-------------|--------|----------|--------|------------|
| REQ-001 | User login | Stakeholder interview | Must | Approved | TC-001, TC-002 |
| REQ-002 | Order history | User observation | Should | Draft | TC-015 |
| REQ-003 | Export CSV | Sales team request | Could | Approved | TC-020 |

Requirement States

Track requirement lifecycle:

States:
┌─────────┐     ┌──────────┐     ┌──────────┐     ┌────────────┐
│ Draft   │────►│ Reviewed │────►│ Approved │────►│ Implemented│
└─────────┘     └──────────┘     └──────────┘     └────────────┘
                     │                                   │
                     ▼                                   ▼
                ┌──────────┐                      ┌──────────┐
                │ Rejected │                      │ Verified │
                └──────────┘                      └──────────┘

Anti-Patterns

Templates

Feature Request Template

# Feature: [Name]

## Problem Statement
[What problem does this solve?]

## User Stories
- As a [role], I want [what] so that [why]

## Acceptance Criteria
- Given [context] when [action] then [outcome]

## Out of Scope
- [What this feature does NOT include]

## Dependencies
- [Other features or systems required]

## Open Questions
- [Unresolved issues needing discussion]

Requirements Document Template

# [Project Name] Requirements Specification

## 1. Introduction
### 1.1 Purpose
### 1.2 Scope
### 1.3 Definitions

## 2. Overall Description
### 2.1 Product Perspective
### 2.2 User Classes
### 2.3 Constraints

## 3. Functional Requirements
### 3.1 [Feature Area 1]
### 3.2 [Feature Area 2]

## 4. Non-Functional Requirements
### 4.1 Performance
### 4.2 Security
### 4.3 Usability

## 5. Appendices
### A. Stakeholder Register
### B. Traceability Matrix

References

• Interview Question Bank - Questions by domain
• User Story Examples - Well-written story examples