看到本书第十三章发现，需求不应该决定架构，我心想：what？架构不就是要根据用户需求来确定的吗。再往下看，原来是关键需求决定软件架构。
究其原因也很好理解，在实际软件开发中，不是像大学里这种“实验室代码”，软件架构师没有时间对‘所有需求’进行深入分析，这既是策略，也是现实，当然这对于我以后走向社会提供了很大帮助，转化了一种思路。俗话说，事无巨细，但这在软件架构设计阶段并不适用，姑且不论用户的需求经常变化，反复无常，要想兼顾所有的需求那是不可能的，所以确定关键需求至关重要。结合课上所学知识，相互印证，一般可以从功能需求、质量需求和商业需求三方面来进行分类。任何功能需求，都是由一条特定的‘模块协作链’完成的。
一方面，不同质量属性之间往往具有相互制约性，于是我们自然应该权衡哪一部分质量属性是架构设计的重点目标。另一方面，功能需求数量众多，应该控制架构设计时需要详细分析的功能（或用例）的个数。
可通过如下4条启发规则，确定关键功能子集：
- 核心功能
- 必做功能
- 高风险功能
- 独特功能（覆盖了上述3类功能没有设计的职责）
只要能较好地覆盖组成架构的不同职责模块，并体现职责模块之间协作关系的特点，那么“关键功能子集”的价值也就体现出来了。为什么架构师的经验很重要呢，确定“关键需求”靠的就是经验，目的是用有限的时间针对关键需求把设计做到位、并减小需求变更对架构设计的影响。这也就是为什么软件架构师比较难做，做好就更不用说了，你既要有多年的软件开发而经验，也就是心中有“货”，又要当机立乱，不能犹豫，确定出本软件最核心的功能是什么，就像硬盘一样，要求读取速度快，就不能要求磁盘利用率高；要保证充分利用磁盘，节省空间，就无法注重读取速度，所以要学会取舍。