4. 范围与假设说明：定义解决方案覆盖范围、明确边界与排除项、列出关键假设
适用场景
本章节适用于以下场景中的最佳实践阶段：
- 解决方案设计文档的早期编制阶段（用户需求分析完成后）
- 项目可行性研究或方案评审前需要明确交付边界
- 跨团队协作时消除理解歧义，防止范围蔓延
- 历史遗留系统升级或整合场景，需清晰界定新旧系统边界
前置条件
- 已完成《需求梳理与用户故事映射》（第3章）并得到干系人确认
- 已获得项目章程或立项批准文件
- 已识别至少80%的核心干系人及其关注点
- 已有初步的系统上下文图或业务流程图草稿
操作步骤
本流程共5个步骤，完成后输出“范围定义表”和“假设日志”。
| 步骤 | 活动 | 责任角色 | 输出物 |
|---|---|---|---|
| 1 | 列出所有可能受影响的业务领域、系统模块、用户角色 | 解决方案架构师 | 影响范围清单 |
| 2 | 与关键干系人逐个确认“包含/不包含”决策 | 架构师+产品经理 | 范围决策记录 |
| 3 | 明确边界条件：时间边界、数据边界、接口边界、组织边界 | 架构师 | 边界定义说明 |
| 4 | 识别必须依赖的外部条件或不确定因素，形成初始假设清单 | 架构师+技术负责人 | 假设清单（草案） |
| 5 | 组织评审会，通过后锁定范围与假设，更新文档版本 | 项目经理 | 评审纪要+签批后的范围假设章节 |
输入与输出物
| 输入物 | 来源 | 输出物 | 去向 |
|---|---|---|---|
| 用户需求清单 | 第3章 | 解决方案范围定义表 | 第5章（架构决策） |
| 项目章程 | PMO | 边界与排除项说明 | 附录A（项目限定） |
| 干系人识别矩阵 | 项目管理计划 | 关键假设日志 | 风险登记册（接口） |
| 系统上下文图草稿 | 架构师 | 更新后的上下文图（含边界标注） | 架构设计章节 |
责任边界
- 解决方案架构师：主导范围定义，确保技术可行性与业务一致性
- 产品经理：代表业务方做出包含/排除决策并签字
- 技术负责人：提供技术可行性评估，协助识别假设中的技术风险
- 项目经理：组织评审会，监控范围变更申请
记录材料
所有记录需保存至项目结束，建议采用以下模板化文档：
📄 范围定义表模板（节选）
# 范围定义表
## 解决方案名称：智慧仓储管理系统升级
### 包含项
- 仓储主数据迁移
- 出入库流程自动化（RFID + 自动分拣）
- WMS与ERP接口改造（库存同步）
### 排除项
- 现有硬件设备替换（仅做软件适配）
- 第三方物流配送模块
- 移动端PDA开发（推迟至v2.0）
### 关键假设
- 目标仓库网络基础设施满足Wi-Fi 6覆盖要求
- ERP团队能在2025Q1提供稳定版API
- 原WMS厂商支持数据库结构开放（合同已含条款）💡 技巧： 排除项必须使用“不包含/不做/推迟/在下一版本”等否定措辞，避免模糊表述。每一条排除项应附带业务或技术理由。
异常处理
| 异常场景 | 处理方式 | 升级路径 |
|---|---|---|
| 干系人对排除项有重大分歧 | 安排专题协商会，必要时提交会议记录由决策层裁断 | 项目经理 → 项目发起人 |
| 假设被证伪（如外部系统接口不可用） | 触发范围变更请求，评估影响后调整范围或假设 | 架构师 → CCB（变更控制委员会） |
| 遗漏关键边界（如数据隐私法规） | 补录排除项，更新评估表，重新评审 | 架构师 → 合规部门 |
| 评审会未通过 | 根据反馈修改后进入二次评审，最多三次 | 项目经理 → 发起人决定是否终止 |
验收标准
- 所有范围条目均有“包含/排除”标记和业务理由
- 每一条假设都对应一个可验证的条件或触发事件
- 边界描述涵盖：时间、数据、接口、组织四个维度
- 至少获得项目发起人、架构师、产品经理三方签批
- 假设日志包含风险评估优先级（高/中/低）