图13-6展示了确定对软件架构关键需求的步骤，下面我们将一一讨论。

13.5.1  全面整理需求

软件架构师为了确定关键需求，他需要全面整理需求，从而对需求建立通盘认识。为此，软件架构师可能需要：

Ÿ   研究《愿景和范围文档》

Ÿ   研究《软件需求规格说明书》

Ÿ   参加需求讨论会

Ÿ   询问客户、用户、领域专家、系统分析员

大多数情况下需求文档未必有软件架构师需要的所有信息，例如易扩展性、易测试性等开发期质量属性往往是《软件需求规格说明书》相对薄弱的环节，所以软件架构师必须通过通盘理解需求，将缺失的、隐含的需求找出来。

如果条件允许，软件架构师应该多参与需求活动，这样更有利于把握需求的轻重缓急。

13.5.2  分析约束性需求

对约束性需求进行分析非常有必要，因为很多约束之中“藏”着一些隐含的需求，我们必须将它们找出来。

总体而言，约束性需求可能通过三种途径影响设计（如图13-7所示）。

Ÿ   直接制约设计决策。例如，“系统运行于Linux平台之上”作为一条约束，架构师直接遵守即可；

Ÿ   转化为功能需求。例如，“本银行系统必须严格执行人行统一规定的利率”是一条约束，但分析后发现，正是它引出了一条功能需求：即必须提供调整利率设置的实用功能；

Ÿ   转化为质量属性需求。例如，有经验的系统分析员发现了一条重要约束：要开发的软件系统的预期用户计算机水平普遍不高。由此，未来的软件系统必须具有很高的易用性（否则不会用）和鲁棒性（否则可能把系统搞瘫痪了）就是非常必要的啦。

13.5.3  确定关键功能需求

如何确定关键功能需求？

对此，Per Kroll和Philippe Kruchten在《Rational统一过程实践者指南》中所论述的相当令人信服（或许读者需要一点RUP知识基础）：

在初始阶段，应该确定出一些（大概占总数的20%至30%）对系统起关键作用的用例。这些用例通常对创建架构具有重要影响。

A. 作为应用程序的核心或实现了系统的主要接口的功能，因此，对系统架构有很重要的影响。通常系统架构师通过分析冗余的管理策略、资源互斥风险、性能风险和数据安全风险等来识别出哪些用例是最重要的。例如，在销售系统中，从信用卡划账和支付是最主要的用例，因为它是与信用卡确认系统的接口，它的负载和性能特性也很重要。

B．必须被实现的功能。这些功能反映了系统的本质，如果这些功能不能实现，那么开发出的应用程序就没有价值了。通常领域专家和相关方面的专家知道用户最需要哪些功能（主要行为、数据处理的峰值和关键的控制操作等）。比如，如果没有接受订单的功能，就不能实现一个订单发布系统。

C. 覆盖了系统架构的一些方面，但没有被其他重要的用例覆盖到的功能。要确保解决所有主要技术风险，就必须全面了解系统的每个方面。否则，即使架构中的某个方面看起来没有重大风险，但是在设计、实现和测试时就很有可能发现这个部分中潜伏着巨大的技术风险。

    读者还要识别用户需求中的一些难于实现的、未知的或者存在风险的元素（也许包括一些非功能性的元素），并且要找到一些用例（或者用例的一部分）来说明当前遇到的困难以及解决方案的风险。在这个过程中，通常会有一些技术性风险转移到系统架构的基础部分中。例如，如果系统对时间响应特性或负载特性有特殊的要求，就要识别出一个用例（或者用例的一个事件流）来说明这个需求，同时还要表现出对特性的要求。还有其他一些例子，比如错误恢复策略和系统初始化策略等。

    最后，还要识别出这样的一些用例：它们既不会对系统架构产生重要影响也没有技术风险，但是它们描述了尚未涉及到的系统功能。这样，在细化阶段结束时，才能创建出体现系统要领的整体架构。例如，要确保每个主要的“业务实体”都至少与一个核心用例交互。

13.5.4  确定关键质量属性需求

为了确定对架构设计关键的质量属性需求，需要做如下三方面的工作：

Ÿ   考虑为了提高要开发的软件系统受认可的程度，应着重提高哪些方面的质量属性要求；

Ÿ   接下来，充分考虑这些质量属性的相互制约或相互促进关系，以调整不同质量属性的要求标准——例如，你可能会决定高性能要求最最重要，而可扩展性也比较重要；

Ÿ   同时，必须满足各种约束性需求。