第3章 维度定义与拆解：业务、技术、体验、安全边界清单

验收边界量化从四个核心维度展开：业务（Business）、技术（Technical）、体验（Experience）、安全（Security）。每个维度拥有独立的关注域、判定指标和交叉约束。本章给出各维度的正式定义、边界拆解方法及一份可直接用于评审的边界清单模板。

3.1 适用场景

• 多团队联合验收：业务、开发、测试、安全、运维五方需要统一维度口径时。
• 需求阶段边界预埋：在用户故事或技术方案中提前标注验收边界。
• 复盘/漏测分析：定位上一轮验收遗漏的维度归属，补充量化规则。

3.2 前置条件

1. 已完成系统上下文图（System Context）和核心业务流梳理。
2. 已识别至少3 条跨团队接口或数据交换点。
3. 安全等级与合规要求已明确（等保、GDPR、PCI-DSS 等）。
4. 团队已约定“维度冲突”仲裁机制（例如：安全边界高于体验边界）。

3.3 操作步骤

步骤一：绘制维度边界全景图

召集四方代表，在白板上画出四个象限，每个象限列出该维度的核心关注点与禁止越界区域。

步骤二：逐维填写边界卡片

使用下表模板，为每个维度至少填写 3 条边界条目。每条包含：边界ID、维度、边界描述、量化阈值、违反后果。

边界ID	维度	边界描述	量化阈值	违反后果
BZ-01	业务	订单创建接口不支持负数量	数量 < 1 返回 422	P0 缺陷，阻断上线
TZ-02	技术	API 响应时间上限	P99 < 500ms	性能回归，须优化
EZ-03	体验	关键路径点击次数不超过 4 次	4 次以内完成主线任务	UX 拒绝签字
SC-04	安全	登录失败 5 次锁定账号	5 次/15 分钟锁定 30 分钟	安全准入不通过

步骤三：交叉依赖标注

在四条边界之间识别约束关系，例如：安全维度的“强制 2FA”会增加体验维度的操作步骤数。依赖关系需在边界清单的备注列中记录。

步骤四：生成维度边界清单

将所有边界条目汇总为一份可执行文档，作为验收用例设计的输入物。

3.4 输入输出物

类型	名称	格式	责任方
输入	系统上下文图 + 业务流程图	Drawio / PNG	系统分析师
输入	安全等级与合规矩阵	Excel / Confluence	安全工程师
输出	维度边界清单（4 维）	Markdown / 在线表格	验收负责人
输出	维度依赖关系矩阵	CSV / 矩阵图	技术架构师

3.5 责任边界

• 业务方（PO/BA）：定义业务维度的正异常边界，签字确认。
• 技术架构师：定义技术维度（性能、可用性、可扩展性）阈值。
• UX 设计师：定义体验维度（操作步数、反馈时延、无障碍）边界。
• 安全工程师：定义安全维度（认证、授权、审计、加密）底线。
• 验收负责人：汇总冲突并组织仲裁会议。

3.6 记录材料

以下材料需归档至项目 Wiki 或验收数据包：

1. 维度边界清单（含版本号）
2. 维度冲突仲裁会议纪要
3. 边界变更申请单（若有修订）

3.7 异常处理

异常场景	处理策略	介入角色
维度边界冲突（如安全与体验）	按“安全 > 业务 > 技术 > 体验”优先级裁决	安全负责人 + PO
某个维度缺少量化手段	标记为“待探索”，设置最长观察期（通常 2 个 Sprint）	验收负责人 + QA
边界清单与实现差距过大	发起边界重审会议，刷新清单版本	变更控制委员会（CCB）

3.8 验收标准

维度边界清单满足以下条件方可进入验收用例设计阶段：

1. 每个维度至少包含 5 条可量化边界条目；
2. 所有边界条目的量化阈值已通过相关方评审并签收；
3. 维度间的依赖关系已识别，冲突已裁决并记录；
4. 边界清单已纳入版本管理，基线号可追溯。

---