一、需求评审

1、需求评审-提前邮件通知

a、时间（最好提前1天）

b、人员（产品、UI、运营、开发、测试）

c、产品需求说明书（功能、流程图、信息结构、原型交互）

d、提前沟通核心问题

2、评审会议

a、需求背景

b、用户需求

c、功能需求

d、讲流程

e、原型交互

f、数据指标

g、需要谁支持

h、预计上线时间

3、评审后

a、会议纪要

b、文档调整

c、明确各个时间点

二、需求跟踪

目的：确保需求－设计－编程－测试的一致性。

1、需求追踪矩阵

用户需求标号、需求标题、变更标识、

产品功能标号、需求标题、变更标识、优先级

需求状态（待评审、待开发、待测试、待上线、已完成、已拒绝）

概要设计、测试用例

2、双向跟踪机制

a、正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。

b、逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。

三、需求变更

统一记录和决策，确保理解一致

1、需求分析和分级

2、是否一定要插入在当前版本或延后

3、变动是否较大，开会评审

4、全体明确需求变动是（产品、运营、UI、开发、测试、客服）

5、文档记录并执行

---

【记忆宫殿】

今天的目标是要画一批马，然后大家就开会评审怎么画马，确认后进行了需求追踪，画了一半的马挺好看的，不过却发生了需求变更，然后剩下一半的马就画残了，变成四不像了。