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

Posted 2023-02-16 文火冰糖的硅基工坊

第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 “拿来主义”虽好，但要合适才行

备注：

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

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