1.  确定对架构关键的需求  这不仅要求对功能需求（如用例）进行筛选，还要对非功能需求进行综合权衡，最终确定对软件架构起关键作用的需求子集。也就是说，必须致力于“缩小范围”，这样就掌握了主动权，可以充分利用有限的时间把架构分析和架构设计工作做“深”，而不是碌碌无为地在多得数不清的需求之间徘徊。
2. 概念性架构设计  设计概念性架构的第一步是分析关键用例的用例规约，运用鲁棒图构造系统理想化的职责模型。接下来，明确架构模式，确定交互机制，形成初步的概念性架构。最后，还要通过质量属性分析，制定出满足非功能性需求的高层设计决策，并根据这些设计决策对此前的工作成果进行增强、调整，以保证概念性架构体现这些设计决策。在接下来，考虑具体技术的运用，设计出实际架构。
3. 细化软件架构   此前的概念性架构所关注的关键设计要素、交互机制、高层设计决策多与具体技术无关，而最终的软件架构设计方案必须和具体技术结合，为开发人员提供足够的指导和限制。为此，我们必须从系统如何规划、如何开发、如何运行等角度揭示软件系统的结构和机制。一般而言，可以分别从逻辑架构、开发架构、运行架构、物理架构、数据架构等不同架构视图进行设计。
4. 验证软件架构  对后续工作产生重大影响返工价很高的任何工作都应该进行验证，软件需求如此，架构设计方案也是如此。至于验证架构的手段，对软件项目而言，往往需要开发出架构原型，并对原型进行测试和评审来达到；而对软件产品而言，可以开发一个框架（Framework）来贯彻架构设计方案，再通过在框架之上开发特定的垂直原型来验证特定的功能或质量属性。因此，从架构验证工作得到的不应该仅仅是“软件架构是否有效”的回答，还必须有可实际运行的程序：体现软件架构的垂直抛弃原型或垂直演进原型，或者是更利于重用的框架。这些成果为后续的开发提供了实在的支持。

                                                         摘自 《软件架构设计》