DarkM

# 需求管理规范

规范需求从提出到上线的全流程管理，确保需求可追溯、可评估、可交付

# 一、需求分类

# 按规模分类

类型 工作量 流程 审批
小需求 <5 人天 简化流程 项目经理
中需求 5-20 人天 标准流程 技术负责人
大需求 >20 人天 完整流程 项目总监
紧急需求 不限 快速通道 项目经理 + 客户确认

# 按类型分类

  • 功能需求：新功能开发、现有功能优化
  • 缺陷修复：Bug 修复
  • 运维需求：数据修改、配置调整、权限变更
  • 技术需求：技术升级、重构、性能优化、技术债务清理

# 二、需求提出

# 需求邮件模板

主题：【需求】XXX 功能需求

【业务背景】
为什么需要这个功能？解决什么问题？

【功能描述】
具体需要什么功能？用户如何使用？

【期望上线时间】
希望什么时候上线？是否有业务时间节点？

【优先级】
P0-紧急 / P1-高 / P2-中 / P3-低

【附件】
如有原型图、文档等请附上
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 需求接收确认

项目经理收到需求后，应在4 小时内回复确认：

  • ✅ 已收到，预计 X 天内给出评估
  • ✅ 需求清晰，进入评估流程
  • ⚠️ 需求不清晰，需要进一步沟通

# 三、需求评审

# 内部评审要点

  1. 需求清晰度：业务背景是否明确？功能描述是否完整？
  2. 技术可行性：技术上是否可实现？有无技术风险？
  3. 影响范围：影响哪些现有功能？是否需要数据迁移？
  4. 工作量评估：需要多少人天？是否需要外部资源？
  5. 优先级判断：是否符合业务优先级？是否可以延后？

# 问题清单模板

【需求名称】XXX 功能

【待澄清问题】
1. XXX 场景下，系统应该如何处理？
2. XXX 数据的来源是什么？
3. XXX 权限如何控制？

【技术风险】
1. XXX 功能涉及第三方接口，需要确认接口稳定性
2. XXX 功能性能要求高，需要压力测试

【建议】
1. 建议分两期实施，一期先实现核心功能
2. 建议先做原型确认，再开始开发
1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 四、需求变更管理

# 变更流程

变更提出 → 影响评估 → 客户确认 → 计划调整 → 实施变更
1

# 变更评估要点

  1. 工作量影响：增加/减少多少人天？
  2. 进度影响：上线时间是否需要调整？
  3. 成本影响：是否需要额外费用？
  4. 风险评估：变更是否引入新风险？

# 变更控制原则

  • 需求变更>20% 需重新评估工作量和排期
  • 已开发完成的功能变更，需评估返工成本
  • 紧急变更可先实施，后补变更流程

# 五、需求跟踪

# 需求状态

状态 说明
待评审 需求已提交，等待内部评审
评审中 正在内部评审，提出问题
待确认 评审完成，等待客户确认问题
已确认 需求已确认，等待排期
已排期 已安排开发计划
开发中 正在开发
测试中 开发完成，正在测试
已上线 已部署上线
已关闭 客户验收完成

# 需求跟踪表

需求 ID 需求名称 提出日期 当前状态 负责人 预计上线 实际上线
REQ-2026-001 XXX 功能 2026-03-01 已上线 张三 2026-03-15 2026-03-14

# 六、需求验收

# 验收标准

  1. 功能完整：需求描述的功能全部实现
  2. 测试通过：功能测试、集成测试通过
  3. 性能达标：响应时间、并发量满足要求
  4. 文档完整：用户手册、运维手册完整

# 验收流程

开发提测 → 测试验证 → 客户 UAT → 问题修复 → 验收通过
1

# 相关文档

← 开发规范 →