需求是有结构的。

许多实践者不懂这一点，更不知道如何“主动运用”这一点。在他们眼中，架构设计要应对的需求往往是又多又乱的，而且遗漏了关键需求也发现不了......

相反，有经验的架构师懂得运用需求的结构。他们能够将复杂的需求集合梳理得紧紧有条，为进一步分析不同需求之间的联系（作为权衡折中的依据）、识别遗漏的重要需求打下坚实基础。

Pre-architecture阶段要求进行需求结构化，这代表着ADMEMS方法更贴近一线架构设计的真实实践。

通过形象的“物体归类”的隐喻可以嘉盛对需求结构化工作的理解。

那么，需求结构化要怎么做呢？

既然架构师必须“对需求进行理性的、有针对性的权衡、取舍、补充”，那么“作为架构设计驱动力的需求因素”和“供甲方确认的《软件需求规格说明书》”之间就必然不能“划等号”。

所以，架构师要通过需求结构化真正全面的“鸟瞰”需求大局 ，就必须超越《软件需求规格说明书》

还有一个重大意义在于，只有摆脱了对《软件需求规格说明书》的“呆板依赖”，才有可能尽早开始架构设计（参见 3.2.3. 尽早开始架构设计 ）。

矩阵，是很多著名方法的核心。

“ADMEMS矩阵”，也称为“需求层次-需求方面矩阵”。

需求的三个层次，是站在“不同层次的涉众提出需求所站的立场不同的角度 ”，将需求划分为三种类型。

另外，需求还需要从不同的方面进行考虑。

忽视质量属性和约束性需求，常常导致架构师设计最终失败 。

从“需求定义了直接目标还是间接限制”的角度，把需求划分为3中类型，这就是需求的3个方面：

一句话，需求是有结构的 。而且，需求的结构绝不是“List”，而应该是“二维数组 ”。

结构化是控制复杂度的好办法。

进行需求结构化之后，会感觉“需求变少了”--其实，需求并没有变少，但复杂度却得到了控制。

另外，进行结构化之后，最大的好处是，可以比原来更轻易发现遗漏需求。

风险有个烦人的特点：一旦你忘了它，它就会找上门来制造麻烦。

背鳍下面是不是一条鲨鱼？约束性需求中，是不是潜藏了风险因素？

对于架构设计而言，来自方方面面的约束性需求中潜藏着大量风险因素 。

分析约束影响应该怎么做？

我们先看看这些约束来自“哪些涉众”？

4类约束在ADMEMS矩阵中的位置清楚表明：业务环节、使用环境、构建环境应分别考虑客户、用户、开发者3类涉众，而技术环境与上述3类涉众都有关系

只有把握住涉众来源，才便于发现并归纳涵盖广泛的约束因素，也有利于针对性地进行交流，还可跟踪对约束的支持是否令涉众满意。

架构师应当直接或（通过需求分析员）间接的了解和掌握上述需求和约束，并深刻理解它们对架构的影响，只有这样才能设计出合适的软件架构。

另外，还有一个重要的基础问题，太多的架构师对约束的理解都过于零散，影响了系统化思维。

一句话：约束是架构设计的上下文。

没有全局观念就不可能成为架构师，”约束是架构设计要解决的问题的上下文“是一个犀利的理解 ，揭示了”软件需求 = 功能需求 + 质量 + 约束“背后更深层层次的规律。

如果忽视了上下文对架构设计的限制，最终的架构设计就是不合理的，甚至是不可行的。

举个生活中的例子--设计大桥。建筑师必须关注以下4类约束的影响，合理规划大桥的设计方案。

分析约束影响在需求结构化的基础上，充分考虑需求方及业务环节因素，用户群及使用环境因素、开发方及构建环境因素、业界当前技术环境因素等”4类约束“，并分析约束印象、识别约束背后的衍生需求。

从本质上讲，分析约束影响就是分析各个需求项之间的关系，并发现被遗漏的需求。所以将需求”化杂乱为清晰“的正交表可以作为分析约束影响的基础--即在需求项清晰定位的前提下，找到不同需求之间的关系，发现遗漏需求。

ADMEMS矩阵方法应用法则有两个。

像Amazon这样大型的B2C网站，架构的起步阶段应如何规划呢？下面看看ADMEMS方法的“表现”。

通过ADMEMS矩阵（需求层次-需求方面矩阵），有助于高屋建瓴的把握复杂系统的需求大局。

先来梳理一下业务级的需求。

用户级需求，要特别注意挖掘来自“用户及使用环境”的约束，也别忘了开发方的因素。

接下来分析约束影响。

基于ADMEMS矩阵应用推导法则规律十分明显：隐含需求（或遗漏需求）是通过 “从上到下” 或 “从右到左” 的脉络被发现的。考虑到公司的中远期法则（B2C业务从图书扩展到各类商品），以及近期商业策略（投入资金2000万）的限制，必须制定“网站发展路线图”--而这对架构而言属于“开发级约束”。

接下来，我们利用类似的思维来理解不同需求之间的联系，这样你不会再觉得需求是“一盘散沙”了。

另外，还要主动运用查漏法则。例如，我们发现至今对质量的重视还不够（实践一线经常出现此情况），于是开始“查漏”：方方面面的约束背后藏着哪些必须强调的质量属性要求呢？

例如，如此多的质量要求，比如要提高系统的互操作性......

PASS系统的全称是：合理用药监测系统（Presription Automactic Screening System）。通过全面部署PASS系统可以促进医院的用药合理化、规范化、降低医院的医疗事故率，还有利于管理部门高效全面的掌握医疗一线的用药情况，及早发现问题域解决问题。

PASS系统的主要功能:

将“功能列表”等同于“全部需求”根本不是架构师的应有做法。相反，为了全方位、多角度的把握需求，应当重视并运用“需求的结构”。

下面逐一分析约束因素的潜在影响。

首先是业务级需求因素的影响分析。例如，既然药品的种类繁多、用药规则的数量也很大，就应该设法避免每家医院都重复用药规则--于是决定“省级集中提供用药规则的定义和更新支持”（这其实是业务流程一级的一项需求）。