4. 需求逻辑矛盾或冲突：识别方法、责任边界、修正流程
4.1 适用场景
- 条件互斥：两个需求对同一条件提出相反约束（如“用户注册后必须立即绑定手机”与“允许用户在7天内跳过绑定”）。
- 时序冲突：需求A依赖B的输出，但B的交付时间晚于A的启动时间。
- 资源竞争：多个需求共享同一资源（如缓存、定时器、硬件接口）但访问规则矛盾。
- 角色权限矛盾：同一角色在不同需求中被赋予冲突的权限范围。
- 数据一致性矛盾：不同需求对同一字段的取值逻辑或校验规则不一致。
4.2 前置条件
- 已输出可评审的PRD文档（含功能列表、业务规则、交互原型）。
- 组建了至少包含PM、开发负责人、QA代表的评审小组。
- 已准备《需求逻辑检查表》作为识别工具。
提示：逻辑检查表建议包含“条件互斥检查”“时序依赖检查”“资源冲突检查”三大维度，每个维度列出常见反模式。
4.3 操作步骤
- 逻辑矛盾检测：逐条比对需求描述，使用逻辑检查表标记以下反模式：
- 条件互斥：相同上下文下的A和B条件不能同时成立。
- 时序依赖断裂：后序需求的前置条件未被满足。
- 资源独占冲突：同一资源被要求同时写和读，或写锁与读锁矛盾。
- 矛盾清单生成：将已识别的矛盾以表格形式记录，包含矛盾编号、涉及需求ID、矛盾类型、简要描述。
- 责任边界判定：根据矛盾类型指定处理负责人：
- 业务逻辑矛盾 → 产品经理/BA。
- 技术实现矛盾 → 系统架构师/技术负责人。
- 跨团队协作矛盾 → 项目PM/Scrum Master。
- 修正流程执行：
- 责任人起草修正方案（修改需求描述、重新排期、调整资源分配等）。
- 在评审会上展示方案并讨论影响范围。
- 达成一致后更新PRD，标记矛盾为“已解决”。
- 验收确认：由QA或原矛盾发现者验证修正后的需求与实际业务逻辑一致，且无引入新矛盾。
4.4 输入输出物
| 阶段 | 输入物 | 输出物 |
|---|---|---|
| 识别 | PRD文档、逻辑检查表 | 《需求矛盾清单》（含矛盾编号、类型、描述） |
| 修正 | 矛盾清单、修正方案草案 | 修正后的PRD（标注变更记录） |
| 验收 | 修正后PRD、原始矛盾清单 | 矛盾已解决确认书（或评审纪要签字） |
4.5 责任边界
- 产品经理：承担业务逻辑矛盾的发现与修正，负责最终需求一致性。
- 技术负责人：识别技术实现层面的矛盾（如数据库设计冲突、API接口矛盾），并给出可落地方案。
- QA：在测试用例设计阶段主动核对逻辑一致性，发现矛盾后上报并推动列入矛盾清单。
- 项目PM：当矛盾涉及多个团队或需要优先级调整时，组织协商并更新排期。
注意：责任边界不清晰是导致矛盾积压的主要原因。建议在项目启动阶段明确“矛盾升级流程”，避免跨角色推诿。
4.6 记录材料
- 需求矛盾清单（建议用Excel或JIRA issue管理，字段：矛盾ID、状态、严重级别、责任人、解决日期）。
- 评审会议纪要（包含每个矛盾的讨论结论、最终修正方案、变更影响范围）。
- PRD变更日志（记录每次修正的版本号、修改内容、修改人、批准人）。
4.7 异常处理
- 矛盾无法达成一致：升级至产品委员会或CTO，由更高决策者裁定优先级和折中方案。
- 修正方案引入新矛盾：回退至步骤3（责任边界判定），重新评估并迭代修正，直至矛盾清单清零。
- 发现矛盾但影响面过大：标记为“待评审”，冻结PRD，单独召开专题会议讨论，避免阻塞整体评审流程。
4.8 验收标准
- 所有已识别的矛盾在矛盾清单中均有对应的“已解决”状态。
- 修正后的PRD中，涉及矛盾的需求描述前后逻辑一致，无自相矛盾表述。
- QA在测试计划中新增的“逻辑一致性验证”测试用例已通过评审。
- 矛盾解决过程记录完整（含责任人、讨论结论、变更版本号）。