13.3.1  对架构关键的需求vs.需求优先级

在软件过程上游的需求分析活动中，我们有必要识别并记录需求的优先级，这对项目管理乃至控制交付范围等都有重要影响。那么，项目经理所关心的需求优先级和软件架构师所关心的对架构关键的需求之间，到底是什么关系呢？

一“图”以蔽之。如图13-2所示，高优先级的需求和对软件架构关键的需求之间，既有区别又有联系。

一个事物是否关键、是否优先考虑，要视具体目标不同而定。我们通常所说的“需求优先级”是针对客户而言的（同时要从技术角度考虑需求之间的依赖关系），而本章的主题“对软件架构关键的需求”是对架构设计的影响而言的，请读者注意区分。

需求优先级主要是针对功能需求而言的，除却被依赖的需求应当优先实现之外，需求优先级主要反映了客户希望最终系统提供某功能需求的迫切程度。一般而言，需求优先级可以分为三级：

Ÿ   高优先级。必不可少的功能。只有在这些需求上达成一致意见，软件才可能被接受。这些功能的实现质量必须趋于完美；

Ÿ   中优先级。必要的功能。这些功能是系统所需要的，如果有必要可以延迟实现。虽然不提供这些功能系统也有可能被接受，但最好不要忽略它们。值得为这些功能的质量付出努力；

Ÿ   低优先级。锦上添花式的功能增强。低优先级的需求可以实现也可以不实现；但如果资源允许的话，实现这些需求将会使产品更臻完美。另外，对于这些需求的实现质量要求不是很高，甚至可以容忍不严重的缺陷存在。

鉴于此，我们也就不难理解，一个项目中，需求优先级为高、中、低的需求的比例应该科学（比如3^:4^:3），从而有利于项目管理。如果将需求优先级统统定为高，或者需求优先级为高的需求明显占了压倒性的比例，这显然是不科学的做法，违背了设定需求优先级的初衷，不利于项目管理中权衡与调整。鉴于项目管理不是本书的主题，对此我们不再展开讨论。

总之，可以这么说，需求优先级是项目经理的一种权衡和决策的工具（如图13-3所示）。该工具使项目经理可以在一定程度上获得对项目管理的灵活调整的余地，为了在项目的时间、成本和质量要求范围内顺利完成目标，对项目所提供的功能范围（Scope）进行调整。

13.3.2  关键需求对后续活动的影响

确定了对架构关键的需求之后，软件架构师下面的活动将主要针对这些关键需求展开（如图13-4所示）：

Ÿ   无论对于概念性架构的设计（第14章），还是实际架构的设计（第16章），都需要对关键用例进行分析。此时将采用鲁棒图等用例分析技术，最终将各鲁棒图进行综合，得到整体的软件系统职责划分模型（也被称为逻辑设计模型或分析模型）；

Ÿ   质量属性分析中，采用“质量属性—场景—决策”表等技术手段，分析质量属性要求，制定架构级设计决策；

Ÿ   当然，经过质量属性分析之后得到的架构决策，可能引起软件系统职责划分模型的调整。以高性能设计为例，无论是“对消息采用多线程并发处理”还是“将图片服务器独立出来以便进行专门的缓存和索引等加速处理”都需要对软件系统职责划分模型进行细化等调整。