需求分析 → 业务流程：用户要完成什么任务

需求回答「用户要做什么」，业务流程回答「用户怎么一步步完成任务」。这一条线：分析需求，得到业务流程。它是四条分析链的第一条——之后才是「业务流程 → 功能点」和「功能点 → 功能流程 + 算法设计」，而数据结构来自另一条独立的设计链（见线 04）。

一、需求分析：从想法到需求点

开发不是从「写代码」开始，而是从「想法」开始。想法先要被分析成需求：

想法（模糊的、零散的）
  ↓
问题分析（要解决什么问题）
  ↓
需求分析（要做什么）
  ↓
需求点（一条一条可追踪的需求）

例如「做一个进程管理器」：

想法：我想看看电脑里有哪些进程在跑
问题：怎么查看、怎么结束不想要的进程
需求：列出所有进程、查看进程详细信息、结束进程
需求点：① 列出进程 ② 查看进程详情 ③ 结束进程

需求点的关键：每个需求点都能被追踪——后面设计的功能、写的代码、做的测试，都要能对应回某个需求点。这是工程控制线里「确保每个需求都有归宿」的分析侧版本。

二、业务流程：用户怎么完成任务

需求点说「要做什么」，业务流程说「用户怎么一步步完成」：

1
2
3

需求点：查看进程详情
  ↓
业务流程：查看进程 → 选择进程 → 打开进程 → 读取信息 → 显示

业务流程由四样东西构成：

业务入口     什么事件/操作开始这个流程（点击查看）
业务步骤     用户一步步做什么（选择 → 打开 → 读取）
业务规则     过程中要遵守的规则（权限不够就拒绝）
业务结果     流程完成后的结果（详情页面显示出来）

业务对象和业务关系也从这里产生——流程里出现的名词（进程、权限、详情）就是候选的业务对象，它们之间的关系（进程拥有权限、进程包含信息）是业务关系。

三、产物：业务流程图

分析结果要落成产物，否则无法作为下游设计的输入：

需求点设计文档
  ↓
业务流程分析文档（描述用户如何完成任务）
  ↓
业务流程图（可视化的流程）

业务流程图是「设计表示」线里八种表示方式之一——流程用流程图表达，因为它的重点是步骤顺序。

四、游戏的对应物：游戏规则流程

普通软件分析的是「用户要完成什么任务」，游戏分析的是「游戏世界里会发生什么」：

1 2	桌面软件：查看进程 → 选择进程 → 打开 → 读取 → 显示 ← 业务流程游戏：玩家移动 → 遇敌 → 碰撞 → 扣血 → 死亡 → 掉金币 ← 游戏规则流程

两者结构相同，都是「事件 → 步骤 → 结果」：

1 2	桌面软件的业务流程 → 产生 Service（业务模块）游戏的游戏规则流程 → 产生 System（游戏规则模块）

普通软件围绕用户操作流程分析，游戏围绕世界运行规则分析——这是两条领域对象分析线的来源（一般软件 vs 游戏/建模）。

五、和其他线的关系

需求分析 → 业务流程 ←→ 领域对象分析（一般软件）
  对象从业务流程/业务名词里挖出来，是同一套分析的另一个侧面

需求分析 → 业务流程 ←→ 领域模型
  业务流程产生的业务对象和关系，是领域模型的素材

需求分析 → 业务流程 ←→ 业务系统（系统角色）
  分析出的业务流程最终落在业务系统的 Service 模块里

需求分析 → 业务流程 ←→ 工程控制
  需求点可追踪是「确保每个需求都有归宿」的分析侧前提

需求分析 → 业务流程 ←→ 设计表示
  业务流程的产物是业务流程图（流程类表示方式）

收束

想法 → 问题 → 需求 → 需求点        ← 需求分析（要做什么）
需求点 → 业务动作/规则/入口/步骤/结果 ← 业务流程（怎么一步步完成）

业务流程 = 用户完成任务的操作序列
  + 业务对象/业务关系（领域模型的素材）

产物：业务流程图

普通软件 → 业务流程 → Service
游戏     → 游戏规则流程 → System

需求分析回答「要做什么」，业务流程回答「怎么完成」——完成的分析交给下一条线：业务流程 → 功能点。