说明书（设计说明）被要求补正的材料里，功能模块图是个高频点。它不像截图那样一眼能看出糊不糊，问题往往藏在「图本身挺好看，但和正文、和申请表对不上」这种地方。
今年审核对材料的一致性、真实性查得更细，模块图作为「软件由哪些部分构成」的总纲，值得单独规范一遍。下面按「为什么容易被挑」到「怎么画」讲清楚。
一、模块图为什么容易被挑出来
文字描述可以写得比较宽松，模块图不行——它是一张有结构的声明：你声明了这个软件由哪几个模块组成、谁调用谁、层级怎么分。审核端拿它主要是去比对两件事：
- 和申请表「主要功能和技术特点」对不对得上：申请表里写了哪几项功能，图上就得有对应的模块，多一个少一个都可能被追问
- 和正文的功能描述对不对得上：正文讲到某个功能，模块图里应该有它落脚的位置
只要这两条有一条说不通，就容易收到「请补充说明」的意见。注意，这里要的不是图更好看，而是三处描述彼此自洽。
二、一张合格的模块图，通常有三层
很多人只画一张「大首页 + 几个方框」的总图就交了，这是最常见的单薄点。比较稳的做法，是让模块图体现出层次：
| 层次 | 画什么 | 作用 |
|---|---|---|
| 总体结构图 | 整个软件分成哪几个一级模块 | 给出全局骨架 |
| 模块分解图 | 每个一级模块下面有哪些子功能 | 说明功能深度 |
| 关键流程图 | 2～3 条核心业务从进入到出结果的过程 | 证明功能真的串得起来 |
三层都有的好处是：审核顺着「总—分—流程」看下来，功能是被证明存在的，而不是只被罗列了一遍。如果软件本身不复杂，第一层和第二层可以合并成一张，但关键流程那一层建议保留。
三、画的时候，这 5 个细节最容易出错
1. 模块命名要和正文、申请表统一。 同一个功能，正文叫「订单管理」，图里就别写成「订单处理」，申请表里更不要写成「单据模块」。三处用词不一致，是「信息对不上」最典型的来源。建议先把功能名固定成一份清单，三处都从这份清单里取词。
2. 模块粒度要齐。 一级模块下面，不能有的模块分了 5 个子项、有的一个都没有。粒度忽粗忽细，会让人觉得是为了凑图而画。同一层级的模块，展开程度要大致相当。
3. 箭头方向要表达真实关系。 结构图里的连线是在说「谁包含谁 / 谁调用谁」，不是装饰。数据流向、调用方向、包含关系，三种含义别混在一张图里不区分。要用不同线型或图例说明清楚。
4. 层级不要太深，也不要太浅。 一般三层左右够用：系统—模块—子功能。层级过深（五六层）说明拆得过细，反而不好对照；只有一层又证明不了结构。能对应到正文的功能颗粒度，就是合适的深度。
5. 图要能独立看懂。 每张图配图号（图 1、图 2……），正文用「如图 N 所示」引用；图里出现的缩写、英文名，要么在图注里解释，要么换中文。别让审核在一张图上猜。
四、和申请表怎么对齐（这一步最省事）
一个很实用的顺序是先定功能清单，再画图：
- 从申请表「主要功能和技术特点」里，把功能逐条抄成一份清单
- 把这份清单归并成几个一级模块
- 照着模块和功能，画总体结构图和分解图
- 回头检查：图上的每个模块，都能在申请表和正文里找到对应；申请表里的每项功能，图上都有位置
这么走一遍，「图上有的正文没有」和「正文有的图上没有」这两类问题基本会一次性暴露出来。它本质上是做一次交叉核对，而不是画一张好看的图。
五、提交前自查清单
- 有总体结构图，功能较多的还有模块分解图
- 保留了 2～3 条核心业务的流程图
- 模块名在「申请表 / 正文 / 图」三处用词完全一致
- 同一层级的模块，展开粒度大致相当
- 连线含义有图例区分，方向不乱
- 每张图有图号，正文用「如图 N 所示」引用得上
- 图里的缩写、英文名有解释
- 图上每个模块都能在申请表功能里找到对应，反之亦然
最后提醒一句：模块图不是设计稿，它要和软件实际做出来的功能一致。 图纸画得再规整，如果图里的模块在界面上找不到，一致性这一条还是过不了。先把功能做实，再把它画清楚，顺序不要反。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/2601_96557149/article/details/167117551
