第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 “拿来主义”虽好，但要合适才行
备注：
不同的目标系统，关键性需求是不相同的。
需要根据自身的需求，重新定制化自己的关键性需求，而不是一味地拿来主义。
