3. 边界与协同的输入材料清单
章节导读：边界定义的质量直接取决于输入材料的完整性与准确度。本章将逐一拆解5份核心输入材料的获取方式、解析要点及其在边界协同中的具体用途，并提供可复用的检查机制。
适用场景
- 新数据产品立项：需要从零界定功能范围，避免后期范围蔓延。
- 大版本迭代：已有产品需扩展或重构，必须识别新旧边界的变化点。
- 跨团队协同：产品、架构、数据、开发四方需要在同一套材料上对齐认知。
- Solution Design 评审：技术方案设计前，必须用输入材料验证功能边界的可行性。
- 合规审计：需要回溯功能边界定义的数据来源与决策依据。
前置条件
- 业务需求已完成初步采集并形成文档（BRD v1.0+）。
- 现有系统架构图已更新至当前生产环境版本。
- 数据字典已至少完成核心业务实体的定义与评审。
- 上游依赖接口列表已通过接口提供方确认。
- 检查表模板已根据本次产品特征完成定制化调整。
- 各材料负责人（BA、架构师、数据工程师、开发组长）已确定并可响应。
操作步骤
-
审查业务需求文档 —— 提取功能边界关键词
逐条阅读用户故事和验收标准，标记所有涉及“范围限定”、“数据范围”、“用户群体”、“时间窗口”的描述，形成功能边界候选清单。 -
分析现有系统架构图 —— 识别技术约束
在架构图上标注新产品功能可能影响的模块，用红笔圈出存在耦合或冲突的区域，产出技术约束矩阵。 -
查阅数据字典 —— 划定数据边界
对照功能需求，筛选出涉及的数据实体和字段，确认数据归属域、读写权限及血缘关系，形成数据边界清单。 -
梳理上游依赖接口列表 —— 明确集成边界
列出所有需对接的外部接口，标注接口的输入/输出规格、SLA 及变更周期，生成集成边界对照表。 -
运行检查表 —— 完整性门禁
用检查表逐项核对前4步的产出是否覆盖全部边界维度，标记缺失项和模糊项，输出边界完整性验证报告。
最佳实践：步骤1-4建议在24小时内集中完成，避免需求上下文丢失；步骤5应由非材料提供方的人员执行，确保检查的独立性。
输入输出物
| 输入材料 | 核心内容 | 产出物 |
|---|---|---|
| 业务需求文档 | 功能描述、用户故事、验收标准、非功能约束 | 功能边界清单 |
| 现有系统架构图 | 模块划分、技术栈、部署拓扑、依赖关系 | 技术约束矩阵 |
| 数据字典 | 数据实体、字段定义、数据类型、数据血缘、权限域 | 数据边界清单 |
| 上游依赖接口列表 | 接口名称、协议、入参/出参、SLA、变更窗口 | 集成边界对照表 |
| 检查表 | 检查项、验证标准、状态标记、责任人 | 边界完整性验证报告 |
责任边界
| 角色 | 负责输入 | 主要职责 | 验收确认 |
|---|---|---|---|
| 业务分析师 | 业务需求文档 | 提供需求并解释边界意图 | 功能边界准确性 |
| 系统架构师 | 现有系统架构图 | 提供技术约束和架构评估 | 技术边界可行性 |
| 数据工程师 | 数据字典 | 提供数据边界和血缘关系 | 数据边界完整性 |
| 开发工程师 | 上游依赖接口列表 | 提供接口依赖和集成方案 | 集成边界可落地 |
| 数据产品经理 | 检查表 | 组织协同并输出边界定义 | 整体边界一致性 |
记录材料
- 边界定义工作底稿：记录每个边界点的来源材料、提取依据及最终裁决结论。
- 协同会议纪要：记录跨团队讨论中产生的分歧点、决策理由及待办事项。
- 问题追踪表：登记材料缺失、内容矛盾、边界模糊等问题，跟踪解决状态。
- 边界变更日志：记录边界调整的原因、时间、涉及材料版本及审批人。
异常处理
| 异常场景 | 影响 | 处理方案 | 升级路径 |
|---|---|---|---|
| 业务需求文档缺失或过时 | 功能边界无法确认 | 启动需求补充调研，48小时内产出补丁版本 | 业务负责人 |
| 系统架构图与实际不符 | 技术约束失真 | 组织架构评审，2个工作日内完成更新 | 架构委员会 |
| 数据字典不完整 | 数据边界模糊 | 数据治理团队补充缺失实体定义 | CDO / 数据负责人 |
| 上游依赖接口未定义 | 集成边界缺失 | 推动接口提供方完成规格定义 | 开发负责人 |
| 检查表检查项覆盖不全 | 边界验证遗漏 | 补充检查项并重新执行完整性验证 | 数据产品负责人 |
⚠ 关键风险：材料版本不一致是边界协同中最常见的隐性风险。务必在启动协同前核对每一份材料的版本号与生效日期，并在工作底稿中注明版本对照关系。
验收标准
- 5种输入材料均可用且为经评审的最新版本。
- 每种材料的边界点已提取并对应记录在边界定义工作底稿中。
- 边界清单完整覆盖功能、技术、数据、集成四个维度，无遗漏。
- 检查表验证通过率 ≥ 90%，未通过项均有明确处理方案和责任人。
- 所有边界模糊项已完成标记并录入问题追踪表。
- 输出物（功能边界定义、协同方案）已获得材料提供方的签字或电子确认。
附录：常用材料片段示例
数据字典条目示例（JSON 片段）：
{
"entity": "user_order",
"domain": "交易域",
"fields": [
{"name": "order_id", "type": "string", "boundary": "核心交易", "sensitive": false},
{"name": "user_id", "type": "string", "boundary": "用户域", "sensitive": true},
{"name": "order_amount", "type": "decimal", "boundary": "核心交易", "sensitive": false},
{"name": "payment_time", "type": "datetime","boundary": "核心交易", "sensitive": false}
],
"data_source": "order_center.mysql",
"update_freq": "实时"
}检查表核心检查项（Markdown 格式）：
## 边界完整性检查表 — v3.2
- [x] 业务需求文档覆盖所有用户故事
- [ ] 系统架构图标注了新产品影响模块
- [x] 数据字典包含所有需求涉及实体
- [ ] 上游依赖接口已确认 SLA 和变更周期
- [ ] 边界清单四个维度均已填写完整
- [ ] 所有模糊项已登记问题追踪表注：检查表每次使用前需根据本次产品特性调整检查项，确保与业务上下文匹配。