3. 需求背景与问题描述
本章聚焦于将零散的客户诉求转化为结构化的四要素模型。这是解决方案设计的“地基工程”，决定了后续方案走向的合理性与可行性。通过本章流程，你将掌握从表象需求中提炼核心要素的方法，确保项目基线清晰且达成共识。
模板提示： 建议在项目初期即使用“四要素画布”（Pain-Scene-Goal-Limit Canvas）与客户共同填写，确保信息透明对齐，避免后期频繁返工。
3.1 适用场景与前置条件
| 适用场景 | 前置条件 | 输入物 |
|---|---|---|
| 新项目立项与需求调研 | 完成干系人识别 | 客户原始需求文档 |
| 售前方案可行性评估 | 获得内部立项批准 | 招标书 / RFP |
| 存量系统优化改造 | 现有系统架构资料 | 运维报告、日志 |
3.2 操作步骤：四要素分析法
Step 1：梳理业务痛点 (Pain Points)
- 行动： 采用“5Why”分析法穿透表象。例如客户说“系统慢”，连续追问后得出“数据库锁表”。
- 输出物： 《业务痛点分析表》——记录痛点描述、影响范围、严重等级、根因。
- 责任方： 解决方案架构师 (SA) 主导，客户业务负责人确认。
Step 2：构建用户场景 (Scenarios)
- 行动： 编写用户故事模板：“作为 <角色>，希望 <功能>，以便 <业务价值>”。定义主场景、备选场景、异常场景。
- 输出物： 《用户场景地图》——包含角色、触发条件、操作流程、预期结果。
- 责任方： UX / 业务分析师 (BA) 编写，SA 审核。
Step 3：定义项目目标 (Objectives)
- 行动： 将业务痛点与场景映射为 SMART 目标。区分业务目标（如：降低库存周转率 15%）与技术目标（如：系统可用性 ≥ 99.9%）。
- 输出物： 《项目目标矩阵》——包含目标分类、量化指标、验收标准、优先级。
- 责任方： 项目经理 (PM) 与 SA 共同裁定。
Step 4：识别约束条件 (Constraints)
- 行动： 明确“不能做什么”。三类核心约束：
- 技术约束： 必须兼容现有技术栈、必须部署在私有云。
- 业务约束： 预算上限、不可突破的上线期限、必须通过等保三级。
- 法律约束： 数据不出境、GDPR合规要求。
- 输出物： 《约束条件与风险清单》。
- 责任方： SA 负责技术约束，PM 负责业务与法律约束。
关键验收点： 检查四要素之间是否存在逻辑闭环。例如：痛点“客户投诉响应慢” -> 场景“客服转派工单” -> 目标“工单响应时效缩短50%” -> 约束“不能增加客服编制”。链条断裂则需返工。
3.3 责任边界与验收标准
| 角色 | 核心职责 | 验收通过标准 |
|---|---|---|
| 解决方案架构师 (SA) | 技术可行性把关，非功能需求的翻译 | 输出物无技术逻辑漏洞，四要素链条完整 |
| 业务分析师 (BA) | 用户场景细化，用户故事卡片撰写 | 场景覆盖全部主流程，且通过客户评审 |
| 项目经理 (PM) | 目标对齐，资源与约束的权衡记录 | 目标符合SMART原则，约束获得客户书面确认 |
| 客户代表 | 提供真实业务信息，确认输出物准确性 | 在《四要素结构化说明书》上签字确认 |
3.4 异常处理与记录材料
异常1：干系人提供的痛点相互矛盾
处理流程： 组织专题 Workshop，进行优先级投票排序。若仍无法对齐，输出“已知分歧列表”，由项目发起人做最终决策。
处理流程： 组织专题 Workshop，进行优先级投票排序。若仍无法对齐，输出“已知分歧列表”，由项目发起人做最终决策。
异常2：客户无法量化目标
处理流程： 参照同行业基准数据 (Industry Benchmark) 设定基线，在目标文档中标注“预估基线，待上线后校正”。
处理流程： 参照同行业基准数据 (Industry Benchmark) 设定基线，在目标文档中标注“预估基线，待上线后校正”。
归档记录材料：
- 《业务痛点与用户场景分析表》
- 《项目目标与约束条件说明书》（需客户签字确认）
- 干系人访谈原始记录
- 研讨会会议纪要（含分歧投票结果）