功能结构图用层级关系说明一个系统由哪些功能组成:顶层是系统,下面是功能模块,再往下是具体功能。本篇用“在线课程报名系统”从目标边界画到功能树,并在树旁补充输入输出和验收说明,让产品、研发与测试能用同一份结构讨论范围。

功能结构图和页面导航有什么区别
页面导航回答“用户从哪里进入、点击什么”;功能结构图回答“系统需要提供哪些能力,以及能力之间怎样组合”。例如“课程列表页”是页面,“课程检索、名额校验、报名状态通知”是能力。一个页面可能调用多个功能,一个功能也可能被多个页面复用。
如果把页面直接当功能,评审会漏掉后台校验、异常处理和数据交接。绘图前先写系统目标与不在范围内的内容,再决定拆分粒度。这里讨论的是软件功能的层级分解;如果要表达模块调用、数据流或操作先后,应另画关系图或流程图,不让同一条线同时承担几种含义。
第一步:写目标、边界和使用者
以报名系统为例,可以先写:
- 目标:让用户完成选课、提交报名并获得可追踪的状态。
- 使用者:学员、课程管理员、客服和财务。
- 输入:课程信息、用户资料、库存或名额、支付结果。
- 输出:报名记录、状态通知、统计数据。
- 不在范围:课程内容生产和线下授课安排。
边界写在图的左上角或备注区。没有边界时,团队很容易把“推荐课程”“营销活动”等相邻能力无限扩进来。
第二步:从目标拆出一级能力
一级模块应按稳定能力划分,而不是按当前页面划分。报名系统可以先拆成:
| 一级模块 | 要解决的问题 | 典型输出 |
|---|---|---|
| 课程发现 | 用户如何找到合适课程 | 列表、筛选结果、课程详情 |
| 报名提交 | 用户如何提交并确认报名 | 报名单、校验结果 |
| 状态与通知 | 用户如何知道处理进度 | 成功、失败、待处理状态 |
| 运营管理 | 管理员如何维护课程和名额 | 课程配置、名额记录 |
| 数据与审计 | 团队如何复盘和追踪 | 报名报表、操作日志 |
一级模块数量不必追求固定。若一个模块既包含用户动作又包含后台规则,可以继续拆分;若模块只有一个页面名称,通常说明拆分仍停留在导航层。
第三步:拆成功能单元,并写清输入输出
功能单元要具体到团队可以讨论实现和验收。以“报名提交”为例,可以拆成“报名资料管理、资料校验、名额校验、报名记录创建、提交结果反馈”。这五项在树上是同级子功能,不靠从左到右的位置表示执行顺序。节点名称保持简短,详细规则放在旁边的说明表,至少补充四个字段:
| 字段 | 示例 |
|---|---|
| 触发 | 用户点击提交 |
| 输入 | 课程 ID、用户 ID、报名资料 |
| 处理 | 校验、名额锁定、写入记录 |
| 输出 | 成功状态或可解释的失败原因 |
“支持报名”仍然太宽;“提交资料后校验必填项,缺失字段在对应位置提示”已经能转成验收场景。继续把同一层的功能补齐,能更容易发现遗漏:
| 编号与功能 | 输入 | 输出 | 要补的规则 |
|---|---|---|---|
| F2.1 报名资料管理 | 学员填写的资料 | 待提交资料 | 哪些字段必填,能否修改 |
| F2.2 资料校验 | 待提交资料 | 校验结果 | 错误信息如何对应到字段 |
| F2.3 名额校验 | 班次、当前可用名额 | 可报名或名额不足 | 多人同时报名如何处理 |
| F2.4 报名记录创建 | 通过校验的请求 | 报名编号 | 重复提交不重复建单 |
| F2.5 提交结果反馈 | 报名处理结果 | 成功、失败或待确认信息 | 响应中断后如何查询 |
第四步:补依赖、异常和责任边界
功能树先回答“有哪些能力”,异常说明再回答“失败后由什么能力处理”。对关键单元补三件事:依赖哪个数据或服务、失败后返回什么、谁负责跟进。报名系统需要考虑名额不足、重复提交、通知失败和管理员手动关闭课程;如果本期包含付费报名,还要补支付结果查询及失败处理。
主树的实线统一表示功能从属。依赖和异常可放在独立说明区,使用 F2.3 等编号引用;确需画虚线时,在图例中标明“依赖”,避免读者把它当子功能。支付、报名和通知之间的先后关系则移到配套流程图。功能结构图不必画满所有异常分支,但不能让已知异常在需求材料中消失。
第五步:把功能映射到验收标准
最终评审时给每个叶子节点绑定验收条件,形成“功能—测试—负责人”对照表:
| 功能单元 | 验收问题 | 证据 | 负责人 |
|---|---|---|---|
| 名额检查 | 名额不足时是否阻止提交 | 测试记录与提示文案 | 业务与研发 |
| 重复提交拦截 | 连续点击是否只生成一条记录 | 日志或测试截图 | 研发 |
| 报名通知 | 成功和失败是否分别提示 | 通知规则与样例 | 运营 |
| 管理员关闭 | 关闭后用户是否看到原因 | 权限测试 | 管理员 |
验收表不是功能结构图的替代品,而是让结构可以落到交付。若一个叶子节点无法写出验收问题,说明它可能仍是概念或页面标签。
版式、连线和版本检查
把“课程报名系统”放在顶部,五个一级模块排在下一层,各模块的子功能按同一粒度对齐。连接线从父节点连到子节点边缘,输入输出说明放在树旁。评审前标明版本与日期;需要移除的功能先记录取舍原因,再从当前范围中移出。
在 Boardmix 工作台登录并新建白板后,可以使用“基本图形”添加矩形,用“文本”填写模块名,再用“连接线”建立父子关系。先完成一个“报名提交”分支,再按同一层级扩展其他模块;同级节点使用一致的外框、填充和字号,避免颜色被误读成重要程度。
在图右侧用表格放置 F2.1—F2.5 的规则,评论具体落在有争议的功能旁。例如,研发询问“名额锁定后多久释放”,产品补充条件后,再同步更新 F2.3 的说明和验收表。Boardmix 官方帮助中心提供基本图形、连接线、表格、评论和分享的使用说明,这些工具可以把讨论留在功能对应的位置。
想借用现有结构,可先查看社区的产品功能结构图模板,再把原有业务模块替换为自己的系统。本例仍以五个课程报名模块为准,不照抄模板中的页面栏目。分享时确认协作者权限;导出图像或 PDF 前,检查功能树和说明表能否一同读清。需要了解其他图的分工,可继续查看功能模块图的组成与作用。

功能结构图完成前检查清单
- 已写目标、使用者和不在范围内的内容。
- 一级模块表达能力,不只是页面名称。
- 叶子节点包含触发、输入、处理或输出。
- 关键依赖、异常出口和责任边界可追溯。
- 每个重要功能都有验收问题和证据位置。
- 连接线不遮挡文字,层级粒度前后一致。
- 当前版本、废弃项和修改日期可区分。
FAQ
功能结构图需要画到按钮级别吗?
通常不需要。画到能够分配责任、讨论依赖和编写验收条件的粒度即可;按钮位置属于交互或页面设计,应该在相关文档中继续展开。
功能结构图和流程图能放在一起吗?
可以放在同一画布,但建议分区。结构图表达“有哪些能力”,流程图表达“能力如何按顺序运行”,混在一棵树里会让读者误把层级当成时序。
功能结构发生变化后如何避免漏改?
给每个一级模块和叶子节点保留编号或稳定名称,变更时同时更新验收表、流程图和负责人。废弃节点移到历史区并记录原因,不要直接覆盖后只保留最新截图。

