基于架构的软件设计（Architecture-Based Software Design， ABSD）是一种架构驱动方法。 这种方法有 3 个基础：
（1）功能的分解。在功能分解中， ABSD 方法使用已有的基于模块的内聚和耦合技术。
（2）通过选择架构风格来实现质量和业务需求。
（3）软件模板的使用。软件模板利用了一些软件系统的结构。
ABSD 方法的输入由下列部分组成：
（1）抽象功能需求，包括变化的需求和通用的需求；
（2）用例（实际功能需求）；
（3）抽象的质量和业务需求；
（4）质量因素（实际质量和业务需求）；
（5）架构选项；
（6）约束。
架构需求
需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。需求过程主要是获取用户需求，标识系统中所要用到的构件。
需求获取
架构需求一般来自三个方面，分别是系统的质量目标、系统的业务目标和系统开发人员的业务目标。
标识构件
在图 6-10 中虚框部分属于标识构件过程，该过程为系统生成初始逻辑结构，包含大致的构件。
需求评审 组织一个由不同代表（如分析人员、客户、设计人员、测试人员）组成的小组，对架构需求及相关构件进行仔细的审查。审查的主要内容包括所获取的需求是否真实反映了用户的要求，类的分组是否合理，构件合并是否合理等。
架构设计
架构需求用来激发和调整设计决策，不同的视图被用来表达与质量目标有关的信息。架构设计是一个迭代过程。
架构文档化
文档是在系统演化的每一个阶段，系统设计与开发人员的通信媒介，是为验证架构设计和提炼或修改这些设计（必要时）所执行预先分析的基础。
架构文档化过程的主要输出结果是架构需求规格说明和测试架构需求的质量设计说明书这两个文档。生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。
架构复审
架构设计、文档化和复审是一个迭代过程。从这个方面来说，在一个主版本的软件架构分析之后，要安排一次由外部人员（用户代表和领域专家）参加的复审。
复审的目的是标识潜在的风险，以及早发现架构设计中的缺陷和错误，包括架构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求 。
架构实现
所谓“实现”就是要用实体来显示出一个软件架构，即要符合架构所描述的结构性设计决策，分割成规定的构件，按规定方式互相交互。
虚框部分是架构的实现过程。整个实现过程是以复审后的文档化的架构说 明书为基础的，每个构件必须满足软件架构中说明的对其他构件的责任。
架构演化
在构件开发过程中，最终用户的需求可能还有变动。在软件开发完毕，正常运行后，由一个单位移植到另一个单位，需求也会发生变化。
