Back to Details

requirements-gathering

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Requirements Gathering

需求收集

Overview

概述

Effective requirements gathering establishes a shared understanding of what will be built, preventing misalignment and expensive changes later in the project.
有效的需求收集能让各方对要构建的内容达成共识，避免项目后期出现偏差和成本高昂的变更。

When to Use

适用场景

  • Project kickoff and planning
  • Feature development initiation
  • Product roadmap planning
  • System modernization projects
  • Customer discovery
  • Stakeholder alignment sessions
  • Writing user stories and acceptance criteria
  • 项目启动与规划阶段
  • 功能开发启动时
  • 产品路线图规划
  • 系统现代化项目
  • 客户调研
  • 利益相关者对齐会议
  • 用户故事与验收标准编写

Instructions

操作步骤

1. Stakeholder Discovery

1. 利益相关者识别

python
undefined
python
undefined

Identify and analyze stakeholders

Identify and analyze stakeholders

class StakeholderDiscovery: STAKEHOLDER_CATEGORIES = [ 'End Users', 'Business Owners', 'Technical Leads', 'Operations/Support', 'Customers', 'Regulatory Bodies', 'Integration Partners' ]
def identify_stakeholders(self, project):
    """Map all stakeholder groups"""
    return {
        'primary': self.get_primary_stakeholders(project),
        'secondary': self.get_secondary_stakeholders(project),
        'tertiary': self.get_tertiary_stakeholders(project),
        'total_to_engage': self.calculate_engagement_strategy(project)
    }

def analyze_stakeholder_needs(self, stakeholder):
    """Understand what each stakeholder needs"""
    return {
        'stakeholder': stakeholder.name,
        'role': stakeholder.role,
        'goals': self.extract_goals(stakeholder),
        'pain_points': self.extract_pain_points(stakeholder),
        'constraints': self.extract_constraints(stakeholder),
        'success_criteria': self.define_success(stakeholder),
        'engagement_frequency': self.plan_engagement(stakeholder)
    }

def extract_goals(self, stakeholder):
    """What does this stakeholder want to achieve?"""
    return {
        'business_goals': [],  # Revenue, efficiency, market share
        'technical_goals': [],  # Performance, scalability, reliability
        'user_goals': [],       # Ease of use, effectiveness
        'operational_goals': []  # Support efficiency, uptime
    }

def extract_pain_points(self, stakeholder):
    """What are current problems?"""
    return [
        'Current solution limitations',
        'Integration challenges',
        'Performance issues',
        'User adoption barriers',
        'Operational costs'
    ]
undefined
class StakeholderDiscovery: STAKEHOLDER_CATEGORIES = [ 'End Users', 'Business Owners', 'Technical Leads', 'Operations/Support', 'Customers', 'Regulatory Bodies', 'Integration Partners' ]
def identify_stakeholders(self, project):
    """Map all stakeholder groups"""
    return {
        'primary': self.get_primary_stakeholders(project),
        'secondary': self.get_secondary_stakeholders(project),
        'tertiary': self.get_tertiary_stakeholders(project),
        'total_to_engage': self.calculate_engagement_strategy(project)
    }

def analyze_stakeholder_needs(self, stakeholder):
    """Understand what each stakeholder needs"""
    return {
        'stakeholder': stakeholder.name,
        'role': stakeholder.role,
        'goals': self.extract_goals(stakeholder),
        'pain_points': self.extract_pain_points(stakeholder),
        'constraints': self.extract_constraints(stakeholder),
        'success_criteria': self.define_success(stakeholder),
        'engagement_frequency': self.plan_engagement(stakeholder)
    }

def extract_goals(self, stakeholder):
    """What does this stakeholder want to achieve?"""
    return {
        'business_goals': [],  # Revenue, efficiency, market share
        'technical_goals': [],  # Performance, scalability, reliability
        'user_goals': [],       # Ease of use, effectiveness
        'operational_goals': []  # Support efficiency, uptime
    }

def extract_pain_points(self, stakeholder):
    """What are current problems?"""
    return [
        'Current solution limitations',
        'Integration challenges',
        'Performance issues',
        'User adoption barriers',
        'Operational costs'
    ]
undefined

2. Requirements Elicitation Techniques

2. 需求获取技巧

yaml
Elicitation Techniques:

1. Interviews (One-on-One)
   Best For: Senior stakeholders, sensitive topics
   Duration: 30-60 minutes
   Output: Detailed requirements, context
   Preparation: Create question guide, schedule in advance

   Sample Questions:
     - What are you trying to accomplish?
     - What's currently preventing you?
     - What would success look like?
     - What metrics matter most?
     - What are your biggest risks?

---

