3. 收集业务需求文档：梳理用户故事、提取核心功能需求、定义成功标准

本章定位：从原始业务描述到结构化功能清单的转化枢纽。本环节将“模糊的期望”转化为可度量、可开发的AI解决方案需求基线。如果跳过本环节，后续可行性评估将建立在主观猜测而非业务事实上。

3.1 适用场景

  • 已与业务方完成初步意向沟通，需要系统化捕获需求细节。
  • 涉及多角色参与的业务流程（如客服、审批、质检），需要明确各角色对新AI功能的真实期望。
  • 存在历史遗留系统或非结构化需求说明（会议纪要、邮件、IM记录），需要统一整理为标准化文档。
  • 需要在可行性评估阶段前，为技术团队提供准确的输入范围。

3.2 前置条件

  • 已确认利益相关方清单：至少包括业务负责人、关键用户、IT对接人。
  • 获得原始资料：需求访谈录音/纪要、当前业务流程文档、现有系统操作手册。
  • 确定需求记录工具：推荐使用Jira、Confluence、Excel模板或专用需求管理平台，后续章节输出物需据此托管。
  • 团队就位：至少1名BA（业务分析师）主导，1名技术代表提供早期可行性反馈。

3.3 核心步骤与输入输出物

步骤 输入物 活动描述 输出物
3.3.1 梳理用户故事 会议纪要、访谈记录、原始需求邮件 按标准模板将业务需求拆解为独立的、以用户视角表述的故事。 用户故事卡片（含角色、功能、价值）
3.3.2 提取核心功能需求 用户故事卡片 去重、分类、抽象出具体的AI功能列表，标注优先级。 功能需求清单（含输出/输入规范）
3.3.3 定义成功标准 核心功能需求清单、业务KPI 为每个功能或整个解决方案设定可量化、可验证的验收指标。 成功标准表（含指标、阈值、检验方式）
常见误区：直接要求业务方写“技术需求”（如“我要一个NLP模型”），而非“业务需求”（如“我希望系统能自动提取客户投诉中的关键字段”）。必须坚持用户故事格式，确保需求源于真实场景。

3.4 操作步骤详解

3.4.1 梳理用户故事（格式与示例）

使用标准模板：

作为【用户角色】
我想要【执行动作/功能】
以便【业务价值/目标】

实际AI场景示例：

  • 客服审核员：“作为客服审核员，我想要AI自动标记‘情绪异常’对话，以便我优先处理高危投诉。”
  • 运营主管：“作为运营主管，我想要AI生成每日工单汇总摘要，以便我减少80%的阅读时长。”
  • 前端开发：“作为系统集成的后端模块，我想要AI功能通过标准REST API暴露，以便减少集成工作量。”

注意事项：每个故事应独立、可测试，尽量避免出现“并且”、“同时”等连词，若出现则拆分为多个故事。

3.4.2 用户故事评审与INVEST原则

在进入提取功能需求前，对每个用户故事进行快速质量检查：

  • I（Independent）：故事是否相互独立？
  • N（Negotiable）：是否有讨论/调整空间，而非硬性命令？
  • V（Valuable）：是否对用户有明确价值？
  • E（Estimable）：是否能大致评估工作量？
  • S（Small）：是否足够小（通常应<1周开发量）？
  • T（Testable）：是否有明确的测试通过条件？

3.4.3 提取核心功能需求（从故事到功能卡片）

  1. 去重与合并：将表述不同但本质相同的用户故事合并。
  2. 抽象出公共功能：例如“AI总结”、“AI分类”、“AI匹配”可作为公共模块。
  3. 标注输入/输出规格：明确AI功能需要接收什么格式的数据，输出什么内容。
  4. 分配优先级：使用MoSCoW法则（Must have / Should have / Could have / Won't have）。
模板示例：功能需求卡片 
功能ID: AI_RQ_001
功能名称: 对话摘要生成
输入: 客服-客户完整对话文本（UTF-8，JSON数组格式）
输出: 结构化摘要包含：{诉求类型、关键时间点、情绪标签、待办事项}
优先级: Must
关联用户故事: US-003, US-005

3.4.4 定义成功标准（SMART原则）

成功标准必须为后续的技术可行性评估和POC验证提供可量化的目标。避免使用“效果更好”、“效率提升”等模糊描述。

