第二步：业务场景与用户故事拆分

本步骤是需求边界界定方法的核心环节，通过场景卡片将抽象的业务需求固化为具体场景，再借助用户故事模板将场景拆解为可交付的功能单元，最后运用边界划分原则明确每个需求的纳入/排除范围。完成此步后，需求边界将从模糊的“业务想法”转化为结构化的“需求边界描述”。

适用场景

• 项目启动阶段：业务方提出初步需求，但范围笼统、粒度不一时。
• 需求澄清会前后：已有干系人清单和业务背景，需系统化梳理需求边界。
• 多部门协同场景：不同角色对“做什么”有不一致预期，需统一语言和边界。
• 迭代规划前：需要将大需求拆分为可独立交付的小单元，便于排优先级。

前置条件

• 已完成第一步：需求干系人识别与分析，输出《干系人清单》与《核心干系人访谈纪要》。
• 已收集业务背景资料（业务流程图、现有系统操作手册、会议纪要等）。
• 已确定核心干系人参与通道（业务代表、产品经理、技术负责人已确认时间）。
• 已准备场景卡片模板和用户故事模板（推荐使用在线协作文档或需求管理工具）。

操作步骤

步骤 1：识别与梳理业务场景

基于干系人访谈纪要及业务背景资料，梳理用户从“触发事件”到“目标达成”的完整业务旅程。重点关注关键触点、决策节点、异常分支，识别出需要纳入需求范围的场景。

• 场景来源：主业务流程、异常流程、边缘流程、合规要求。
• 场景粒度：每个场景应覆盖一个完整的业务目标（如“提交采购申请”为一个场景，而非“点击提交按钮”）。
• 输出记录：暂记《业务场景初筛清单》，包含场景编号、名称、触发条件、期望结果。

步骤 2：创建场景卡片

为每个筛选后的业务场景创建标准化的场景卡片，作为后续用户故事编写的统一输入源。

步骤 3：编写用户故事

从场景卡片中提取每个角色的视角，使用标准用户故事模板将需求转化为可交付的功能描述。每个场景可能产出1~3个用户故事。

步骤 4：应用边界划分原则

对所有用户故事进行边界评审，确保每个故事的需求范围清晰、无交叉、无遗漏。遵循以下四项核心原则：

1. 完整性原则：所有核心业务场景必须被至少一个用户故事覆盖，不允许出现“业务断点”。
   检查方法：将场景卡片与用户故事逐一映射，形成场景-故事覆盖矩阵。
2. 独立性原则：每个用户故事可独立开发、测试和交付，尽量减少故事间的功能耦合。
   判断标准：修改故事A无需同时修改故事B，则A和B独立。
3. 一致性原则：同一业务术语在所有故事中含义相同，角色名称、状态值、业务规则无冲突。
   检查方法：建立统一术语表，作为边界划分的参照依据。
4. 可验证原则：每个用户故事必须附带可测试的验收标准，且验收标准本身不包含模糊词汇（如“快速”“友好”“高效”）。
   反例：“系统响应要快”；正例：“查询结果应在3秒内返回”。

输入输出物

责任边界

记录材料

本章节执行过程中需归档以下材料，作为需求边界界定的过程证据：

1. 《场景卡片集》（最终版，含版本号和修订日期）。
2. 《用户故事列表》（与场景卡片关联，标注优先级和边界状态）。
3. 《场景-故事覆盖矩阵》（用于验证完整性）。
4. 《边界划分评审会议纪要》（包含参会人、争议事项、决议结果）。
5. 《统一术语表》（记录边界划分中使用的业务术语及其定义）。

异常处理

验收标准

完成本章节所有任务后，需逐项检查以下标准是否达成：

1. 完整性检查：所有前置条件中识别的业务场景均已生成场景卡片，且每张卡片的基本流程步骤完整可读。
2. 一致性检查：场景卡片与用户故事满足 1:N 映射关系（1张卡片对应1~3个故事），无“无源故事”或“无故事场景”。
3. 独立性检查：随机抽取20%的用户故事进行依赖分析，不存在“故事A的验收必须依赖故事B的功能已上线”的情况。
4. 可验证检查：每个用户故事的验收标准均为可量化的具体条件，无模糊词汇；且每条标准在现有技术条件下可被测试用例覆盖。
5. 文档归档检查：场景卡片集、用户故事列表、覆盖矩阵、评审纪要、术语表五类材料均已归档，版本号与日期清晰。