2. Workshops (Group Sessions)
   Best For: Cross-functional alignment, brainstorming
   Duration: 2-4 hours
   Output: Consensus, prioritization
   Preparation: Agenda, facilitation guide, materials

   Format:
     - Opening (10 min): Goals and agenda
     - Brainstorm (45 min): Generate ideas
     - Clarify (30 min): Understand each idea
     - Prioritize (45 min): Rank by importance
     - Decide (30 min): Commit to priorities

---

3. User Observation (Contextual Inquiry)
   Best For: Understanding actual workflows
   Duration: 2-4 hours
   Output: Realistic workflows, hidden requirements
   Preparation: Gain access, create observation guide

   Focus On:
     - Current workflow steps
     - Pain points and workarounds
     - Frequency of tasks
     - Error handling
     - Collaboration patterns

---

4. Surveys
   Best For: Broad input from many people
   Duration: 10-15 minutes per respondent
   Output: Quantified preferences, trends
   Preparation: Write clear questions, select sample

   Types:
     - Multiple choice (easy analysis)
     - Rating scales (prioritization)
     - Open-ended (discovery)
     - Ranking (prioritization)

---

5. Document Analysis
   Best For: Understanding existing processes
   Duration: Variable
   Output: Current state understanding
   Preparation: Request documents in advance

   Review:
     - Process documentation
     - System specifications
     - User manuals
     - Incident reports
     - Competitor products
yaml
Elicitation Techniques:

1. Interviews (One-on-One)
   Best For: Senior stakeholders, sensitive topics
   Duration: 30-60 minutes
   Output: Detailed requirements, context
   Preparation: Create question guide, schedule in advance

   Sample Questions:
     - What are you trying to accomplish?
     - What's currently preventing you?
     - What would success look like?
     - What metrics matter most?
     - What are your biggest risks?

---

2. Workshops (Group Sessions)
   Best For: Cross-functional alignment, brainstorming
   Duration: 2-4 hours
   Output: Consensus, prioritization
   Preparation: Agenda, facilitation guide, materials

   Format:
     - Opening (10 min): Goals and agenda
     - Brainstorm (45 min): Generate ideas
     - Clarify (30 min): Understand each idea
     - Prioritize (45 min): Rank by importance
     - Decide (30 min): Commit to priorities

---

3. User Observation (Contextual Inquiry)
   Best For: Understanding actual workflows
   Duration: 2-4 hours
   Output: Realistic workflows, hidden requirements
   Preparation: Gain access, create observation guide

   Focus On:
     - Current workflow steps
     - Pain points and workarounds
     - Frequency of tasks
     - Error handling
     - Collaboration patterns

---

4. Surveys
   Best For: Broad input from many people
   Duration: 10-15 minutes per respondent
   Output: Quantified preferences, trends
   Preparation: Write clear questions, select sample

   Types:
     - Multiple choice (easy analysis)
     - Rating scales (prioritization)
     - Open-ended (discovery)
     - Ranking (prioritization)

---

5. Document Analysis
   Best For: Understanding existing processes
   Duration: Variable
   Output: Current state understanding
   Preparation: Request documents in advance

   Review:
     - Process documentation
     - System specifications
     - User manuals
     - Incident reports
     - Competitor products

3. Requirements Documentation

3. 需求文档编写

javascript
// Structure and document requirements

class RequirementsDocument {
  createRequirementStatement(requirement) {
    return {
      id: `REQ-${Date.now()}`,
      title: requirement.title,
      description: requirement.description,
      rationale: 'Why is this important?',
      source: requirement.stakeholder,
      category: requirement.category, // Functional, non-functional, constraint
      priority: requirement.priority, // Must, Should, Could, Won't
      acceptance_criteria: [
        {
          criterion: 'Specific, measurable behavior',
          test: 'How to verify'
        }
      ],
      dependencies: [],
      assumptions: [],
      constraints: [],
      estimated_effort: 'TBD',
      status: 'Draft',
      last_reviewed: new Date(),
      review_comments: []
    };
  }

  categorizeRequirements(requirements) {
    return {
      functional: requirements.filter(r => r.category === 'Functional'),
      non_functional: requirements.filter(r => r.category === 'Non-Functional'),
      constraints: requirements.filter(r => r.category === 'Constraint'),
      prioritized: this.prioritizeRequirements(requirements)
    };
  }

  prioritizeRequirements(requirements) {
    // MoSCoW method: Must, Should, Could, Won't
    return {
      must: requirements.filter(r => r.priority === 'Must'),
      should: requirements.filter(r => r.priority === 'Should'),
      could: requirements.filter(r => r.priority === 'Could'),
      wont: requirements.filter(r => r.priority === 'Won\'t')
    };
  }