维度 指标示例（AI对话摘要） 阈值 验证方式
准确率 摘要关键字段（如诉求类型）与人工标注一致的比例 ≥ 92% A/B测试，随机抽取500条对话，由两名人工标注员比对
召回率 标注出的真正关键信息占比 ≥ 85% 抽样检验，以专家标注为golden set
响应时间 从提交文本到生成摘要的P95耗时 ≤ 3秒 负载测试（100并发请求）
用户满意度 审核员对摘要质量的主观评分（5分制） 平均 ≥ 4.0分 功能上线后收集100份问卷
协作建议：成功标准定义阶段必须由BA主导，但需引入技术代表评估“当前技术能否达到该标准”，避免设定过低或过高的指标。

3.5 本章核心流程：从业务输入到需求基线

业务需求文档生成流程 原始输入 会议纪要 访谈录音 邮件/IM记录 现流程文档 步骤1：梳理用户故事 角色 + 功能 + 价值｜INVEST评审 步骤2：提取核心功能需求 去重 → 抽象 → 标输入/输出 → 定优先级 步骤3：定义成功标准 准确率 ≥ 92% 召回率 ≥ 85% 响应时间 ≤ 3s 用户满意度 ≥ 4.0 输出：业务需求文档基线（用户故事 + 功能清单 + 成功标准） 作为后续技术可行性评估 / POC设计的唯一需求输入 必须在需求文档内建立用户故事→功能ID→成功标准的双向溯源关系
流程要点：上述SVG展示了“原始输入 → 梳理用户故事 → 提取功能需求 → 定义成功标准 → 输出基线的线性递进关系。注意定义成功标准环节与技术可行性检视并非先后关系，而是并行协作，避免产生不可实现的指标。

3.6 责任边界

角色 主要职责 输出物责任
BA团队 主导梳理用户故事、提取功能和成功标准，确保需求覆盖所有利益相关方。 需求基线文档
PM/架构师 对功能需求进行早期技术可行性评估（资源、数据、模型能力），提前标注高风险需求。 技术可行性备注
业务方 确认用户故事的真实性，提供成功标准的原始KPI数据（如当前处理时长、错误率）。 业务确认签名
QA团队 在成功标准确定阶段，参与指标可测性验证，确保每个标准都能设计对应的测试用例。 可测试性备注
常见边界模糊：BA不应承担技术可行性评估，只需要记录需求；架构师不应当修改用户故事，只给出可行性反馈。两种角色若越界，会导致需求偏离业务初衷或过于技术化。

3.7 记录材料

  • 需求基线文档（RD-Baseline）：包含所有用户故事清单、功能需求卡片、成功标准表格、优先级分配。
  • 用户故事溯源矩阵：用户故事ID ↔ 功能ID ↔ 成功标准ID ↔ 原始资料引用（标注来源会议纪要或邮件）。
  • 利益相关方签字记录：至少业务方负责人和BA共同确认需求基线冻结。

3.8 异常处理

异常场景 处理方式
用户故事之间存在逻辑矛盾（如A要“实时”而B要“批量”） 升级至业务决策层，由利益相关方协商统一策略；保留两个版本作为候选，由可行性评估结果决定。
成功标准指标无法获取原始数据基线 先定义短周期（如2周）的基线收集任务，将此任务作为需求的前提条件，推迟该需求的正式评估。
业务方对需求优先级争议过大 使用WSJF（Weighted Shortest Job First）方法：计算业务价值/时间概率，提供量化排名。
需求涉及多个独立业务系统，无法统一用户视角 拆分为多个独立的用户故事集合，每个系统单独输出需求基线，后续在架构层面设计数据交互。

3.9 验收标准

  1. 完整性验证：所有已确认的利益相关方均对应至少一个用户故事。
  2. 可追溯性验证：每个用户故事有原始资料引用，每个功能需求映射到至少一个用户故事。
  3. 可度量性验证：所有成功标准均包含指标名称、阈值、数据来源、验证方法四项内容。
  4. 一致性验证：用户故事之间、功能需求之间不存在明显逻辑冲突。
  5. 签收记录：业务方及BA双方在需求基线文档上完成电子签字确认。
← 上一章 📖 返回目录 下一章 →