유스케이스

도메인 분석과 모델링 사이에 연결되는 작업이

유스케이스use case를 찾아내는 일이다.

 

요구를 모으고(추출)

→ 도메인을 이해하고(분석)

→ 시스템이 실제로 어떻게 동작해야 하는지

 

사용자 관점에서 정리해야 한다.

그 연결 고리가 유스케이스(use case) 이다.

---

1) 유스케이스가 하는 일: 도메인 개념을 “동작 명세”로 매핑

도메인 분석은 “모델을 만드는 것”이라기보다,
모델링에 필요한 개념(용어/규칙/구조) 를

이해하고 뽑아내는 작업이다.

 

그리고 유스케이스는 그 결과를 가져와서,

• 액터(Actor)
• 유스케이스(기능 단위)
• 관계(Relationship)
• 시스템 범위(System Boundary)

로 구성된 형태로 시스템의 동작을 모형화한다.

 

즉, “업무의 세계(도메인)”에서 발견한 개념들이
“시스템이 제공해야 할 서비스(동작)”로

바뀌는 순간이 유스케이스이다.

---

2) 유스케이스가 중요한 이유

유스케이스는 요구 분석에서 끝나는 문서가 아니다.

 

시스템 개발 전 과정에서

계속 재사용되는 핵심 빌딩 블록이 된다.

• 모델링/설계의 재료
  : 객체, 속성, 메시지, 관계 같은 정보를 뽑아낼 수 있다.
• 테스트의 재료
  : 구현 후 테스트 시나리오(정상/예외 흐름)를 구성할 수 있다.
• 요구의 길잡이
  : 무엇을 만들어야 하는지를 사용자 관점에서 계속 확인할 수 있다.

---

3) 유스케이스 모델의 4요소

유스케이스는 아래 4개가 결합된 것이다.

• 액터(Actor)
  : 시스템과 상호작용하는 외부 존재(사람/조직/다른 시스템 등)
• 시스템 범위(Boundary)
  : 시스템 안/밖을 구분하는 경계
• 유스케이스(Use Case)
  : 액터에게 보이는 시스템의 기능(단위 기능)
• 관계(Relationship)
  : 유스케이스 간 연결(포함/확장 등)

핵심은 “시스템이 하는 일”과

“시스템 밖에서 일어나는 일”을

정확히 가르는 것이다.

액터는 시스템 밖,

유스케이스는 시스템 안에 위치한다.

---

4) 유스케이스 분석 절차 3단계

유스케이스 분석은 보통 아래 순서로 진행된다.

1. 액터 찾기
2. 유스케이스 찾기
3. 유스케이스 사이의 관계 찾기

결과물은 두 가지이다.

• 유스케이스 다이어그램
  : 기능 “목차”를 그림으로 보여줌
• 유스케이스 명세서
  : 각 기능의 “이벤트 흐름(시나리오)”를 글로 자세히 적음

---

5) 유스케이스 다이어그램이란?

유스케이스 다이어그램은
외부에서 보이는 시스템 동작에 초점을 둔 그림이다.

 

구성은 단순하다.

• 액터(사람 아이콘 등)
• 유스케이스(타원)
• (그리고 필요하면 관계: include/extend 등)

이 다이어그램을 그리는 과정 자체가 결국
“시스템 범위를 어디까지로 볼 것인가?”를 정하는 작업이 된다.

---

6) 액터(Actor) — “사람”이 아니라 “역할”이다

액터는 시스템과 상호작용하는 외부 엔티티이다.
사람일 수도 있고, 외부 시스템일 수도 있다.

중요한 포인트는 이것이다.

• 액터는 역할(role)의 추상화이다.
• 같은 사람이라도 역할이 다르면 서로 다른 액터가 될 수 있다.
  (예: ‘학생’ 역할 vs ‘관리자’ 역할)

액터 찾을 때 던질 질문

• 누가 업무를 수행하기 위해 시스템 도움을 받는가?
• 누가 핵심 기능을 사용하는가?
• 누가 유지보수/관리 같은 부수 기능을 쓰는가?
• 시스템이 연동되는 외부 하드웨어/소프트웨어는 무엇인가?

---

7) 유스케이스(Use Case) — “관찰 가능한 결과”를 만드는 동작 묶음

유스케이스는 시스템이 수행하는 일련의 동작으로,
특정 액터에게 관찰 가능한 결과를 제공한다.

또 다른 말로,

• 유스케이스는 여러 시나리오의 집합이다.
• 정상 흐름만이 아니라 오류/예외/대안 흐름까지
  포함해야 “유스케이스답다”.

유스케이스 찾을 때 도움이 되는 질문

