3. 边界与协同的输入材料清单：业务需求文档、现有系统架构图、数据字典、上游依赖接口列表、检查表

适用场景

• 新数据产品立项：需要从零界定功能范围，避免后期范围蔓延。
• 大版本迭代：已有产品需扩展或重构，必须识别新旧边界的变化点。
• 跨团队协同：产品、架构、数据、开发四方需要在同一套材料上对齐认知。
• Solution Design 评审：技术方案设计前，必须用输入材料验证功能边界的可行性。
• 合规审计：需要回溯功能边界定义的数据来源与决策依据。

前置条件

• 业务需求已完成初步采集并形成文档（BRD v1.0+）。
• 现有系统架构图已更新至当前生产环境版本。
• 数据字典已至少完成核心业务实体的定义与评审。
• 上游依赖接口列表已通过接口提供方确认。
• 检查表模板已根据本次产品特征完成定制化调整。
• 各材料负责人（BA、架构师、数据工程师、开发组长）已确定并可响应。

操作步骤

1. 审查业务需求文档 —— 提取功能边界关键词
   逐条阅读用户故事和验收标准，标记所有涉及“范围限定”、“数据范围”、“用户群体”、“时间窗口”的描述，形成功能边界候选清单。
2. 分析现有系统架构图 —— 识别技术约束
   在架构图上标注新产品功能可能影响的模块，用红笔圈出存在耦合或冲突的区域，产出技术约束矩阵。
3. 查阅数据字典 —— 划定数据边界
   对照功能需求，筛选出涉及的数据实体和字段，确认数据归属域、读写权限及血缘关系，形成数据边界清单。
4. 梳理上游依赖接口列表 —— 明确集成边界
   列出所有需对接的外部接口，标注接口的输入/输出规格、SLA 及变更周期，生成集成边界对照表。
5. 运行检查表 —— 完整性门禁
   用检查表逐项核对前4步的产出是否覆盖全部边界维度，标记缺失项和模糊项，输出边界完整性验证报告。

输入输出物

责任边界

记录材料

• 边界定义工作底稿：记录每个边界点的来源材料、提取依据及最终裁决结论。
• 协同会议纪要：记录跨团队讨论中产生的分歧点、决策理由及待办事项。
• 问题追踪表：登记材料缺失、内容矛盾、边界模糊等问题，跟踪解决状态。
• 边界变更日志：记录边界调整的原因、时间、涉及材料版本及审批人。

异常处理

验收标准

• 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 和变更周期
- [ ] 边界清单四个维度均已填写完整
- [ ] 所有模糊项已登记问题追踪表

注：检查表每次使用前需根据本次产品特性调整检查项，确保与业务上下文匹配。