Requirements
시스템 아키텍쳐를 설계하는 것은 일반적으로 method, algorithm, class를 구현하는 것과 다르다. 더 높은 Abstraction를 요구하며 높은 수준의 Ambiguity을 가져오는 경우가 많다. 왜냐하면 Requirements를 제시하는 사람은 기술적인 지식이 부족한 경우가 많기 때문이다.
이러한 문제를 초기에 구체화하지 않으면 기술 부채가 발생하여 비효율, 비용 더 나아가 서비스를 하는 경우에는 브랜드 이미지의 실추로 이어질 수 있다. 따라서 초기에 Requirements를 구체화 할 필요가 있다.
Requirements는 아래 3가지로 나눌 수 있다.
1. Feature of the System (=Functional requirements)
2. Quality Attribute (= Non-Functional requirements)
3. System Constraints (= Limitations and boudaries)
Feature of the System는 System의 기능적 역할을 나타낸다. 사용자가 어떤 행동을 하거나 어떤 상황이 발생하면 시스템의 입장에서 어떤 행동을 취할것인지에 대한 것이다.
Quality Attribute는 시스템이 갖춰야할 속성에 대한 것이다. Scalability, Availability, Reliability, Security 와 같은 것들이 이에 해당한다. 그래서 Quality Attribute는 Software Architecture에 직접적으로 영향을 주는 Requirements라고 할 수 있다.
System Constraints는 외부적인 제한사항이다. 시간적, 비용적, 인적 자원의 제한을 나타낸다.
이러한 Requirements를 통틀어 Architecture Drivers라고 부르기도 한다. 왜냐하면 모호한 요구사항을 구체화하여 더욱 쉽게 시스템 아키텍쳐를 설계할 수 있도록 돕기 때문이다.
Gathering Functional Requirements
그렇다면 Requirements는 어떻게 파악해야할까? Clients에게 가능한 모든 Requirements에 대해 물어 볼 수 있다. 하지만 복잡한 시스템의 경우에는 이 방법을 사용하기에 적절치 않다. 대신 Use Cases를 나열한 후 Use Cases를 구체화하기 위해 User Flows를 활용하는 것이 좋은 방법이 될 수 있다. Use Cases는 시스템이 맞닥뜨릴 상황 혹은 시나리오를 나타내는 것이고 User Flows는 이런 상황에 어떤 행위를 취해야하는지 자세히 나타낸 것을 의미한다. User Flows는 보통 시각적인 방법을 많이 사용한다. User flow를 시각화 하는데 UML의 일종인 Sequence Diagram을 많이 사용한다. 현업에서 UML을 사용하는 것이 표준 방법은 아니지만 Sequence Diagram은 entity들의 상효작용을 표현할때 종종 쓰인다. Requirements를 수집하는 것은 아래의 세 단계로 요약할 수 있다.
- 시스템에서 Actor, User를 정한다.
- 가능한 모든 Use-cases를 나열한다.
- 각 Use-case에 대해 event의 flow를 만들고 각 event에 취해야할 Action과 Data 처리에 대해 구체화 한다.
Quality Attributes
시스템의 재설계는 기능적 문제로만 일어나는 것이 아니다. 시스템의 속도, 확장성, 유지보수성, 보안 등의 비기능적(Quality Attributes) 문제로 일어날 수도 있다. Quality Attributes는 기능적 요구사항의 quality 혹은 전체 시스템의 특성을 나타낸다. 따라서 System Architecture에 직접적인 연관성이 있다. Quality Attributes는 Measurable, Testable 해야한다. 예를 들어 시스템의 속도에 대한 요구사항을 기술할때 '충분히 빨라야한다' 라는 표현보다 '200ms 이내로 이루어 져야한다' 라는 표현을 사용해야한다.
가장 이상적인 형태의 Quality Attributes를 보장하는 것은 거의 불가능에 가깝다. 왜냐하면 Quality Attributes는 많은 경우 많은 경우 서로 trade-off관계에 있을 수 있다. 예로는 시스템 처리속도와 보안수준의 관계를 들 수 있다. 또한 특정 Quality Attribute를 보장하는 것은 불가능한 것일 수 도 있다. 모든 공격을 막을 수 있는 보안 수준, 100% Availability 등과 같은 것이 있다.
System Constraints
System Constraints는 시스템을 설계할때 degree of freedom을 제한한다. 그래서 System Constraints는 우리의 결정을 제한하는 요소로 생각할 수 있다. 하지만 오히려 선택의 폭을 좁혀주는 초석을 제공해주기 때문에 System Architecture를 더욱 수월하게 설계할 수 있게 해준다.
일반적으로 3개의 System Constraints가 존재한다. Technical, Business, Legal constraints. Technical Constraint는 hardware, cloud, programming language, db, platform, browser, OS와 같은 기술적인 제한사항을 나타낸다. Business Constraint 는 비용, 기간, 3rd-party 서비스 등의 비즈니스 팀이 제시한 제한사항을 나타낸다. Legal Constraint는 Global, Specific region에 해당하는 제한사항일 수 잇다.
System Constraints를 고려할때 2가지 사항을 주의해야한다. 첫째로, 주어진 제한사항을 가벼이 여기면 안된다. Real Constraint, Self-imposed Constraint를 잘 구분해야하고 Self-imposed Constraint를 변경할때도 다시 되돌리기 힘들기때문에 신중하게 결정해야한다. 둘째로, 다른 Architecture와의 과도한 의존성은 피해야한다. 미래에 해당 Architecture를 변경해야할때 우리의 시스템의 영향을 최소화하기 위해서이다.
