3 功能边界划分的输入输出物清单
功能边界划分的输入输出物是需求分析阶段的核心交付件，它们共同定义了系统“做什么”以及“不做什么”。本章逐一拆解四类关键物件的适用场景、责任人、获取方法与验收标准。
3.1 适用场景
- 需求文档（PRD）：在项目启动后、概要设计前完成，用于对齐产品、业务与研发对于功能范围的共识。
- 用户故事地图：在需求梳理工作坊中使用，通常与PRD并行产出的可视化需求结构。
- 系统上下文图（SCD）：在系统分析与外部接口定义阶段输出，便于界定系统边界与外部依赖。
- 边界划分矩阵：在功能边界争议解决或跨团队分工时使用，需要决策者参与评审。
3.2 前置条件
- 已完成用户访谈与需求采集，形成初步需求条目。
- 项目方已明确产品愿景与版本规划。
- 具备统一的术语表或业务词汇库。
3.3 操作步骤
以下为单项输入输出物的标准产出流程：
步骤一：产出需求文档
- 定结构：按“背景—用户角色—功能清单—非功能需求—数据字典”组织章节。
- 写功能：每条功能以“动词+业务对象”格式命名，并标注优先级（P0~P3）。
- 附加规则：补充业务约束、交互规则及异常流程。
步骤二：构建用户故事地图
- 纵轴分层：按活动→任务→故事→子任务四层自顶向下展开。
- 横轴排序：按用户操作的时间顺序从左到右排列。
- 标记MVP：用颜色或便签标示最小可行版本范围。
步骤三：绘制系统上下文图
- 以目标系统为中心矩形，外部系统为椭圆或圆角框。
- 用带箭头实线表示数据流或控制流，标注协议/接口名称。
- 排除非系统交互的逻辑（如人工操作、纸质单据）。
步骤四：生成边界划分矩阵
- 列：子系统/模块/服务名称。
- 行：功能用例或用户故事。
- 单元格：标记“主责任”“协助”“不涉及”等状态。
- 附加列：备注数据源、异常归属或依赖版本。
3.4 输入输出物清单
| 物件名称 | 类型 | 主要内容 | 产出角色 |
|---|---|---|---|
| 需求文档 | 静态文档（Word/在线文档） | 业务背景、角色定义、功能清单（P0~P3）、非功能需求、数据字典、交互原型索引 | 产品经理 |
| 用户故事地图 | 可视化看板/卡片矩阵 | 纵轴：活动→任务→故事；横轴：时间顺序；MVP标记 | 产品经理+业务方 |
| 系统上下文图 | 图形化模型 | 目标系统、外部系统、人角色（如适用）、数据流、接口协议 | 架构师/系统分析师 |
| 边界划分矩阵 | 矩阵表格（Excel/在线表格） | 行=功能用例，列=子系统/模块，单元格=职责标记 | 产品经理+架构师+研发负责人 |
3.5 责任边界
- 产品经理：主导PRD与用户故事地图的编写，推动边界划分矩阵对齐。
- 架构师/系统分析师：绘制系统上下文图，评审矩阵中技术可行性。
- 研发负责人：协助提供技术依赖与子系统边界建议。
- 业务方代表：确认需求文档与用户故事的真实性与优先级。
3.6 记录材料
- 需求文档评审纪要（含评审人、日期、决策项）。
- 用户故事地图终版照片或电子快照。
- 系统上下文图版本记录（含历史变更原因）。
- 边界划分矩阵的头脑风暴草稿与最终确认签字版。
3.7 异常处理
常见异常处理策略
- 需求遗漏：在用户故事地图中预留“待确认”水平带，统一在评审会后补齐。
- 边界争议：使用边界划分矩阵逐条带评审，若仍无法达成共识，由架构师向CTO或决策委员会上升仲裁。
- 外部系统定义不明确：在系统上下文图中用虚线框和“TBD”标注模糊依赖，同步关联PM与商务对外联调。
3.8 验收标准
以下条件全部满足，视为本里程碑完成：
- 需求文档已通过评审，版本号和变更记录清晰。
- 用户故事地图已拆分到“子任务”层级，MVP范围可独立提取。
- 系统上下文图已标识所有外部系统及数据流向，无灰色区域。
- 边界划分矩阵无“待定”状态单元格，所有功能都明确归属到子系统或模块。