第三章 功能边界识别四步法：业务域拆解、利益相关者分析、系统依赖梳理、边界锚点确定

3.1 用户场景与痛点：为什么边界总在开发阶段“塌方”？

某零售企业启动“智能库存预警”数据产品。产品经理与业务方开了三次研讨会，输出了一份 47 页的需求清单。进入原型设计后，发现订单系统的“库存锁定”与仓储系统的“虚拟库存”在同一页面上相互冲突；财务部要求将“呆滞库存”纳入预警，但运营部认为那属于财务分析模块。最终原型返工四次，上线延误两个月。

3.2 功能边界识别四步法

步骤一：业务域拆解 —— 从“大需求”到“子领域”

将业务按核心流程、支撑流程、管理流程切分为独立子域。每个子域具备完整业务语义，对应一个数据模块。

• 核心流程域：订单、库存、物流、财务等直接产生业务价值的链路。
• 支撑流程域：用户管理、权限、消息通知、配置中心等。
• 管理流程域：报表、分析看板、预警规则配置、数据治理。

步骤二：利益相关者分析 —— 谁在使用？谁被影响？谁在决策？

每一类角色都需要标注其使用频率、数据权限、操作意图，避免出现“功能看似完整，但核心角色被边缘化”。

步骤三：系统依赖梳理 —— 数据从哪里来？到哪里去？

绘制数据依赖关系图，识别上游系统、下游系统、平行系统之间的接口边界。这一步决定哪些功能属于本产品，哪些属于外部系统。

• 上游系统：ERP、WMS、OMS —— 提供原始数据。
• 本产品：智能库存预警平台 —— 清洗、聚合、规则判断。
• 下游系统：BI 报表、消息推送、OA 审批 —— 消费结果数据。

步骤四：边界锚点确定 —— 用“红线”锁定模块范围

边界锚点是每个模块的不可逾越的标准，包括：数据边界、功能边界、角色边界、接口边界。

3.3 四步法流程全景图

下图展示了功能边界识别的完整四步流程。每一步的输出是下一步的输入，最终收敛为边界锚点清单，直接指导原型设计。

3.4 用户旅程与原型线框图表达

用户旅程示例：库存预警触发与处置

原型线框图关键区域（文字描述）

根据边界锚点，原型划分为四大区域：

• 数据源配置区：展示已接入的数据源列表，不提供数据编辑能力（数据边界）。
• 预警规则配置区：运营可新增/修改预警规则，但不可删除系统预置规则（功能边界）。
• 预警事件列表区：所有角色可查看，仅仓库管理员可操作“处置反馈”（角色边界）。
• 系统依赖状态区：显示上游接口健康状态，不提供重试按钮（接口边界）。

3.5 PRD 片段：功能边界说明（库存预警模块）

# 3.2 功能边界定义 —— 库存预警模块

## 3.2.1 数据边界
- 本模块维护：库存快照表（sku_id, warehouse_id, available_qty, safety_stock）
- 本模块不维护：订单明细、采购单、财务凭证
- 上游依赖：OMS 接口 /api/v1/inventory/snapshot（实时查询）
- 下游输出：预警事件表（event_id, sku_id, alert_type, status, create_time）

## 3.2.2 功能边界
- 本模块负责：阈值匹配 → 事件生成 → 通知分发 → 处置记录
- 本模块不负责：创建采购补货单、调整安全库存（由运营在规则配置页手动设置）
- 不允许：从预警事件直接跳转至订单创建

## 3.2.3 角色边界
| 角色        | 可操作功能                             | 不可操作功能             |
|-------------|----------------------------------------|--------------------------|
| 运营管理员  | 配置预警规则、查看事件列表、导出报表    | 处置事件、删除规则       |
| 仓储管理员  | 查看事件、填写处置备注、关闭事件        | 修改预警规则、删除事件   |
| 系统管理员  | 查看数据源状态、日志                   | 干预业务数据             |

## 3.2.4 接口边界
- 入接口：GET /api/v1/inventory/snapshot（OMS → 本模块）
- 出接口：POST /api/v1/alert/event（本模块 → 消息队列）
- 本模块不提供实时数据订阅接口，仅支持定时轮询（策略：每5分钟）

3.6 验证指标与验收清单

验证指标

验收清单（交付物模板）

【功能边界验收清单】— 模块：库存预警

□ 1. 业务域分解图已完成，且与业务方确认签字
□ 2. 利益相关者分析表包含所有角色，无遗漏
□ 3. 系统依赖关系图已绘制，上/下游接口已定义
□ 4. 边界锚点清单（数据/功能/角色/接口）逐条通过评审
□ 5. 原型线框图的每个交互元素均对应至少一个锚点
□ 6. PRD 中“不做什么”清单已获业务方签字
□ 7. 验证指标基线已录入，首次测量值为 ≤ 目标值
□ 8. 变更流程已约定：超边界锚点需触发变更评审