上节说到，做任何事情都可以分为三个阶段：准备做、做、做好。本文，就将进入第一个阶段，准备做阶段。

Pre-Architecture：准备架构

　　准备架构阶段，最最重要的是弄清楚要做什么东西，即掌握用户需求。应该来说，整个准备阶段都围绕着“需求”来转。

　　我将它描述为如下过程：需求-->约束-->质量-->关键功能

　　初学者根据上诉步骤，一步一步来，就能够完成准备架构阶段。

1.需求

　　可能有人会认为“需求应该来自市场人员”，这句话并不全面，需求不应该仅仅来自市场人员。

　　记得本人接手的第一个项目时，市场人员告诉研发部门需要研发出一款产品，研发部门会成立一个项目小组，然后再指定一个研发人员做需求调研，写需求列表，这个做法现在觉得是非常不合理的。首先，研发人员没有市场经验，更不懂用户想要什么产品，就只能够照着别的公司的产品抄，最终肯定是抄个四不像。

　　下面回到话题，需求应该来自哪里？应该是一拨人讨论出来的结果，这拨人就应该包括：市场人员+产品经理+架构师+项目经理。首先一款产品是否需要做，这是市场人员和产品经理所讨论的范畴，他们决定该如何定位此款产品，产品经理根据公司的技术实力，决定能否做。那么，接下来便是了解用户需求，前期的调研工作需要市场人员来做，并形成一个“初步需求列表”。有了“初步需求列表”，架构师和项目经理就应该考虑，并弄清楚每条需求，这里为什么需要项目经理的参与呢，就是为了保证该项目的负责人能够最清晰的明确做什么，接下来才能带领队伍把握关键指标。

　　架构师在考虑需求的时候，如果只是笼统的来了解每个功能，这样各种需求混在一起就显得比较乱，最好可以参考ADMEMS矩阵法来进行划分：

从表中可以看出需求是分为层次的。

业务级需求：包含客户或出资者要达到的业务目标、预期投资、工期要求，以及要符合哪些标准、对哪些遗留系统进行整合等约束条件；

用户级需求：用户使用系统来辅助完成哪些工作？对质量要求如何？用户群及所处的使用环境方面有何特殊要求？

开发级需求：开发人员需要实现什么？开发期间、维护期间有何质量考虑？开发团队的哪些情况会反过来影响架构？

　　对于此三类需求弄清楚之后，就可以形成一个初步的需求列表。

　　基本上来说掌握ADMEMS矩阵表，前期的准备工作就算做完了。下面的小节是对其他概念做更加详细的解释。

2.约束

　　前面说了，整个阶段都是围绕“需求”来转，接下来的“约束”、“质量”都是对需求做限制的。那么何为“约束”？

　　约束：制约项目发展的因素。

　　首先，约束来自与需求又制约需求，比如“用户级需求”中提到了“用户群特点”的约束，就说明，本产品必须要考虑针对哪些用户群来做，要做一个儿童教育软件，就不应涉及成人的复杂理论和逻辑。这就是约束！

3.质量

　　质量，类似于“约束”，它更重视某一事物具备的属性。当然，有些时候可以把质量属性来当做约束，比如可移植性，可以把它看做是质量也可以当做一种约束来看。

　　那么，作为一个架构师该考虑哪些质量属性呢？

　　1.性能  2. 安全性 3.持续可用性 4.可靠性 5.鲁棒性 6.易用性 7.可测试性 8.可重用性 9.可维护性 10.可扩展性 11.可移植性 12 可互操作性。

　　也不是说用户要把每一个指标都做上去。有些指标之间是相互影响的。其影响关系如下（+表示促进  －表示影响  空白表示无明显作用）：

　　架构师应该确定关键质量的优先级。并在《架构文档》中明确记录此要求。

4.关键功能

　　关键功能包含如下四个方面：1.核心功能；2.必做功能；3.高风险功能；4.独特功能。

　　如何区别这四个方面，实际上是靠经验和感觉。它们之间实际上是有重叠部分的。

核心功能：业务层接口所反映的功能。如，项目管理系统中，项目信息查看、添加任务等都属于核心功能；

必做功能：必做功能实际上是以客户为背景的，简单来说就是愿景；

高风险功能：顾名思义，哪些功能操作可能会涉及到安全和隐私等问题；

独特功能：实际是上诉上个功能的补集，看看还有哪些没有覆盖到的，却又很关键的功能。

　　架构师在设计阶段要考虑到“关键功能”所占有的比例，没有明确的标准，一般遵循：功能少的系统比例高一些，功能多的系统比例少一些。

总结

　　总得来说，准备阶段要做的最重要的一件事，就是弄懂需求，不管通过何种方式剖析和理解，只要弄懂架构的需求就算完事了！