Pre-architecture：准备架构阶段，主要的是弄清楚要做什么东西，即掌握用户需求。应该来说，整个准备阶段都围绕着“需求”来转。
我认为如下过程：需求-->约束-->质量-->关键功能
1.需求：需求不应该仅仅来自市场人员。
需求应该来自哪里？应该是一拨人讨论出来的结果，这拨人就应该包括：市场人员+产品经理+架构师+项目经理。首先一款产品是否需要做，这是市场人员和产品经理所讨论的范畴，他们决定该如何定位此款产品，产品经理根据公司的技术实力，决定能否做。那么，接下来便是了解用户需求，前期的调研工作需要市场人员来做，并形成一个“初步需求列表”。有了“初步需求列表”，架构师和项目经理就应该考虑，并弄清楚每条需求，这里为什么需要项目经理的参与呢，就是为了保证该项目的负责人能够最清晰的明确做什么，接下来才能带领队伍把握关键指标。
架构师在考虑需求的时候，如果只是笼统的来了解每个功能，这样各种需求混在一起就显得比较乱，最好可以参考ADMEMS矩阵法来进行划分：
|
从表中可以看出需求是分为层次的。
业务级需求：包含客户或出资者要达到的业务目标、预期投资、工期要求，以及要符合哪些标准、对哪些遗留系统进行整合等约束条件；
用户级需求：用户使用系统来辅助完成哪些工作？对质量要求如何？用户群及所处的使用环境方面有何特殊要求？
开发级需求：开发人员需要实现什么？开发期间、维护期间有何质量考虑？开发团队的哪些情况会反过来影响架构？
对于此三类需求弄清楚之后，就可以形成一个初步的需求列表。
基本上来说掌握ADMEMS矩阵表，前期的准备工作就算做完了。下面的小节是对其他概念做更加详细的解释。
2.约束：何为“约束”？
约束：制约项目发展的因素。
首先，约束来自与需求又制约需求，比如“用户级需求”中提到了“用户群特点”的约束，就说明，本产品必须要考虑针对哪些用户群来做。
3.质量
质量，类似于“约束”，它更重视某一事物具备的属性。当然，有些时候可以把质量属性来当做约束，比如可移植性，可以把它看做是质量也可以当做一种约束来看。
那么，作为一个架构师该考虑哪些质量属性呢？
1.性能 2. 安全性 3.持续可用性 4.可靠性 5.鲁棒性 6.易用性 7.可测试性 8.可重用性 9.可维护性 10.可扩展性 11.可移植性 12 可互操作性。
有些指标之间是相互影响的。其影响关系如下（+表示促进 －表示影响 空白表示无明显作用）：
| 性能 | 安全性 | 持续可用性 | 可互操作性 | 可靠性 | 鲁棒性 | 易用性 | 可测试性 | 可重用性 | 可维护性 | 可扩展性 | 可移植性 | |
| 性能 | － | － | － | － | － | － | － | － | ||||
| 安全性 | － | － | － | － | － | |||||||
| 持续可用行 | + | + | ||||||||||
| 可互操作性 | － | － | + | + | ||||||||
| 可靠性 | － | + | + | + | + | + | + | |||||
| 鲁棒性 | － | + | + | |||||||||
| 易用性 | － | + | － | |||||||||
| 可测试性 | － | + | + | + | + | |||||||
| 可重用性 | － | － | + | + | + | + | + | |||||
| 可维护性 | － | + | + | + | ||||||||
| 可扩展性 | － | － | + | + | + | |||||||
| 可移植性 | － | + | + | + | － | + |
架构师应该确定关键质量的优先级。并在《架构文档》中明确记录此要求。
4.关键功能
关键功能包含如下四个方面：1.核心功能；2.必做功能；3.高风险功能；4.独特功能。
如何区别这四个方面，实际上是靠经验和感觉。它们之间实际上是有重叠部分的。
核心功能：业务层接口所反映的功能。如，项目管理系统中，项目信息查看、添加任务等都属于核心功能；
必做功能：必做功能实际上是以客户为背景的，简单来说就是愿景；
高风险功能：顾名思义，哪些功能操作可能会涉及到安全和隐私等问题；
独特功能：实际是上诉上个功能的补集，看看还有哪些没有覆盖到的，却又很关键的功能。
架构师在设计阶段要考虑到“关键功能”所占有的比例，没有明确的标准，一般遵循：功能少的系统比例高一些，功能多的系统比例少一些。
总结
总得来说，准备阶段要做的最重要的一件事，就是弄懂需求。