품질 기반: 고전적인 소프트웨어 설계 접근 방식(예: Jackson 구조프로그래밍)은 필요한 기능과 시스템을 통한 데이터 흐름에 의해 주도되었지만 현재의 통찰력[4]:26:28은 소프트웨어 시스템의 아키텍처가 더 중요하다는 것입니다. 내결함성, 이전 버전과의 호환성, 확장성, 안정성, 유지 관리 가능성, 가용성, 보안, 유용성 및 기타 –ilities와 같은 품질 특성과 밀접한 관련이 있습니다. 이해 관계자의 관심사는 종종 이러한 품질 특성에 대한 요구 사항으로 변환되며, 이 요구 사항은 다양한 비기능적 요구 사항, 추가 기능 요구 사항, 동작 요구 사항 또는 품질 특성 요구 사항이라고 합니다. 소프트웨어 아키텍처 설명에는 아키텍처 설명 언어, 아키텍처 관점 및 아키텍처 프레임워크와 같은 메커니즘을 사용하여 아키텍처를 모델링하고 표현하는 원칙과 관행이 포함됩니다. 분석 활동의 출력은 아키텍처적으로 중요한 요구 사항이라고 하는 소프트웨어 시스템의 아키텍처에 측정 가능한 영향을 주는 요구 사항입니다. [27] 전통적인 건축 건축에 이어 `소프트웨어 건축 스타일`은 주목할 만한 특징을 특징으로 하는 구체적인 건축 방법이다. 다양한 조직에서 시스템 아키텍처를 다음과 같은 다양한 방식으로 정의할 수 있습니다. [1] 실제로 건축가는 소프트웨어 건축(건축 설계)과 상세 설계(비건축 설계) 사이의 선을 긋는 건축가이다. 구별을 공식화하려는 시도가 있었지만 모든 경우에 맞는 규칙이나 지침은 없습니다. [41] 건축과 세부 설계의 구별은 지역규기준에 의해 정의되며,[41] 소프트웨어 설계에 대한 진술이 비로컬(건축)인 경우만 을 리츠를 리츠는 그렇지 않은 프로그램으로 확장할 수 있습니다. 예를 들어, 이 원칙에 따라 구축된 프로그램은 피어 투 피어 노드를 추가하여 클라이언트-서버가 아닌 프로그램으로 확장할 수 있기 때문에 클라이언트-서버 스타일은 아키텍처(전략적)입니다. 대규모 엔터프라이즈 규모 시스템이 어떻게 설계되는지 궁금한 적이 있습니까? 주요 소프트웨어 개발을 시작하기 전에 원하는 기능과 품질 특성을 제공하는 적합한 아키텍처를 선택해야 합니다.

따라서 디자인에 적용하기 전에 다양한 아키텍처를 이해해야 합니다. 시스템 엔지니어는 기존 시스템 요소를 자주 활용합니다. 이러한 재사용 제약 조건은 시스템 요구 사항으로 식별되어야 하며 아키텍처 및 설계 중에 신중하게 고려해야 합니다. 표 2와 같이 시스템 요소 재사용과 관련된 세 가지 일반적인 사례를 구분할 수 있습니다. 시스템 아키텍처 프로세스의 목적은 시스템 아키텍처 대안을 생성하고, 이해 관계자의 관심사를 구성하고 시스템 요구 사항을 충족하는 하나 이상의 대안을 선택하고, 일관된 뷰 집합에서 이를 표현하는 것입니다. (ISO 2015). 예를 들어 5가지 산업 용 소프트웨어 아키텍처 방법을 연구한 결과 "입력(목표, 제약 조건 등)은 일반적으로 요구 사항 엔지니어링과 소프트웨어 아키텍처 간에 상당한 중복이 있습니다. 아키텍처가 등장하기 시작하면서 발견되거나 더 잘 이해될 뿐"이라며 "대부분의 아키텍처 문제는 시스템의 요구 사항으로 표현되지만, 또한 필수 설계 결정을 포함할 수 있다"고 말했다. [24] 즉, 특정 문제를 고려하여 필요한 동작을 선택하는 것은 해당 문제를 해결하는 솔루션의 아키텍처에 영향을 주는 동시에 아키텍처 디자인이 문제에 영향을 미치고 새로운 요구 사항을 도입할 수 있습니다. [43] 트윈 픽스 모델[44]과 같은 접근 방식은 요구 사항과 아키텍처 간의 시너지 관계를 활용하는 것을 목표로 합니다.