从企业级 B 端产品（多租户 SaaS/模型服务平台）的需求与测试实践中提炼的通用方法论，不含任何具体项目信息。工作区原文因密级不入库，本页为可公开的做法抽象。
需求版本对比分析法
新版本需求文档评审前的标准动作：
- 澄清问题状态核对：把上一版的全部澄清问题列成表，逐条标注状态（已解决/部分解决/仍开放）——只关心”开放比例”，它是需求成熟度的直接指标；
- 变更主题矩阵：新版本改动按主题聚类（权限模型/字段/交互/流程），每个主题标注”新增/修改/删除/未变”——未变的部分也要显式声明，防止评审时重复讨论；
- 新引入问题清单：对比后新冒出来的问题单独成列，与遗留问题分开放；
- 对下游文档的影响清单：本次变更需要同步修订哪些既有文档（功能清单/测试用例/脑图），逐份列出修订指引——需求变更最常见的债务是”上游改了下游不知道”。
测试用例与需求状态联动
- 用例按需求澄清状态打标：[需求待确认] 的用例锁定不执行，澄清解锁后才进入执行池——避免测了个寂寞；
- “五段式”功能规格写法（评审 checklist）：角色权限（谁能看/谁能操作）→ 列表字段（展示什么、排序、筛选）→ 按钮交互（每个按钮的前置条件与后果）→ 表单数据项（必填/校验/默认值）→ 弹窗抽屉（边界与异常流）。任何功能需求按这五段齐了才算可评审；
- 典型设计冲突案例（可公开抽象）：列表页”密钥可复制查看”与安全规范”密钥只显示一次”天然冲突——安全约束要前置进需求评审，不能等测试阶段才发现。
相关页面
出处 · 第一轮工作区调研（mvaas 项目方法论的自有语言重写，无涉密内容）