业务流程 → 功能点：软件要提供什么能力

业务流程描述「用户怎么完成任务」，功能点描述「软件需要提供什么能力来支撑这个流程」。这一条线：分析业务流程，得到功能点。它是四条分析链的第二条。

一、从流程到能力

用户的任务不能由用户自己完成——要由软件提供能力来支撑。分析业务流程，就是要找出：每一步流程，软件需要提供什么能力。

1
2
3
业务流程：查看进程 → 选择进程 → 打开进程 → 读取信息 → 显示
  ↓ 每个环节都需要软件能力支撑
功能：列出进程 / 打开进程 / 读取进程信息 / 显示信息
1
2
3
4
5
6
7
流程步骤          需要的软件能力
──────────────────────────────────
查看进程       →  枚举进程列表
选择进程       →  按 PID 定位进程
打开进程       →  打开进程句柄
读取信息       →  读取进程信息
显示           →  输出格式化

功能不是凭空设计的——它从业务流程的每一步反推出来。

二、功能点：把功能拆到可设计的最小单元

一个功能可能很粗（「管理进程」），需要继续拆成功能点：

1
2
3
4
5
功能：管理进程
  ├── 功能点：列出进程
  ├── 功能点：查看进程详情
  ├── 功能点：结束进程
  └── 功能点：设置进程优先级

为什么必须拆成功能点？ 因为设计、实现、测试都要以功能点为粒度：

1
2
3
4
5
6
7
功能点 = 可独立设计的最小功能单元
  有目标    这个功能点要达成什么
  有输入    进入这个功能点的数据
  有输出    离开这个功能点的结果
  有约束    边界和限制
  有前置    什么条件下才能执行
  有后置    执行完保证什么状态

以「结束进程」为例：

1
2
3
4
5
6
7
功能点：结束进程
  目标：终止一个正在运行的进程
  输入：进程 PID、权限凭证
  输出：成功 / 失败（权限不足、进程不存在）
  约束：不能结束系统关键进程
  前置：进程存在、有结束权限
  后置：进程已被终止

三、功能点必须找到归属

功能点设计出来不能悬空，必须落到系统的某个模块：

1
2
3
功能点：列出进程   → 进程列表模块
功能点：结束进程   → 进程管理模块
功能点：读取内存   → 内存访问模块

每个功能点必须有系统/模块归属；一个功能点不应无意义地属于多个模块。

这一步同时产生功能点—接口映射：每个功能点都要能通过某个接口被调用到——这是「接口设计覆盖功能」的检查基础。

四、产物：功能点设计文档

1
2
3
4
5
6
7
业务流程分析文档
  ↓
功能设计文档（软件需要哪些功能）
  ↓
功能点设计文档（每个功能拆成哪些功能点）
  ↓
功能点—模块归属 / 功能点—接口映射

功能点设计文档是下一条线（功能点 → 功能流程）的输入。

五、和其他线的关系

1
2
3
4
5
6
7
8
9
10
11
业务流程 → 功能点 ←→ 业务系统（系统角色）
  功能点分配到模块 = 业务系统「功能—模块映射」的分析侧来源

业务流程 → 功能点 ←→ 单一职责
  功能点的粒度 = 一个功能点只做一件事（单一职责在功能层的体现）

业务流程 → 功能点 ←→ 工程控制
  「每个功能点必须有归属」= 需求追踪在功能层的落实

业务流程 → 功能点 ←→ 接口
  功能点—接口映射决定接口要覆盖哪些功能

收束

1
2
3
4
5
6
7
8
9
业务流程（用户怎么完成任务）
  ↓ 反推软件需要的能力
功能（软件要提供什么）
  ↓ 拆到可设计的最小单元
功能点（目标/输入/输出/约束/前置/后置）
  ↓ 落到模块、映射到接口
功能点—模块归属 / 功能点—接口映射

功能点 = 设计、实现、测试的粒度单位

业务流程回答「用户怎么完成」，功能点回答「软件要提供什么能力来支撑」——功能点再交给下一条线：功能点 → 功能流程 + 算法设计。