유즈케이스 다이어그램으로 요구사항을 사용자 관점에서 설계하기

사용자와 시스템이 만나는 지점을 그리는 모델

유즈케이스 다이어그램(Use Case Diagram)은 UML(Unified Modeling Language)의 행위 다이어그램 가운데 하나다. 시스템 경계 안에서 액터(Actor)와 시스템이 주고받는 상호작용을 시각화해, 사용자가 시스템에 요구하는 기능과 서비스를 명세한다.

복잡한 요구사항도 사용자 관점에서 단순화해 볼 수 있다는 점이 핵심이다. 구현 방식보다 시스템이 제공해야 할 행위와 그 범위를 먼저 합의할 때 적합하다.

다이어그램을 이루는 대상

액터는 시스템 밖에서 시스템과 상호작용하는 개체다. 보통 사람을 떠올리지만 외부 시스템이나 하드웨어도 액터가 될 수 있다. 표현에는 일반적으로 스틱 피겨를 사용하며, 서비스를 요청하는 주 액터와 시스템이 서비스를 요청하는 보조 액터로 나눌 수 있다.

⤢✕

유즈케이스는 시스템이 액터에게 제공하는 기능 또는 서비스다. 타원형 안에 기능명을 적고, 액터의 목표를 달성하는 작업 흐름을 나타낸다. 이름은 “로그인하기”, “주문 처리하기”처럼 명사보다 동사 형태로 쓰는 편이 기능의 의도를 분명하게 만든다.

시스템 경계는 사각형으로 시스템의 범위를 구분한다. 유즈케이스는 이 경계 안에 놓고 액터는 바깥에 배치하며, 시스템 이름은 보통 경계 상단에 적는다.

액터와 유즈케이스, 또는 유즈케이스끼리의 연관성은 관계로 표현한다. 이때 연관관계, 포함관계, 확장관계, 일반화 관계를 구분해야 의미가 흐려지지 않는다.

관계가 전달하는 의미

액터가 기능에 참여하는 연관관계

연관관계(Association)는 액터와 유즈케이스 사이의 기본 상호작용이다. 실선으로 연결하며, 액터가 해당 유즈케이스에 참여한다는 뜻을 담는다. 필요하면 화살표로 방향을 표시해 단방향 또는 양방향 관계를 표현할 수 있다.

⤢✕

반드시 수행되는 기능은 포함관계로 분리한다

포함관계(Include)는 한 유즈케이스가 다른 유즈케이스를 필수로 포함할 때 사용한다. 점선 화살표에 <<include>> 스테레오타입을 표시하고, 기본 유즈케이스에서 포함되는 유즈케이스 쪽으로 화살표를 보낸다.

재사용 가능한 공통 기능을 분리해 모듈화할 때 유용하다. 예를 들어 “주문하기”는 반드시 “결제하기”를 포함한다.

⤢✕

조건이 붙는 기능은 확장관계로 표현한다

확장관계(Extend)는 기본 유즈케이스에 특정 조건에서만 더해지는 선택적 기능을 나타낸다. 점선 화살표와 <<extend>> 스테레오타입을 사용하며, 확장 유즈케이스에서 기본 유즈케이스 방향으로 화살표를 그린다.

조건부 행위를 기본 흐름에서 분리할 때 쓰인다. “주문하기”가 특정 조건에서 “할인 적용하기”로 확장되는 경우가 이에 해당한다.

⤢✕

공통 특성과 차이를 드러내는 일반화

일반화(Generalization)는 액터끼리 또는 유즈케이스끼리의 일반화-특수화 관계를 표현한다. 빈 삼각형 화살표가 있는 실선을 사용하며, 특수한 자식 요소에서 일반적인 부모 요소로 향한다. 공통 특성은 부모에 두고 차이점은 자식에 정의한다.

회원과 비회원이 모두 고객을 상속하는 관계가 예시가 될 수 있다.

⤢✕

요구사항에서 다이어그램으로 옮기는 과정

먼저 개발할 시스템의 이름과 범위를 정하고, 외부 시스템과의 경계를 구분한다. 이어서 시스템과 상호작용하는 모든 외부 개체를 찾아 주 액터와 보조 액터를 나누며, 액터 사이의 일반화 관계도 검토한다.

각 액터가 요구하는 기능을 도출한 뒤 유즈케이스를 동사형으로 이름 붙인다. 너무 상세하거나 지나치게 추상적인 수준을 피하는 것이 필요하다. 그다음 액터와 유즈케이스의 연관관계를 연결하고, 유즈케이스 사이에 포함·확장·일반화 관계가 있는지 식별한다.

다이어그램만으로는 상세 내용을 모두 표현하기 어렵다. 중요한 유즈케이스는 기본 흐름, 대체 흐름, 예외 흐름 등을 포함한 유즈케이스 명세서로 문서화해야 한다.

온라인 쇼핑몰에 적용한 형태

온라인 쇼핑몰에서는 회원, 비회원, 관리자처럼 역할이 다른 액터가 서로 다른 기능에 연결된다. 주문은 결제를 필수로 포함하고, 마일리지 적립과 쿠폰 적용은 주문의 선택적 확장으로 표현할 수 있다.

⤢✕

이 예시에서 주요 액터는 회원, 비회원, 관리자다. 회원과 비회원은 일반화 관계이며, 비회원이 회원가입하면 회원이 된다. 회원은 로그인, 상품 검색, 장바구니 관리, 주문 등의 기능을 사용하고, 관리자는 상품 관리와 회원 관리 기능을 담당한다.

요구사항 협의에서 얻는 점과 한계

유즈케이스 다이어그램은 시스템을 사용자 관점에서 분석하게 해 비기술적 이해관계자도 내용을 비교적 쉽게 이해할 수 있다. 시스템 경계와 기능 범위를 명확히 하고, 요구사항과 구현 사이의 추적성을 확보하는 데도 도움이 된다. 개발팀과 비즈니스 관계자가 기능을 논의하는 공통 언어가 될 수 있다.

반면 내부 처리 로직이나 데이터 흐름을 상세히 나타내기는 어렵다. 대규모 시스템에서는 다이어그램 자체가 복잡해질 수 있고, 구현 방법이나 기술 스택도 제공하지 않는다. 따라서 다이어그램만으로 충분한 정보를 전달하기 어렵다는 한계를 전제로 보완 문서를 함께 준비해야 한다.

프로젝트 초기의 요구사항 수집과 정의, 시스템 범위 및 기능 세트 설정, 이해관계자 간 기능 합의, 주요 기능의 식별과 분류에 활용할 수 있다. 설계와 구현 단계에서는 개발 우선순위와 모듈 구조를 결정하는 지침으로도 사용할 수 있다.

작성할 때는 액터와 유즈케이스의 이름을 명확하고 일관되게 유지하고, 관계 유형의 정확한 의미를 이해한 뒤 적용해야 한다. 모든 세부 기능을 담기보다 핵심 기능에 집중하며, 추상화 수준이 지나치게 상세하거나 모호해지지 않도록 조절한다.