3.3. 业界现状

既然Pre-architecture阶段如此重要，业界现状如何呢？

很遗憾，业界对Pre-architecture阶段普遍不够重视。相反“架构设计唯靠经验”、“架构设计目标不变”等错误观点比较常见。

我们头脑中的“位置”是有限的，如果错误的认知占据了主导位置会导致实践偏差，必须防止。

3.3.1. “唯经验论”

和“架构师不必懂需求”的误解相比，“唯经验论”已经有所进步了。这种观点认为，架构师纯粹凭借经验，发现需求的遗漏、权衡需求之间的矛盾、确定架构设计的重点目标。

必须承认，经验对架构设计很重要，但“唯经验论”依然是错误的。

因此，世界上并不存在两个完全相同的想，不同的项目在功能需求、质量属性，以及约束这3方面必然存在差异。

于是，架构师不仅应具有一定经验，还必须掌握超越具体项目的、更具有意义的方法和技能。

架构设计的目标不是一成不变的，基于此认识，ADMEMS方法在Pre-architecture阶段的“确定关键质量”环境提供了专门的指导。

“架构设计目标不变论”是错误的。

例如，有人认为：

我们必须牢记架构设计的总体目标，可概况为以下几点。

最大化的重用......

尽可能的简单明了......

最灵活的扩展性......

首先，若架构设计的目标真能概括为不变的“几点”，那可算是架构师的福音了。

但实际上，架构设计的目标必然会随着领域不同（如航天航空、电信、电子政务）、规模不同（如项目、产品、平台）、条件不同（如工期、预算、标准）而变化。

其次，为重用、简单、可扩展都加了“最”（而不是权衡折中），不符合架构设计的现实，更何况“灵活”和“简单”之间常常存在矛盾。

软件行业处在不断发展变化中，软件需求分类法就是一例。当前，业界影响最为广泛的需求分类法将需求分为3个层次。

图片来源：《软件需求》

这种需求分类法的最大好处是明确了不同层次之间的跟踪关系--业务需求->用户需求->功能需求。从而建立了需求分析的主要脉络，非常有意义。

但是对以架构师来说，这种需求分类法中的“约束条件”太过狭义了，没有反应“架构设计必须面对来自业务环节、使用环境、构建环境、技术环境的4大类约束”这一现实情况。

再例如，RUP提倡的需求分类法也包含3个层次：需要（Need）、特性（Feature）、软件需求。

这类分类法也是主要为需求分析工作服务的，它除了非常倚重用例技术之外，还有一个明显特点--Feature。

以特性（Feature）技术作为从需要（Need）想软件需求过过渡的跳板，是解决需求分析中“从需求想软件需求跨度过大”问题不错的选择，这一点已经受到很多实践者的认同。

但是，这个方法中用例的地位过分突出了，又由于“用例涉及但不涵盖非功能需求”的性质，不少实践者遗漏非功能需求的常见问题也就不难解释了。

最后，顺便指明上述两种“需求层次论”的对应关系，此问题令不少实践者困惑。

不懂不同需求分布如何影响架构，就难以进行理性的架构设计，难免“拍脑袋”决策，关于需求决定架构原理，业界当前的认知状况如下：