上一次评审会开到最后会议室里吵成了一片。业务说需求文档第43页写的支持批量导入不只是导入还要包含字段校验开发说校验本来就应该是导入功能的一部分测试组问那这到底算一个用例还是十个用例。我中途打断把电脑连上投影仪翻到一周前画好的系统功能图。屏幕上没有密密麻麻的文字只有四层、二十几个功能框实线表示数据流向虚线表示控制触发。会议室安静下来二十分钟后所有人都点了头。这正是功能图的价值。它不负责描述怎么实现也不纠结数据存哪它只回答一个问题这个系统到底要做哪些事。今天这篇是这个系列的第32篇聊功能图的产生和基本概念。无论你做软件需求分析、系统架构设计还是工业控制逻辑梳理只要面对的是一个稍复杂的系统功能图都是帮你从一团乱麻里走出来最有效的工具之一。1. 为什么会有功能图软件危机与系统复杂度的双重挤压1.1 文字需求文档失效的那一天功能图的出现不是某个理论家坐在书斋里凭空想出来的它背后是真实且惨痛的工程教训。上世纪六七十年代软件行业进入所谓的软件危机阶段大型系统开发周期一拖再拖预算一超再超交付后缺陷率居高不下。我研究过当年的失败案例报告有一个共同点——团队手里攥着一叠几百页的文字需求规格说明书可到了开发阶段每个人理解的系统都不一样。原因是明显的。人类阅读文字是线性的而系统的功能结构是网状的。一段文字描述订单处理流程写清楚主流程可能就要三页纸但这三页纸里涉及的校验规则、异常分支、外部接口却散落在不同章节。读者看完第三章想翻第五章翻完第五章又要回看第二章几百页文档读下来脑中对系统整体结构的映像往往是碎片化的。更麻烦的是每个人按自己的阅读顺序构建出了不同的全局图。结构化分析方法就是在这个背景下逐渐成型的。它的核心主张可以概括成一句话在写代码之前先把系统画出来。用什么画用图。数据流图画数据的流动状态转换图画状态的变迁功能图就负责把系统能做什么事结构化地摊开。功能图在那个年代被吸纳进系统分析工具箱不是因为它时髦而是因为它是唯一能快速回答这系统到底有哪些功能、功能之间什么关系的载体。1.2 功能图在建模体系中的位置数据流图、控制流图之外的另一根支柱刚接触建模的读者常会把功能图和数据流图混在一起这两个画的都是方框加箭头但它们在回答完全不同的问题。数据流图的核心是数据订单从外部实体流入系统经过校验处理变成合法订单再写入数据库。它通篇讲的是数据的来龙去脉。控制流图的核心是执行顺序先做什么、再做什么、条件为真走哪条路。它通篇讲的是流程的流转。功能图的核心是能力系统能校验订单、能计算价格、能生成报表。它通篇讲的是系统对外提供的能力清单以及这些能力之间通过什么输入输出发生关联。三者的分工我用一个简单例子说明。一个电商后端系统数据流图会画出用户提交订单→订单数据进入队列→库存服务消费队列→扣减库存→回写结果控制流图会画出如果库存充足则发货否则进入缺货流程功能图则画出订单提交库存扣减缺货通知退款处理这样一组功能模块并标出它们之间的输入输出接口。打个比方数据流图是物流干线控制流图是红绿灯规则功能图则是城市功能分区图——你得先知道这座城市有哪些片区再看区内怎么运输、怎么管制。在很多真实项目中这三类图是配合使用的。功能图先行把系统的功能边界和外部接口定下来数据流图跟进细化每个功能的数据交互控制流图最后登场规定功能的执行时序。脱离了功能图直接画数据流或控制流很容易画着画着就迷失在细节里因为缺少一张总地图把关全局。2. 功能图到底画什么核心概念的一次说清2.1 功能图的本质图里装的全是动词我给学生讲功能图时最爱用的开场白是功能图里每一个方框都应该代表一个动词名词的短语。为什么是动词因为功能描述的是行为。一个系统不会是什么它只会做什么。订单管理听起来像个名词但其实它是一个浓缩的动词短语管理订单。而在实际绘制中我一般要求团队把这个短语写得更完整新增订单修改订单取消订单导出订单。功能图最忌讳用纯名词比如一个框写订单模块那等于没说清楚这个模块到底承担哪些行为责任。功能图描述的对象是系统本身是系统的功能集合以及功能与功能之间的输入输出、触发控制关系。它与软件架构图有本质区别架构图画的是结构哪些组件、怎么部署、怎么连接功能图画的是行为系统能做什么、每个功能需要谁来支持、产出什么交给谁。一个偏静态一个偏动态。很多团队在需求阶段就画架构图把怎么做放在做什么前面这是常见的顺序颠倒。2.2 一个最小示例自动售货机的功能图概念讲得再多不如一个例子直观。我用自动售货机来演示功能图的分层结构。最高层上下文图只有一个功能框自动售货服务。外部实体是顾客和运维人员二者分别向系统发送投币/选货/取货和补货/取款的动作系统反馈出货/找零和货道状态/收款记录。往下分解一层自动售货服务可以拆成四个主功能自动售货服务 ├── 1. 处理支付 │ ├── 1.1 识别货币 │ ├── 1.2 校验金额 │ └── 1.3 计算找零 ├── 2. 管理货道 │ ├── 2.1 读取货道库存 │ ├── 2.2 更新货道数量 │ └── 2.3 检测缺货 ├── 3. 执行出货 │ ├── 3.1 定位货道 │ ├── 3.2 驱动机械臂 │ └── 3.3 确认出货成功 └── 4. 上报运营数据 ├── 4.1 汇总销售记录 ├── 4.2 生成补货清单 └── 4.3 推送告警信息这张图回答了很多问题。支付完成后数据流给执行出货一个触发信号那么计算找零和驱动机械臂是并行关系检测缺货出现后数据流会一路向上汇总到生成补货清单。两种连接方式——数据流和控制流——在图上用不同线形区分语义就清清楚楚。2.3 功能图与相邻概念的边界功能图在实践中有几个近亲经常被混为一谈。我做一个表把边界划清楚。概念核心关注点典型元素与功能图的关系功能图系统具备哪些能力能力间的输入输出功能模块、数据流、控制流本文主角数据流图DFD数据从哪里来、经过哪些加工、到哪里去外部实体、处理、数据存储、数据流功能图常与它并存DFD更强调数据走向用例图UML参与者通过系统完成哪些目标参与者、用例、关系用例图从用户视角出发功能图更接近系统内部视角功能块图FBD工业控制中功能块的逻辑连接功能块、输入输出端子、连接线工业控制领域的功能图源于IEC 61131-3标准举一个实际区分用例图和功能图的例子。一个在线考试系统用例图会画「考生-参加考试」「教师-出题」「管理员-发布考试」讲的是谁用系统干什么。功能图则会画「组卷抽题/拼卷/排版」「监考防切屏/异常记录」「阅卷客观题自动批/主观题人工批」讲的是系统内部提供了哪些能力。前者服务需求采集后者服务系统设计二者可以互相印证但不能互相替代。3. 一张功能图的基本骨架四大核心要素拆解3.1 功能模块命名与粒度的拿捏功能模块是功能图上最基本的图元一般用矩形框表示。每个模块承载一个相对独立的功能命名格式建议统一为动词宾语。命名这件事看似简单实际是功能图绘制中分歧最大的环节。我见过团队为了一个框叫订单管理还是编辑订单争论二十分钟。其实判断标准很简单如果这个功能内部还存在明显差异化的子行为就用更细的动词短语如果它已经是原子操作直接写清楚动作本身。订单管理这种词模糊在管理到底包含哪些动作编辑订单就明确指向某一次操作。粒度的把握还要考虑图的服务对象。如果顶层图是给高层评审看的模块粒度可以粗到订单域库存域支付域级别到了底层图面对开发人员粒度就要细到能对应到一个可估工的工作项。很多画图画到一半卡壳的团队问题不是技巧不够而是没想清楚这层图到底画给谁看。3.2 数据流与控制流信息与指令各走各的道功能模块之间的连线有两种基本语义。数据流传递的是信息比如订单对象、库存数量、支付结果控制流传递的是触发比如事件、信号、调用指令。这在很多标准画法中用实线和虚线区分方便一眼看出哪些连接是数据往来、哪些是行为驱动。我自己的经验是在大多数项目里功能图里 80% 的连接其实是数据流控制流通常只在表达某功能完成后才能启动下一个功能时出现。控制流泛滥往往是设计出了问题的信号——如果一个功能图里满屏虚线说明团队很可能把流程逻辑和功能结构混在一起画了。遇到这种情况我会建议把虚线抽出来单独画一张控制流图或时序图功能图先保持它能力地图的纯粹性。3.3 外部实体与数据存储系统的两个边界邻居功能图不能只画系统内部。原因很简单一个功能如果没有输入来源和输出去向就无从验证它是否完整。外部实体和数据存储就是为功能图提供上下文的两类要素。外部实体表示系统之外的参与者可能是人、外部系统、硬件设备。它们位于系统边界之外通过功能模块的输入输出与系统交互。数据存储表示系统需要长期保存的信息在功能图中通常用开口矩形或专门的存储图标表示。数据存储的价值在于暴露这个功能要不要落库的决策如果某个功能产生了数据却没有任何存储指向评审时顺手就能抓出缺失。画外部实体时最容易犯的错误是把边界无限扩张。一个后台管理系统数据库、消息中间件、第三方短信服务都算外部实体但如果把运维监控系统也画进来图就失控了。我在项目里一般会定一条规则与系统有直接数据交换的才算外部实体隔了一层的间接依赖不画。3.4 分层分解自顶向下拆功能的递进逻辑功能图之所以能应对复杂系统靠的是分层分解。整个思路是从抽象到具体逐层细化。顶层叫上下文图只有一个功能模块代表整个系统周围挂上外部实体和主要数据流表达的是系统的对外接口全貌。上下文图往下是0层图把系统拆成几个一级功能域每个一级功能域再展开成1层图以此类推直到每个叶子功能都足够具体可以直接指导设计或评估工作量。这里有一个重要的编号约定。我在项目里习惯用父编号.子序号的方式给功能模块编号比如2.3表示二级功能2管理货道下的第三个三级功能检测缺货。编号是功能图分层结构的关键索引评审时只需要说我们看2.3这个功能所有人立刻定位到同一个模块。没有编号的功能图就像一本没有目录的书泛读还行精读就乱了。4. 从零绘制一张功能图实操方法与常见标准4.1 画图前的准备边界、功能清单与评审人新手拿到需求文档就急着开画通常画到第三层就推倒重来。我建议画图前先做三个准备动作。第一划边界。明确这个图描述的系统边界在哪。比如做订单子系统还是做整个电商平台边界的差异直接影响功能图的范围也决定了外部实体是谁。第二提取功能清单。从需求文档中筛出所有动词短语这是原始功能素材。第三确定读者。给业务方看还是给研发看决定了分层的深度。这三个准备做完画图时就不会反复推翻结构。提取功能清单有一个实用技巧把需求文档翻到最后看验收标准里的每个可应能字句几乎每一个系统应支持某操作都能对应一个功能模块。我自己经常用高亮笔把这类句子标出来再汇总成表。这比凭印象猜功能要靠谱得多。4.2 六步绘制法从上下文图到叶子功能我画功能图有一套固定的流程走了很多项目后稳定成六个步骤。第一步画上下文图。一个框写系统名四周画外部实体连上数据流。第二步定一级功能域。按业务域或者能力域划分一般控制在5到9个模块超过9个说明一级划分太碎。第三步逐域展开二级功能。这一步开始出现数据流交叉需要特别标记跨域的数据输入输出。第四步持续分解到叶子功能。叶子功能的判断标准是它是否已经是一个完整操作的最小描述。第五步标注编号和数据流名。第六步反向走查。从每个叶子功能出发问三句话它的输入从哪来输出到哪去触发它的是谁答不上来就说明这张图有洞。第二步里有一个常见决策点按业务域划分还是按技术域划分。我建议在早期功能图中坚定地按业务域划分因为功能图是需求分析阶段的产物服务对象是人对业务信息的理解。技术域划分属于架构设计阶段的事提前引入会让图变得晦涩难懂。4.3 工业控制里的功能块图另一种功能图的表示法功能图这个术语还有一个不能回避的语境就是工业自动化领域的IEC 61131-3标准。标准定义了PLC编程的几种语言其中功能块图FBD在现代工业控制里使用率相当高。FBD里的功能块本质上也是模块化功能的概念但它的视角跟软件需求分析里的功能图有些不同。FBD的核心是功能块每个块有输入端子和输出端子块之间用连线传递数据。一个PID控制块接收设定值和测量值输出控制量一个逻辑与块把两个布尔量缩成一个。程序员把若干块连成网络就构成了控制逻辑。它更接近逻辑电路图的思维而软件需求分析中的功能图是业务能力地图的思维。前者强调可执行的计算逻辑后者强调可沟通的需求边界。我给做工业控制项目的读者的建议是如果你要对外解释整套产线的自动化策略先用传统功能图画出控制系统的功能分布再对单个控制回路用FBD进行详细设计。两个功能图配合使用一个负责让项目各方看懂全貌一个负责让工程师写代码不出歧义。4.4 人机系统功能分配一个常被忽略的绘制维度很多功能图画到最后默认所有逻辑都是系统自动完成的。但现实中大量系统是人机混合系统有些功能由人完成有些由机器完成甚至同一功能的不同阶段分别由人和机器处理。功能图这时又多了一层作用展示人机功能分配。举个例子一个银行信贷审批系统资料录入、规则校验、征信查询都可以由系统自动完成但最终授信决策通常保留给人工审核员。在功能图上这个决策功能模块的外围要多一条外部实体连线指向审核员。这样评审时就非常直观哪些环节需要配备人力哪些环节自动化程度高瓶颈大概率出现在人机交接处。画这类系统时我会在功能图中用不同底色区分自动功能和人机协同功能并在图例中说明。这个做法在跨部门评审时价值很大业务方看到哪些事是人做的技术方看到哪些事要系统支撑一张图把两个视角粘合在一起。5. 功能图在真实工程里的价值从需求对齐到测试拆解5.1 评审会上靠一张图把各方拉到同一频道文章开头那个评审会的场景不是段子是我这几年体会最深的功能图实际价值。没有功能图的需求评审本质上是各方在各自的文字理解里互相猜。业务按业务惯性理解订单流程开发按代码模块理解订单流程测试按测试场景理解订单流程。三个人能对同一句需求文档产生三种不同的功能认知原因很简单文字描述的展开顺序是线性的但不同人关注的重点不同读出来的上下文就不同。功能图把这种隐性的认知差异直接摊到桌面上。图上有多少模块、模块之间怎么连接看得到的东西没法争辩。某功能画在A域还是B域某条数据流标得对不对某两个模块之间是不是漏了一条线这些讨论都是具体的、可裁决的。一场评审能不能高效收尾取决于参会者是针对着一张共同的地图讨论路线还是各自拿着一张自己脑补的地图对答案。功能图保证的是前者。5.2 把叶子功能变成测试点功能图到测试用例的映射功能图还有一个被低估的作用它是测试用例设计的精准底图。我参与过的一个模拟项目X需求文档写完两周后测试部反馈不知道要测什么整个团队陷入了典型的测试盲区。后来我们把系统的功能图铺开从叶子功能出发为每个叶子功能至少设计一条正向用例和一条反向用例测试场景立刻变得清楚可见。功能图到测试用例有直接的映射逻辑。每个叶子功能对应一个功能测试点功能模块间的每条数据流对应一个集成测试点控制触发关系对应一个时序测试点。再结合具体业务参数用例数量一下子就膨胀到几百条。如果某些叶子功能想不出它对应的测试场景那通常不是测试人员的问题而是功能本身定义得不清楚。操作上我习惯把功能图和用例追踪矩阵对起来行是功能模块编号列是测试用例ID。评审时看着矩阵任何功能改动都能快速圈出受影响的用例范围。很多团队花大价钱上测试管理系统不如先把功能图的编号体系建立起来——矩阵的骨架说到底就是功能分解结构。5.3 用功能图做变更影响分析改一个功能牵动哪些邻居需求变更在软件项目里不可避免真正让人头疼的是不知道一次改动会波及多远。功能图在这时扮演影响分析地图的角色。假设某开发团队要改自动售货机系统里驱动机械臂这个功能。没有功能图时改动的影响面只能靠资深开发的个人记忆风险不小。有功能图时沿着驱动机械臂这个模块的连线找立刻看到它从执行出货接收控制触发、向确认出货成功返回结果、和更新货道数量有数据交换。这三个方向就是改动的影响面。更远一层的分析要沿着数据流继续向上走货道数量变化会流向检测缺货检测缺货又流向生成补货清单。一次小改动追溯到底竟然影响了运维端。这就是功能图分层结构带来的可追踪性。变更评审会看这张图该通知谁、该改哪些模块、该补哪些测试一目了然。5.4 防止功能蔓延图上的新增框其实是需求变更信号功能蔓延是需求膨胀的行业通病表现是开发过程中不断加功能范围越滚越大。功能图反而是控制功能蔓延的一个高效载体因为它把功能边界画在明面上。我管理项目时有一个惯例每次需求变更要求相关人在功能图上新增或修改模块并在图上标注变更日期和变更原因。等到一个迭代结束翻开功能图数一数新增框和修改框范围变化一目了然。如果某一次迭代新增了20个功能框不管再怎么强调都是小改动范围膨胀的现状也不容辩护。更重要的是功能图新增框往往伴随着原有连线结构的改变。一条数据流改了走向可能意味着两个原本独立的域产生了新耦合。对这种结构层面的变化团队在评估工作量时必须有意识地加权。我见过不少项目单个功能开发量估得挺准却反复栽在功能关联变更上原因就是没人愿意从全局图结构看变更。6. 画了多年功能图才想明白的几个问题6.1 这个功能要不要拆——粒度的三个判断标准画到什么程度算完是团队里被问最多的问题。我摸索出一套判断标准供读者参考。第一看看还有人能用。如果这个模块还需要被更上层的决策逻辑引用而你又无法用一句话说清它内部的行为那它就是该拆的。一个框如果描述不清它的行为内容多半是装了两个以上功能。第二看工作量粒度。底层功能模块最好能对应到不超过一个迭代周期的开发工作量过大的模块意味着还要往下拆。第三看复用机会。同一个动词短语出现在两个不同父模块下说明这个底层功能值得独立出来避免重复建模。按这个标准拆完大概每一层模块数量都会落在5到9个之间。这个数字范围是因为人脑短期记忆的带宽有限一层的待处理项超过9个理解成本急剧上升。真正的复杂度不是画在图上而是藏在一个看起来很大的框里需要靠拆分让复杂度显形。6.2 功能之间扯不清警惕四种坏味道画多了功图图你会发现有些图怎么看怎么别扭但就是说不清哪里有问题。我总结出四个典型的坏味道供读者自查。第一个是基类依赖两个功能模块看起来平级但其中一个总是先从另一个拿数据再干活实际是隐含了层级关系。处理方式是把共享的数据提取到一个公共存储或公共功能模块中。第二个是消息链A传给BB处理后又传给CC再返给A连线绕成一圈。这种图要警惕循环依赖分析它是否能用事件解耦。第三个是过宽接口两个模块之间连了七八条数据流往往不是它们关系密切而是其中一个模块粒度过大职责不纯。第四个是孤岛模块某个模块没有任何连线或者只有一条输入没有输出。孤岛模块意味着系统里有一个说不清楚的影子功能。遇到这些坏味道我通常的做法是把有问题的局部放大打印出来单独约相关开发做半小时的图走查。不要试图在评审大会上解决局部结构问题那样既浪费全体时间又容易让当事团队产生防御心理。小范围对齐后再更新全图效率高得多。6.3 工具与协作别让画图本身变成负担工具选择看起来是个小事但我在不同项目里试过各种方式深切体会到工具选错会让画图热情迅速熄灭。整个迭代项目中最得当的做法是草图阶段用白板任何人随时可以擦改评审阶段拍照留存进入基线后统一用一款大家都装得上的绘图工具维护。工具本身不是重点画图的过程协作才是。我见过团队为了所谓工具的统一性把图画得极其精致但没有人愿意修改——图一旦变成艺术品就失去了作为沟通媒介的生命力。版本管理也值得说一句。功能图和代码一样有版本每个基线版本都应该能回溯。我在迭代中养成的习惯是每个迭代初更新一次功能图基线迭代中所有小修改先标记待确认迭代末统一合并。这样评审方看到的功能图永远是上一轮确认过的稳定版不会因为有人临场画了一笔而陷入新一轮争议。功能图这件事我前前后后画了十几年最大的体会是它不解决技术难点但它能防止团队在错误的方向上耗费技术资源。很多棘手的技术争论追到根子上其实是对系统到底要做什么的理解不一致。功能图把一个模糊的共识变成白纸黑字之后的代码分歧、测试分歧、验收分歧都会小得多。如果你现在正被一个复杂系统的需求梳理折磨不妨先在白板上画一张顶层功能图把系统的动词清单列出来。你会发现画着画着很多说什么都说不清的争论就自然地变成了看图形不图出来的讨论。