  validateRequirements(requirements) {
    const issues = [];

    requirements.forEach(req => {
      // Check completeness
      if (!req.acceptance_criteria || req.acceptance_criteria.length === 0) {
        issues.push({
          requirement: req.id,
          issue: 'Missing acceptance criteria',
          severity: 'High'
        });
      }

      // Check clarity
      if (req.description.length < 20) {
        issues.push({
          requirement: req.id,
          issue: 'Description too vague',
          severity: 'High'
        });
      }

      // Check for ambiguous words
      const ambiguousWords = ['quickly', 'easily', 'user-friendly', 'efficient'];
      if (ambiguousWords.some(word => req.description.includes(word))) {
        issues.push({
          requirement: req.id,
          issue: 'Contains ambiguous language',
          severity: 'Medium'
        });
      }
    });

    return {
      valid: issues.length === 0,
      issues: issues,
      recommendations: this.getRecommendations(issues)
    };
  }
}
javascript
// Structure and document requirements

class RequirementsDocument {
  createRequirementStatement(requirement) {
    return {
      id: `REQ-${Date.now()}`,
      title: requirement.title,
      description: requirement.description,
      rationale: 'Why is this important?',
      source: requirement.stakeholder,
      category: requirement.category, // Functional, non-functional, constraint
      priority: requirement.priority, // Must, Should, Could, Won't
      acceptance_criteria: [
        {
          criterion: 'Specific, measurable behavior',
          test: 'How to verify'
        }
      ],
      dependencies: [],
      assumptions: [],
      constraints: [],
      estimated_effort: 'TBD',
      status: 'Draft',
      last_reviewed: new Date(),
      review_comments: []
    };
  }

  categorizeRequirements(requirements) {
    return {
      functional: requirements.filter(r => r.category === 'Functional'),
      non_functional: requirements.filter(r => r.category === 'Non-Functional'),
      constraints: requirements.filter(r => r.category === 'Constraint'),
      prioritized: this.prioritizeRequirements(requirements)
    };
  }

  prioritizeRequirements(requirements) {
    // MoSCoW method: Must, Should, Could, Won't
    return {
      must: requirements.filter(r => r.priority === 'Must'),
      should: requirements.filter(r => r.priority === 'Should'),
      could: requirements.filter(r => r.priority === 'Could'),
      wont: requirements.filter(r => r.priority === 'Won\'t')
    };
  }

  validateRequirements(requirements) {
    const issues = [];

    requirements.forEach(req => {
      // Check completeness
      if (!req.acceptance_criteria || req.acceptance_criteria.length === 0) {
        issues.push({
          requirement: req.id,
          issue: 'Missing acceptance criteria',
          severity: 'High'
        });
      }

      // Check clarity
      if (req.description.length < 20) {
        issues.push({
          requirement: req.id,
          issue: 'Description too vague',
          severity: 'High'
        });
      }

      // Check for ambiguous words
      const ambiguousWords = ['quickly', 'easily', 'user-friendly', 'efficient'];
      if (ambiguousWords.some(word => req.description.includes(word))) {
        issues.push({
          requirement: req.id,
          issue: 'Contains ambiguous language',
          severity: 'Medium'
        });
      }
    });

    return {
      valid: issues.length === 0,
      issues: issues,
      recommendations: this.getRecommendations(issues)
    };
  }
}

4. Requirement Validation & Sign-Off

4. 需求验证与签署

yaml
Requirements Review Checklist:

Completeness:
  [ ] All stakeholder needs documented
  [ ] Functional requirements defined
  [ ] Non-functional requirements specified
  [ ] Constraints identified
  [ ] Assumptions documented
  [ ] Exclusions clearly stated

Clarity:
  [ ] Requirements are specific and measurable
  [ ] No ambiguous language
  [ ] Acceptance criteria clear
  [ ] Technical team understands
  [ ] Business team agrees

Feasibility:
  [ ] Requirements technically feasible
  [ ] Timeline realistic
  [ ] Resource requirements identified
  [ ] Risk assessment completed
  [ ] Dependencies identified

Traceability:
  [ ] Each requirement traced to stakeholder need
  [ ] Each requirement linked to user story
  [ ] Each requirement connected to tests

Validation:
  [ ] Stakeholder review completed
  [ ] Business approval obtained
  [ ] Technical feasibility confirmed
  [ ] Sign-off received

---

Sign-Off:

Business Lead: ____________________  Date: ________
Technical Lead: ____________________  Date: ________
Project Manager: ____________________  Date: ________

Requirements Baseline Established: February 1, 2025
Approved For: Development Planning
Change Control Process: Activated
yaml
Requirements Review Checklist:

Completeness:
  [ ] All stakeholder needs documented
  [ ] Functional requirements defined
  [ ] Non-functional requirements specified
  [ ] Constraints identified
  [ ] Assumptions documented
  [ ] Exclusions clearly stated

