Requirements Validation

需求验证技能

目的

在开发开始前，确保需求正确、完整、一致，并且确实能解决业务问题。“做正确的事”与“把事做正确”。

验证与确认

• 验证（Verification）：“我们把产品做对了吗？”（需求是否符合质量标准？）
• 确认（Validation）：“我们做的是正确的产品吗？”（需求是否解决了用户的需要？）

关键验证技术

1. 同行评审 / 走查

• 流程：与同事（开发人员、其他业务分析师）进行非正式或半正式评审。
• 目标：找出逻辑错误、歧义和遗漏的边界情况。
• 检查清单：
  • 是否清晰？
  • 是否可测试？
  • 是否可行？

2. 利益相关者审查 / 签字批准

• 流程：与业务负责人进行正式评审。
• 目标：批准继续推进。
• 方法：不要只阅读文档，而要逐步演示场景和示例。

3. 原型设计

• 方法：展示，而非描述。使用线框图或模型。
• 目标：确认 UI/UX 需求。“这符合你的设想吗？”

4. 验收标准审查

• 方法：审查“假设-当-那么”场景。
• 目标：确保需求足够具体，可以进行测试。

需求追踪矩阵（RTM）

目的

将需求与其来源及下游交付物关联起来。

• 正向追踪：需求 → 设计 → 代码 → 测试。（确保所有要求都已实现）。
• 反向追踪：测试 → 需求 → 业务目标。（确保没有“过度设计”/不必要的功能）。

RTM 模板

需求 ID	描述	来源（利益相关者）	业务目标	设计文档	测试用例 ID	状态
FR-01	访客结账	营销副总裁	提高转化率	DD-Checkout	TC-001, 002	已实现
FR-02	Apple Pay	CEO	移动战略	DD-Payment	TC-005	已批准
FR-03	3D Secure	合规部门	法律要求	DD-Security	TC-010	已测试

质量检查清单（INVEST）

针对用户故事：

• Independent（独立）
• Negotiable（可协商）
• Valuable（有价值）
• Estimable（可估算）
• Small（规模小）
• Testable（可测试）

处理验证问题

1. 歧义：“系统必须很快。”
   • 修正：“系统必须在 2 秒内加载。”
2. 冲突：利益相关者 A 想要蓝色，B 想要红色。
   • 修正：促成协商，或升级给发起人处理。
3. 不完整：缺少错误状态。
   • 修正：询问“如果失败了会发生什么？”

输出

• 已验证的需求包：整洁、已批准的文档。
• 签字批准记录：批准范围的电子邮件或数字签名。
• 已更新的追踪矩阵。

工具

• Jira（将故事与史诗/测试关联）。
• Excel/Lark Base（RTM）。
• Confluence/Lark Docs（审批）。