name: 需求收集 description: 系统地收集、记录和验证利益相关者的需求。在开发开始之前确保清晰、完整和一致，以减少范围蔓延和返工。
需求收集
概览
有效的需求收集建立了对将要构建的内容的共同理解，防止错位和昂贵的后期更改。
何时使用
- 项目启动和规划
- 功能开发启动
- 产品路线图规划
- 系统现代化项目
- 客户发现
- 利益相关者对齐会议
- 编写用户故事和验收标准
指南
1. 利益相关者发现
# 识别和分析利益相关者
class StakeholderDiscovery:
STAKEHOLDER_CATEGORIES = [
'最终用户',
'业务所有者',
'技术领导',
'运营/支持',
'客户',
'监管机构',
'集成合作伙伴'
]
def identify_stakeholders(self, project):
"""映射所有利益相关者群体"""
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):
"""了解每个利益相关者的需求"""
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):
"""这个利益相关者想要实现什么？"""
return {
'business_goals': [], # 收入，效率，市场份额
'technical_goals': [], # 性能，可扩展性，可靠性
'user_goals': [], # 易用性，有效性
'operational_goals': [] # 支持效率，正常运行时间
}
def extract_pain_points(self, stakeholder):
"""当前存在什么问题？"""
return [
'当前解决方案的限制',
'集成挑战',
'性能问题',
'用户采用障碍',
'运营成本'
]
2. 需求引出技术
引出技术：
1. 访谈（一对一）
最适合：高级利益相关者，敏感话题
持续时间：30-60分钟
输出：详细需求，背景
准备：创建问题指南，提前安排
样本问题：
- 你试图完成什么？
- 目前有什么阻碍你？
- 成功是什么样子？
- 最重要的指标是什么？
- 你最大的风险是什么？
---
2. 研讨会（小组会议）
最适合：跨职能对齐，头脑风暴
持续时间：2-4小时
输出：共识，优先级
准备：议程，引导指南，材料
格式：
- 开场（10分钟）：目标和议程
- 头脑风暴（45分钟）：产生想法
- 澄清（30分钟）：理解每个想法
- 优先级（45分钟）：按重要性排名
- 决定（30分钟）：承诺优先级
---
3. 用户观察（情境查询）
最适合：理解实际工作流程
持续时间：2-4小时
输出：现实工作流程，隐藏需求
准备：获得访问权限，创建观察指南
关注点：
- 当前工作流程步骤
- 痛点和变通方法
- 任务频率
- 错误处理
- 协作模式
---
4. 调查问卷
最适合：从许多人那里获得广泛输入
持续时间：每个受访者10-15分钟
输出：量化偏好，趋势
准备：编写清晰的问题，选择样本
类型：
- 多项选择（易于分析）
- 评分量表（优先级）
- 开放式（发现）
- 排名（优先级）
---
5. 文件分析
最适合：理解现有流程
持续时间：可变
输出：当前状态理解
准备：提前请求文件
审查：
- 流程文件
- 系统规范
- 用户手册
- 事件报告
- 竞争对手产品
3. 需求文档
// 结构化和记录需求
class RequirementsDocument {
createRequirementStatement(requirement) {
return {
id: `REQ-${Date.now()}`,
title: requirement.title,
description: requirement.description,
rationale: '为什么这很重要？',
source: requirement.stakeholder,
category: requirement.category, // 功能，非功能，约束
priority: requirement.priority, // 必须，应该，可以，不会
acceptance_criteria: [
{
criterion: '具体，可测量的行为',
test: '如何验证'
}
],
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方法：必须，应该，可以，不会
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 => {
// 检查完整性
if (!req.acceptance_criteria || req.acceptance_criteria.length === 0) {
issues.push({
requirement: req.id,
issue: '缺少验收标准',
severity: 'High'
});
}
// 检查清晰度
if (req.description.length < 20) {
issues.push({
requirement: req.id,
issue: '描述太模糊',
severity: 'High'
});
}
// 检查模糊词语
const ambiguousWords = ['quickly', 'easily', 'user-friendly', 'efficient'];
if (ambiguousWords.some(word => req.description.includes(word))) {
issues.push({
requirement: req.id,
issue: '包含模糊语言',
severity: 'Medium'
});
}
});
return {
valid: issues.length === 0,
issues: issues,
recommendations: this.getRecommendations(issues)
};
}
}
4. 需求验证和签署
需求审查清单：
完整性：
[ ] 所有利益相关者需求已记录
[ ] 功能需求已定义
[ ] 非功能需求已指定
[ ] 约束已识别
[ ] 假设已记录
[ ] 明确排除
清晰度：
[ ] 需求具体且可测量
[ ] 无模糊语言
[ ] 验收标准清晰
[ ] 技术团队理解
[ ] 商务团队同意
可行性：
[ ] 需求技术上可行
[ ] 时间线现实
[ ] 资源需求已识别
[ ] 风险评估已完成
[ ] 依赖关系已识别
可追溯性：
[ ] 每个需求追溯到利益相关者需求
[ ] 每个需求链接到用户故事
[ ] 每个需求连接到测试
验证：
[ ] 利益相关者审查已完成
[ ] 商务批准已获得
[ ] 技术可行性已确认
[ ] 签署已收到
---
签署：
业务领导： ____________________ 日期： ________
技术领导： ____________________ 日期： ________
项目经理： ____________________ 日期： ________
需求基线建立：2025年2月1日
批准用于：开发规划
变更控制流程：激活
5. 需求可追溯性矩阵
可追溯性矩阵：
利益相关者需求 → 需求 → 用户故事 → 测试用例
---
利益相关者：CFO（成本降低）
需求：通过降低30%的运营成本
需求：
REQ-101: 系统必须自动扩展基础设施
REQ-102: 必须支持多区域部署
REQ-103: 数据库查询必须在<500ms内完成
用户故事：
US-201: 作为运维工程师，我可以自动扩展资源
US-202: 作为用户，我可以访问任何区域的服务
测试用例：
TC-301: 验证在80%容量时触发自动扩展
TC-302: 验证<100ms区域间延迟
---
利益相关者：VP产品
需求：提高用户参与度25%
需求：
REQ-104: 移动优先响应式设计
REQ-105: 支持推送通知
REQ-106: 离线优先能力
相关指标：
- 日活跃用户+25%
- 会话持续时间+40%
- 用户留存+15%
最佳实践
✅ 做
- 早期让所有关键利益相关者参与
- 书面记录需求
- 使用具体、可测量的语言
- 定义验收标准
- 使用MoSCoW方法优先排序
- 获得利益相关者签署
- 创建可追溯性矩阵
- 定期审查需求
- 区分必须有和希望有
- 记录假设和约束
❌ 不做
- 依赖记忆或口头协议
- 没有利益相关者输入就创建需求
- 使用模糊语言（快速，容易等）
- 跳过非功能需求
- 忽略约束和依赖关系
- 过度记录琐碎细节
- 匆忙完成需求阶段
- 未经利益相关者同意就构建
- 未经流程就进行范围变更
- 忘记边缘情况和错误条件
需求收集提示
- 使用原型澄清需求
- 会议前书面审查需求
- 找一个利益相关者代表
- 使用视觉图表表示复杂工作流程
- 通过模拟演示测试需求理解