[架构之路-98]：《软件架构设计：程序员向架构师转型必备》-8-确定关键性需求与决定系统架构的因素 =》架构的雏形或架构的原型

第8章 确定关键性需求

是什么决定了软件系统的架构？！

没有大的争议的是：需求决定了软件系统的架构！

需求有功能性需求、质量需求和约束条件，那么什么样的需求对软件系统的架构影响最大？

并非所有的需求都对架构都有影响！！！

8.1 众说纷纭——什么决定了架构

需求的三方面：

• 功能性需求=》用例

• 非功能性需求：质量需求

• 非功能需求：约束条件

类比：就想买房，并非有所对家的需求对影响房型的选择，只有一些关键需求会影响房型架构，比如家里几口人，对书房或厨房的诉求、对舒适性的需求、以及手头资金这个约束条件！！！

8.1.1 用例驱动论：功能性需求

用例用图形的方式展现了：站在系统之外，软件系统提供的所有的功能性需求。

因为需求决定架构，因此，有相当多的人认为，用例决定了软件系统的架构。

8.1.2 质量决定论：非功能性需求

作者的观点：没有功能性需求，非功能性需求何以立足？

8.1.3 经验决定论

8.2 真知灼见——关键需求决定架构

关键性需求包括:

• 关键性功能性需求

• 关键性非功能性需求

• 关键性约束条件

需求的三个方面缺一不少！！！

8.2.1 “目标错误”比“遗漏需求”更糟糕

错误：方向性错、目标性错误、核心问题的错误

遗漏：遗漏部分需求。

在众多需求中，把握住关键性需求，是叫架构师的关键技能，是架构师在架构之前首先要解决的问题。

一旦关键性需求把握错误，就是方向性选择的错误，这个错误导致的返工的代价是非常大的！！！

错误的质量目标会导致错误的架构设计。

为了克服这个问题，需要采用新的方法来确定软件的架构。

8.2.2 关键需求决定架构，其余需求验证架构

把握住了关键需求，构建系统架构，然后在用其他需求验证，根据关键性需求构建的架构是否能够同时兼容其他非关键性需求，并根据非关键性需求对架构进行优化和改进。

备注：

根据关键性需求构建的架构是架构框架、是基础架构，但并不是理想架构。

并不存在理想架构，它能够满足大多数需求而已。

架构设计要同时考虑：

• 关键性功能性需求

• 关键性质量需求

• 关键性约束条件

关键性需求的特征：

• 风险大

• 性能要求高

• 核心需求

8.3 付诸行动——如何确定关键需求

对于前者：在不同质量目标中取得平衡，正是因为质量目标有一定的制衡性和矛盾，因此选择某一个质量性需求作为主需求，作为关键性需求，则其他与之制衡的非关键性需求就沦为非关键性需求，就会降低他们的影响力，甚至要牺牲哪些非关键性质量需求！！！

对于后者：选择核心的需求、关键性的需求。

8.3.1 确定关键质量要求

备注：

+表示这两个质量属性是正相关的，强化一个属性，这同时强化另一个属性，反之亦然。

-表示这两个质量属性是负相关的，强化一个属性，则会弱化另一个属性，反之亦然。

8.3.2 确定关键功能要求

8.3.3 确定关键约束条件

每个用例都有自己的约束条件，关键需求的约束条件，就是关键性约束条件。

8.4 实际应用（6）——小系统与大系统的架构分水岭

8.4.1 架构师的“拿来主义”困惑

8.4.2 场景1：小型PMIS（项目型ISV背景）

8.4.3 场景2：大型PM Suite（产品型ISV背景）

8.4.4 场景3：多个自主产品组成的方案（例如IBM）

8.4.5 “拿来主义”虽好，但要合适才行

备注：

不同的目标系统，关键性需求是不相同的。

需要根据自身的需求，重新定制化自己的关键性需求，而不是一味地拿来主义。