用例驱动论的局限：用例涉及但不能全面涵盖非功能需求

“架构设计是用例驱动的”这种观点（简称用例驱动论）看似合理，实则有严重缺陷，三句话足以揭示：需求=功能+质量+约束；用例是功能需求实际上的标准；用例涉及、但不能全面涵盖非功能需求。这条判断容易招致反驳——有学员就提出”用例分析中描述非功能需求的方面不能全面涵盖，不是用例技术本身的问题，而是架构师主观因素决定的”，并援引ADMEMS矩阵能更全面覆盖非功能需求作为佐证。对此可以给出四点具体反驳。一，RUP自己在用例模型之外还专门搞了一份《补充规约》，正是因为要把用例没盖住的非功能需求放进去——如果用例真能完全涵盖，这份补充文档就是多余的。二，约束需求非常广泛，用例不可能包住，比如预算、工期、技术专利这类约束根本不适合塞进某个用例。三，系统具有整体性，很多质量属性不可能都映射到一个个具体功能上，比如性能中的吞吐量、并发数是系统整体层面的指标，无法归属于某个单一用例。四，用例是”面向用户”的表达方式，而很多非功能需求根本不是面向用户的，比如可修改性（开发者关心的后台算法便于修改、SDK方便替换厂商）、内存某个bit坏了这类底层考量，都不适合、也不应该出现在用例描述里。这四点共同说明：用例技术本身很好，但”用例足以驱动整个架构设计”是被过度夸大的说法，把用例当成唯一的需求分析入口，会系统性地遗漏一整类真正影响架构的需求。