获取功能树的三种途径与多种呈现形式

要用[[从功能组到功能模块的核心原理]]划分功能模块，第一步是拿到功能树，获取途径总体有三种：拿到文档、进行沟通、分析产品。文档途径：《软件需求规格说明书（SRS）》应该系统化地描述各种功能，是功能树最可能出现的地方——如果SRS里没有”显式”画出功能树，留意它目录的”章-节-小节”结构，往往就直观体现了功能树；如果希望在SRS提交之前就尽早开始架构设计，可以关注更上游的文档，比如《愿景文档》（分析机会、陈述价值、刻画功能体系时会用到功能树）和《方案建议书》（梳理需求背景、明确设计原则、刻画系统方案、对比方案优势时可能用功能树）。沟通途径：和业务人员、需求分析人员沟通获取信息，自己梳理功能树。分析产品途径：如果要设计的是产品4.0版本，不妨研究3.0版本的产品、文档、市场彩页；也不要忽视竞争对手公司的产品资料，甚至可以运行竞品，从它的UI界面里获取梳理功能树所需的信息。这三种途径背后有一个共同的启发：功能树除了常见的”树状结构”，实践中还可能以”列表结构”“表格结构”“功能框图结构”等多种形式出现——书中举了四个真实例子说明这一点：从SRS目录提炼出”功能框图结构”（CRM系统案例）、从市场彩页里找到现成的功能树（酒店综合管理系统案例）、从方案建议书的系统功能表里提取（汽车生产行业ERP系统案例）、从产品实际的UI主界面和权限设置对话框里反向提炼（设备管理系统案例，两个不同界面呈现出的功能树是一致的，都包含”设备购置”“设备台账”“设备转资”等7个功能组）。这条经验的实用价值在于：架构师不该死板地等待一份”标准格式”的功能树文档才开始工作，而应该主动在各种既有材料（甚至竞品的UI）里识别出功能树的实质内容，无论它以什么形式呈现。