在一个以软件架构为中心的软件项目开发过程中，最常见的开发过程大致分五到六个阶段：概念化阶段、分析阶段、架构阶段、详细设计阶段(一般情况下特别是结合敏捷模式时都会被裁剪掉)、并行开发与测试阶段、验收与交付阶段。
软件架构设计阶段依赖于分析阶段并以软件需求规约为主要输入。那么是不是软件架构工程师必须等到软件需求规约评审通过后才开始工作呢？前面讲到软件架构的策略时讲到全面认识需求与关键需求决定架构。因此，软件架构工程师必然有一个对软件需求进行认识、分析的过程，如果软件架构工程师等到软件需求规约评审通过后才开始工作，必然会延长软件项目的工期。好的项目管理者与优秀的软件架构工程师一定会让这段时间与软件需求人员进行需求分析的阶段重叠缩短软件项目工期。而且一个合作良好的软件项目团队，在进行需求分析过程中必然后邀请软件架构工程师对一些需求问题进行分析验证与对软件需求规约进行评审。因此，软件架构工程师必须在软件需求分析阶段的适当时宜尽早介入，甚至在一些软件过程能力成熟度较低而软件项目重要性较高的软件项目团队，我会酌情把有些软件架构工程师提前到概念化阶段就介入。
因此软件架构设计过程的第一步是全面认识需求。在需求分析与领域建模即分析阶段，软件架构工程师与软件需求人员一起将所有需求从不同的级别(组织级、用户级、开发级)分层梳理列表归纳总结建立跟踪矩阵，并划分为不同的类型(功能需求或用例、质量属性、约束与限制)进行梳理列表归纳总结建立影响分析表，找出不同需求类型之间的相互支持、相互制约关系的影响。
软件架构设计过程的第二步是确定对架构关键的需求。软件架构工程师将所有需求进行筛选，在深思熟虑之后作出合适的需求权衡和取舍，最终确定对软件架构起关键作用的需求子集，控制架构设计时需要详细分析的用例个数，找到影响架构的重点非功能需求。
在此基础上，软件架构设计过程的第三步是进行概念性架构设计。设计概念性架构的第一步是分析关键用例有用例规约，运用鲁棒图等方法构造系统理想化的职责模型(如分层)。接下来明确架构模式(如MVC)，确定交互机制，形成初步的概念性架构。最后通过质量属性分析，制定出满足非功能需求的高层设计决策，并根据这些决策对之前的工作成果进行增强、调整，以保证概念性架构体现这些设计决策。
接下来，软件架构设计过程的第四步是细化软件架构，考虑具体技术的运用，设计出实际架构。概念性架构所关注的关键设计要素、交互机制、高层设计决策与具体技术无关，而最终的软件架构设计方案必须和具体技术结合，为开发人员提供足够的指导和限制。为些，必须从系统如何规划、如何开发、如何运行等角度揭示软件系统的结构和机制。一般分别从逻辑架构、开发架构、运行架构、物理架构、数据架构等不同架构视图进行设计。
最后，软件架构设计过程的第五步，千万别忘了验证软件架构。