Clarity:
  [ ] Requirements are specific and measurable
  [ ] No ambiguous language
  [ ] Acceptance criteria clear
  [ ] Technical team understands
  [ ] Business team agrees

Feasibility:
  [ ] Requirements technically feasible
  [ ] Timeline realistic
  [ ] Resource requirements identified
  [ ] Risk assessment completed
  [ ] Dependencies identified

Traceability:
  [ ] Each requirement traced to stakeholder need
  [ ] Each requirement linked to user story
  [ ] Each requirement connected to tests

Validation:
  [ ] Stakeholder review completed
  [ ] Business approval obtained
  [ ] Technical feasibility confirmed
  [ ] Sign-off received

---

Sign-Off:

Business Lead: ____________________  Date: ________
Technical Lead: ____________________  Date: ________
Project Manager: ____________________  Date: ________

Requirements Baseline Established: February 1, 2025
Approved For: Development Planning
Change Control Process: Activated

5. Requirements Traceability Matrix

5. 需求追溯矩阵

yaml
Traceability Matrix:

Stakeholder Need → Requirement → User Story → Test Case

---

Stakeholder: CFO (Cost Reduction)
Need: Reduce operational costs by 30%

Requirements:
  REQ-101: System must auto-scale infrastructure
  REQ-102: Must support multi-region deployment
  REQ-103: Database queries must complete in <500ms

User Stories:
  US-201: As an ops engineer, I can scale resources automatically
  US-202: As a user, I can access service from any region

Test Cases:
  TC-301: Verify auto-scaling triggers at 80% capacity
  TC-302: Verify <100ms latency between regions

---

Stakeholder: VP Product
Need: Improve user engagement by 25%

Requirements:
  REQ-104: Mobile-first responsive design
  REQ-105: Push notifications support
  REQ-106: Offline-first capability

Related Metrics:
  - Daily active users +25%
  - Session duration +40%
  - User retention +15%
yaml
Traceability Matrix:

Stakeholder Need → Requirement → User Story → Test Case

---

Stakeholder: CFO (Cost Reduction)
Need: Reduce operational costs by 30%

Requirements:
  REQ-101: System must auto-scale infrastructure
  REQ-102: Must support multi-region deployment
  REQ-103: Database queries must complete in <500ms

User Stories:
  US-201: As an ops engineer, I can scale resources automatically
  US-202: As a user, I can access service from any region

Test Cases:
  TC-301: Verify auto-scaling triggers at 80% capacity
  TC-302: Verify <100ms latency between regions

---

Stakeholder: VP Product
Need: Improve user engagement by 25%

Requirements:
  REQ-104: Mobile-first responsive design
  REQ-105: Push notifications support
  REQ-106: Offline-first capability

Related Metrics:
  - Daily active users +25%
  - Session duration +40%
  - User retention +15%

Best Practices

最佳实践

✅ DO

✅ 建议

  • Engage all key stakeholders early
  • Document requirements in writing
  • Use specific, measurable language
  • Define acceptance criteria
  • Prioritize using MoSCoW method
  • Get stakeholder sign-off
  • Create traceability matrix
  • Review requirements regularly
  • Distinguish must-haves from nice-to-haves
  • Document assumptions and constraints
  • 尽早让所有关键利益相关者参与
  • 以书面形式记录需求
  • 使用具体、可衡量的语言
  • 定义验收标准
  • 使用MoSCoW方法进行优先级排序
  • 获取利益相关者的签署
  • 创建需求追溯矩阵
  • 定期评审需求
  • 区分必备需求与可选需求
  • 记录假设条件和约束

❌ DON'T

❌ 避免

  • Rely on memory or verbal agreements
  • Create requirements without stakeholder input
  • Use ambiguous language (quickly, easily, etc.)
  • Skip non-functional requirements
  • Ignore constraints and dependencies
  • Over-document trivial details
  • Rush through requirements phase
  • Build without stakeholder agreement
  • Make scope changes without process
  • Forget about edge cases and error conditions
  • 依赖记忆或口头协议
  • 在没有利益相关者输入的情况下创建需求
  • 使用模糊语言（如“快速地”“轻松地”等）
  • 忽略非功能性需求
  • 无视约束和依赖关系
  • 过度记录琐碎细节
  • 仓促完成需求阶段
  • 在未获得利益相关者同意的情况下开始构建
  • 不遵循流程就进行范围变更
  • 忽略边缘情况和错误条件

Requirements Gathering Tips

需求收集技巧

  • Use prototypes to clarify requirements
  • Review requirements in writing before meetings
  • Get one stakeholder representative
  • Use visual diagrams for complex workflows
  • Test requirements understanding through mock demos
  • 使用原型来明确需求
  • 会议前先书面评审需求
  • 争取每个利益相关方的代表参与
  • 对复杂工作流使用可视化图表
  • 通过模拟演示测试对需求的理解