第3章 · 需求分析与拆解

需求是技术方案的起点。本章将带你掌握一套系统化的需求拆解方法：从业务愿景（BRD）到产品需求文档（PRD），最终输出可落地的功能列表与验收标准。

3.1 从BRD到PRD：需求逐级精化

业务需求文档（BRD）通常包含高层商业目标，而产品需求文档（PRD）则细化到用户可感知的功能。拆解的核心是不断追问“为什么”与“怎么做”。

3.2 拆解方法：用户故事 + 用例

采用标准用户故事模板：作为<角色>，我希望<功能>，以便<价值>。配合用例（Use Case）描述主流程与异常流。

3.3 功能列表结构化：MoSCoW 优先级

将拆解后的功能按 Must have / Should have / Could have / Won't have 分类，确保核心范围可控。

3.4 实战：从模糊需求到功能列表

假设业务方提出：“我们要做一个智能客服系统，提升响应速度。” 经过拆解后得到以下功能列表：

功能列表 v1.0 (PRD 拆解)
├── 必须 (Must)
│   ├── 用户提交工单 (标题/描述/分类)
│   ├── 客服分配 (自动轮询 + 手动转接)
│   └── 工单状态流转 (待处理/处理中/已关闭)
├── 应该 (Should)
│   ├── 常见问题知识库 (搜索)
│   └── 工单满意度评价
├── 可以 (Could)
│   ├── 智能推荐答案 (基于NLP)
│   └── 实时聊天 (WebSocket)
└── 不做 (Won't)
    └── 电话呼叫中心集成 (二期)

3.5 验收标准与质量属性

每个功能必须附带验收条件（Acceptance Criteria）。例如：

• 功能： 用户提交工单后，系统应在2秒内返回工单ID。
• 边界： 附件最大10MB，支持jpg/png/pdf。
• 异常： 当分类字段为空时，提示“请选择问题分类”。