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


备注:
不同的目标系统,关键性需求是不相同的。
需要根据自身的需求,重新定制化自己的关键性需求,而不是一味地拿来主义。