评审功能树：辨别真假与两条判断标准

拿到号称是”功能树”的材料后，架构师不能照单全收，首先要能辨别真假功能树——这要求架构师本身要在一定程度上掌握”功能树”这项需求技能。书中举了一个具体反例：设备管理系统里一份号称是”功能树”的结构，实际上是”界面转换图”（若是Web系统则叫”页面流程”）——这根本不是功能树，自然不能据此得出正确的功能模块划分；真正的功能树应该是上级节点为高一级”功能组”、下级节点为”细分功能”，上下节点之间是隶属与支持关系的结构，而不是描述界面之间如何跳转的流程图。辨别出真功能树之后，还要评判这份功能树本身是否”定义良好”，判断标准有两条：一是面向使用，体现使用价值；二是覆盖全面，没有范围遗漏。书中用自动售货机管理系统的一个反面案例说明不合格功能树的样子——”金额累加”算不算功能？故障报警功能有没有？上货人员的功能体现在哪里？钱匣要不要控制？这份功能树同时不满足”面向使用”和”覆盖全面”两条要求，架构师根本无法从中启发出”钱匣控制”这类应有的设计模块；书中直言如果一个更复杂系统的功能树都这样画，架构设计”岂不是死定了”。这两步（辨真假、评好坏）合起来说明：功能树不是需求分析人员甩给架构师、架构师照单全收的输入，架构师有责任、也有能力先对功能树本身的质量把关，发现问题就要求改进，而不是带着一份有缺陷的功能树硬往下做模块划分。