[Requirement Engineering] 설계 시 필요한 제약

아키텍처 핵심 요구사항에 꼭 필요한 부분은 제약사항이다.

제약은 소프트웨어 설계 시 꼭 검토해야 하는 사항입니다. "제약이란 이미 정해져서 변경이 불가능한 설계상의 의사결정" 을 의미합니다. 제약은 이해관계자들과의 논의 과정 중에서 발생할 수도 있고, 아키텍트 스스로 만들어 내는 제약도 존재합니다.

잘 선택한 제약은 소프트웨어 설계에 큰 도움이 된다.

제약은 아키텍트가 설계할 때 선택할 수 있는 다양한 구조를 제한하지만 요구사항 분석 과정에서 잘 정리된 제약은 문제를 단순화하고 좋은 아키텍처를 만드는데 큰 도움이 됩니다. 하지만 제약사항을 잘못 정의하는 경우에는 문제가 커질 수 있으며 또는 이해관계자들의 요구사항을 만족할 수 있는 경우가 발생하기도 합니다.

제약은 비지니스 모델과 설계에 필요로하는 기술에도 영향을 미칠 수 있습니다. 여기서는 비지니스 모델에 관한 내용은 제외하고 기술적인 부분에 대해서만 예시로 알아보겠습니다.

아래와 같이 고객의 니즈가 있었습니다.

저희가 원하는 서비스는 오직 안드로이드에서만 동작했으면 좋겠습니다. 아 그리고 우리는 우리 서비스에 들어간 소스코드를 오픈하고 싶지 않습니다. 오직 저희만이 소유하고 싶습니다.

위와 같은 요구사항이 있다면 개발팀 중 iOS나 안드로이드가 아닌 다른 플랫폼기반에서 개발하는 팀과는 협력하기 어렵습니다. 개발언어 또한 안드로이드 어플리케이션 개발 시 사용되는 Java, Kotlin 으로 제한됩니다. (C++ / Unity를 활용한 C# 개발 등 다른 방법도 있겠지만, 이 글에서는 저렇게 제한된다고 가정합시다.) 또한 다양하고 좋은 오픈소스들을 다수 사용할 수 없을 수도 있습니다. 라이센스를 꼭 확인해야만 하는 기술적인 제약이 존재하게 됩니다.

제약사항을 단순화하자

제약사항은 쉽게 파악될 수도 그렇지 않을 수도 있습니다. 그리고 설계 초기단계에 결정된 제약사항은 추후 돌이킬 수도 없습니다. 만약 제약사항을 잘못 정리하였거나 설계 중간 단계에서 제약사항을 파악하게 된다면 설계하던 시스템의 구조가 흔들리거나 심한경우 새롭게 설계를 해야할 수도 있습니다. 그렇다고 너무 많은 제약사항을 정의하게 된다면 설계에 많은 어려움이 있습니다. 많으면 많을수록 좋은게 아니라는 것을 항상 생각하고 보수적으로 제약사항을 받아들여야 합니다. 한번 결정된 제약사항을 쉽게 돌이 킬 수 없습니다, 복잡하게 서술형으로 제약사항을 정리하지 않고 단순한 문장으로 정리하는 것도 좋습니다. 그리고 마지막으로 반드시 하지 않으면 안되는 제약사항과 있으면 좋을 것 같은 제약사항은 다르다는 것을 항상 기억하세요.

읽어주셔서 감사합니다.