关键功能子集没有标准答案，比例不能一刀切

应用[[确定关键功能的四条启发规则]]确定出的”关键功能子集”，架构师容易陷入两个误区，需要专门澄清。第一个误区是期待”标准答案”：曾有学员问能不能做到”关键功能子集保证覆盖了所有职责模块”，答案是不能——原因有二，一是覆盖情况只能在系统基本开发完毕之后才能做”事后证明”，”事前证明”根本不可能；二是架构师经验之所以重要，正体现在确定”关键需求”这件事本身就是靠经验判断的，目的是用有限时间把设计做到位、并减小需求变更对架构设计的影响，而不是追求一个可以被形式化验证的最优覆盖率。只要关键功能子集能较好地覆盖组成架构的不同职责模块、并体现职责模块之间协作关系的特点（有经验的架构师尤其不会放过后者），它的价值就已经体现了。第二个误区是相信”关键功能所占比例”存在固定标准：一些专家（如Kroll和Kruchten在《Rational统一过程：实践者指南》中）建议”大概占总数的20%至30%“，但这个比例不可能一刀切——如果为一个只有5个功能的系统做架构设计（这类系统在计算、通信、数据访问方面可能有很高复杂性，但功能数量确实不多），套用20%的比例意味着关键功能只有一个，这显然不合适。正确的做法是灵活确定：功能数量少的系统，关键功能占比应该高一些；功能数量多的系统，关键功能占比可以低一些——比例本身不是目的，能否真正覆盖架构的关键职责和协作关系才是判断标准。