• 각 액터가 시스템과 관련해 하는 작업은 무엇인가?
• 시스템에서 발생하는 사건을 액터에게 알려야 하는가?
• 액터가 외부 변화(상황)를 시스템에 알려야 하는가?
• 시스템이 비즈니스 규칙에 맞는 동작을 제공하는가?
• 찾은 유스케이스로 기능이 빠짐없이 커버되는가?
• 유지보수/지원 목적의 유스케이스는 무엇인가?
• 시스템에서 생성/수정되어야 하는 정보는 무엇인가?

---

8) 유스케이스 명세서 — “시간 순서”로 쓰는 상호작용 시나리오

유스케이스 명세는 시스템이 제공할 서비스를

시간 흐름 순서대로 기술한 문서이다.

 

보통 다음을 포함한다.

• 시작 조건(Precondition)
  : 시나리오 시작 전에 만족되어야 하는 것
• 기본 흐름(Basic Flow)
  : 정상 성공 시나리오
• 대안 흐름(Alternative Flow)
  : 오류/예외/분기 시나리오
• 종료 조건(Postcondition)
  : 끝난 뒤 시스템 상태

(추천) 유스케이스 명세 템플릿

• 시스템 제목
• 유스케이스 이름
• 액터
• 시작 조건
• 기본 흐름(번호로 단계화)
• 대안 흐름(번호 + 조건/예외)
• 종료 조건

---

9) 이벤트 흐름(Event Flow) 작성 가이드

이벤트 흐름은 요구 분석 이후(모델링/설계/테스트)를 좌우한다.
그래서 “누가 읽어도 오해 없게” 쓰는 게 중요하다.

체크리스트로 정리하면 아래와 같다.

• 시작/종료 조건을 명확히 쓴다.
• 액터↔시스템 사이에 교환되는 데이터를 설명한다.
• UI 세부는 꼭 필요할 때만(가능하면 “What” 중심).
• “액터가 ~한다”처럼 상호작용 사건으로 쓴다.
• 다른 유스케이스/시스템 밖 사건은 끌고 오지 않는다.
• “예를 들면/등/정보” 같은 모호한 표현은 피한다.
• 테스트 케이스로 뽑을 수 있을 정도로 구체적이어야 한다.

---

10) 유스케이스 사이의 관계: 대안 / include / extend

기본 흐름이 너무 길고 복잡해지면
일부 이벤트 흐름을 분리해서 구조를 개선할 수 있다.

 

대표 패턴은 아래 3가지이다.

• 대안 흐름 분리
  : 예외/선택/변형 흐름을 따로 빼서 정리
• 포함(include)
  : 여러 유스케이스에서 공통으로 재사용되는 동작 캡슐화
• 확장(extend)
  : 특정 조건에서만 추가로 끼워지는 선택적 동작 분리

include vs extend 한눈에 비교(표)

구분	include(포함)	extend(확장)
성격	“공통으로 항상 들어가는” 재사용 동작	“조건에 따라 추가되는” 선택/예외 동작
목적	중복 제거, 공통 절차 캡슐화	기본 흐름 단순화, 옵션/예외 분리
기본 유스케이스의 완결성	포함이 없어도 의미는 통하지만, 흐름상 자주 사용되는 공통 동작을 분리	기본 유스케이스는 확장 없이도 완전해야 함
언제 쓰나	핵심 목적 이해에 필수는 아니지만 반복되는 절차가 있을 때 / 공통 요소가 2개 이상 유스케이스에 있을 때	멤버십 할인처럼 “특정 조건에서만 발생”하는 추가 흐름이 있을 때

---

11) 사용자 스토리 vs 유스케이스

둘 다 사용자가 이해 가능한 언어로 요구를 표현한다.

하지만 깊이가 다르다는 차이점을 지닌다.

항목	사용자 스토리(User Story)	유스케이스(Use Case)
형태	짧은 한 문장(해석 여지 존재)	상호작용을 단계적으로 구체화
목적	빠르게 요구를 공유/협업	기능을 사건 흐름으로 명확히 정의
기본 구성	who + why + what	목표/제목 + 성공 흐름 + 대안/확장 흐름
결과물 느낌	“무엇을 원한다” 중심	“어떻게 상호작용해서 달성하는가” 중심

---

마무리

도메인 분석이 “개념과 규칙을 이해하는 작업”이라면,
유스케이스는 그걸 바탕으로 시스템이 해야 할 동작을

사용자 관점에서 고정하는 작업이다.

• 액터를 찾고(경계 설정)
• 유스케이스를 찾고(기능 목차 구성)
• 관계를 정리하고(include/extend로 구조화)
• 명세서의 이벤트 흐름을 제대로 쓰면(What 중심)

요구 → 설계 → 테스트까지 흐름이 자연스럽게 이어진다.