关键需求决定架构。关键需求横跨功能需求、质量属性，以及约束这三类需求。
其余需求用来验证架构。
1、确定关键质量
需要做如下三方面工作：
- 为了提高要开发软件系统受认可的程度，应着重提高哪些方面的质量属性要求。
- 充分考虑这些质量属性的相互制约或相互促进关系，以调整不同质量属性的要求标准。
- 同时，必须满足各种约束性需求。
确定关键质量时考虑质量属性之间的矛盾关系。采用质量属性关系矩阵（“+”表示行促进列，“-”表示行影响列，“ ”表示行列两种质量属性之间影响不明显。）
|
性能 |
安全性 |
持续可用性 |
可互操作性 |
可靠性 |
鲁棒性 |
易用性 |
可测试性 |
可重用性 |
可维护性 |
可扩展性 |
可移植性 |
||
|
性能 |
– |
– |
– |
– |
– |
– |
– |
– |
区域1 |
||||
|
安全性 |
– |
– |
– |
– |
– |
||||||||
|
持续可用性 |
+ |
+ |
区域2 |
||||||||||
|
可互操作性 |
– |
– |
+ |
+ |
|||||||||
|
可靠性 |
– |
+ |
+ |
+ |
+ |
+ |
+ |
||||||
|
鲁棒性 |
– |
+ |
+ |
+ |
|||||||||
|
易用性 |
– |
+ |
– |
||||||||||
|
可测试性 |
– |
+ |
+ |
+ |
+ |
+ |
区域3 |
||||||
|
可重用性 |
– |
– |
– |
+ |
+ |
+ |
+ |
||||||
|
可维护性 |
– |
+ |
+ |
||||||||||
|
可扩展性 |
– |
– |
+ |
+ |
+ |
||||||||
|
可移植性 |
– |
– |
+ |
+ |
– |
+ |
2、确定关键功能
- 核心功能：标志是业务层的接口要反映这些功能。
- 必做功能：《愿景与范围文档》中的“主要特征”往往应作为“必做功能”的备选项。对于业务系统来说，一般支持“运营”的功能比支持“管理”的功能优先级要高。
- 高风险功能：基于务实考虑。
- 独特功能：