Software Requirements 는 소프트웨어가 만족 해야 하는 요구 사항으로, 우리 시스템의 목적이 된다. 이러한 요구사항은 다양한 이해당사자들로 부터 수집된다. 수집하여 정제하고 이를 문서화 하고 각각 중요도와 난이도를 설정하여 무엇에 집중해야 할지 선정해야 한다.
1. System 요구사항
여기서 선정된 중요한 요구 사항이 바로 설계의 목적인 Architecture Driver 가 된다. 그런데, 소프트웨어는 기본적으로 System의 일부이다. 제품의 전체 시스템이 있고, 소프트웨어는 그 시스템의 구성 요소의 일부이다.
따라서, 고객 즉 우리 시스템을 사용하는 사람의 입장에서, 시스템에 대한 요구 사항이 있고, 시스템 안에서 각 구성 요소간 협업을 통해 요구 사항을 달성한다.
즉, 시스템에 대한 요구 사항을 달성하는 것이 우리의 주 목적이고, 이 요구 사항을 달성하기 위해 Software에게 일부 역할이 주어진다. 따라서 일부 시스템의 경우, HW/SW 간 Partitioning 작업이 중요하다. 즉, 요구사항을 달성하는데 있어 시스템의 구성요소인 Hardware의 책임과, Software의 책임을 구분 짓고, 유기적으로 서로 상호 동작 하도록 해야 한다.
Software 내부적으론, Software에게 부여된 책임을 달성하기 위해, 구성 요소 들간의 관계를 정의해야 한다.
일반적인 기능들은 굳이 Architecture를 고민할 필요 없이 그냥 구현하면 된다. 그러나 품질 측면에서 더 좋은 Software를 개발하기 위해선, Architecture 설계가 필요하다.
2. Software Requirements 의 분류
일반적으로 Software Requirements 를 기능 요구사항과 비기능 요구사항으로 구분짓는다. 그러나, 비기능 요구사항을 자세히 들여다보면 다시 기능과 비기능으로 나눠짐을 알 수 있다. 비기능 요구사항으로 도출된 요구사항들을 다시 살펴보면, 기능과 그 안에 비기능으로 다시 Break down할 수 있다.
그냥 동작하는 Software는 Function하나로 충분히 구현 가능하다. OOAD를 통해 이를 설계하고 요구사항을 달성 할 수 있다. 그러나, 유지 보수성과 Next Generation의 재사용성을 고려해야 한다면, Function을 책임 단위로 나누고, OCP(Open-Close Priciple)을 고려하여 설계 후 구현해야 한다. 이를 위해 Software Architecture 과정을 통해 달성한다.
3. 요구사항 정제
보통 고객은 기능만 요구하지 않는다. 응답성과 유지 보수성 확장성과 같은 품질에 대하여 요구한다. 고객이 요구하는 요구사항들을 문제로 정의하는 것이 설계의 시작이다. 따라서 소프트웨어 요구사항분석 과정을 통해, 고객들이 원하는 요구사항 중 달성하기 어려운 품질 요구사항이 무엇인지, 정제해야 한다.
이러한 과정을 소프트웨어 요구사항 분석과정이라 한다. 이해 당사자들에게 요구 사항을 수집하고, 정제한다. 그 중 품질 요구 사항에 대한 우선순위를 정한다. (중요도/난이도) - 요구사항 우선순위화
우선순위가 높은 것을 우선하여 설계를 진행한다. 설계 결정 간 Trade off관계에 있을 때, 이러한 우선순위가 선택이 도움이 된다.
4. 요구사항 명세
각 품질 요구사항들을 품질 속성 시나리오로 구체적으로 명세한다. 소프트웨어 개발 프로젝트에서 핵심문서이다. 프로젝트의 목표와 범위, 시스템의 동작 및 비동작 요구사항, 기대치 등을 상세하게 기술한 문서이다. 이 명세서는 개발자, 디자이너, 프로젝트 관리자, 테스터 및 기타 이해당사자 간 공통된 이해와 소통을 촉진하고, 개발 프로세스를 지원하기 위해 사용된다.
위와 같은 요구사항 명세가 Software Architecture로 달성해야 할 목적이 된다. 우선순위가 높은 품질요구사항 부터 만족 시켜가야 한다. 어떻게 해당 요구사항을 달성할지 논리적으로 전개해야 한다.
5. 좋은 Software Architecture
좋은 Software Architecture란 무엇일까? 기준을 무엇으로 정할 수 있을까에 대해 고민해본다.
Software의 목적은 사용자가 가장 필요로 하는 요구 사항을 만족하는 것이다. 구성 요소 간 응집성이 좋고, 결합성이 낮더라도, 사용자가 가장 중요하게 생각하는 요구 사항을 만족 시키지 못한다면, 고객 그 Software를 선택하지 않을 것이다. 따라서, Software 가 달성해야 하는 목표인 요구사항을 이해 당사자들과 정확하게 이해하는 것이 가장 중요하다. 이러한 요구사항을 가장 잘 달성하는 Architecture가 가장 좋은 설계라고 생각한다.
대부분의 개발자들은 좋은 설계는 Clean Architecture : SOLID를 만족하는 것으로 알고 있다. 그러나, Clean Architecture 의 원칙을 따르는 것이 실제 고객의 요구사항과 일치하지 않을 수 있다.
좋은 Software Architecture는 Clearn Architecture원칙을 만족하는 것이 아니라, 이해 당사자들간 논의를 통해 결정한 품질 요구사항들을 우선순위에 맞춰 만족하는 것이다.
6. Clean Architecture가 좋은 Architecture ?
Clean Architecture는 개발자 관점에서 OCP를 달성하여 유지 보수성을 높여 적은 Resource로 효율화를 달성하는데 목적이 있다. Clean Achitecture 적용을 통해 달성 하고자 하는 것은 적은 인력으로 많은 과제를 Cover하는 것이다. 그런데, 고객의 입장에서 이러한 유지 보수성이 중요할까? 고객에게 가장 중요한 품질은 서비스의 가용성과 성능이다. 이러 품질 속성은 개발자가 추구하는 유지 보수성과 상당히 Trade off 관계에 있다.
