[Software Engineering] Use Case

 

이번 글에서는 그 중 Specification 단계에서 가장 많이 쓰이는 도구 중 하나인 Use Case에 대해서 작성하겠다. Use Case는 단순한 기능 목록이 아니다. 사용자와 시스템 사이의 상호작용을 시나리오로 표현함으로써, 요구사항을 구체적이고 검증 가능하게 만들어주는 도구다.

 

 

Use Case란 무엇인가

Use Case는 특정 목표를 달성하기 위해 사용자와 시스템 사이에서 일어나는 하나의 특정한 상호작용 시나리오다. 즉, "이 기능이 존재한다"가 아니라 "이 사람이 이 목적으로 시스템을 이렇게 사용한다"를 설명하는 것이다.

 

Use Case가 유용한 이유는 다음과 같다.

1. 사용자 입장에서 직관적이다. 개발자가 시스템 내부를 중심으로 생각하는 것과 달리, Use Case는 철저히 외부 관점에서 기술된다. 클라이언트나 비개발자도 읽고 이해할 수 있다.
2. 테스트 케이스와 직접 대응된다. 하나의 Use Case는 곧 하나의 테스트 시나리오가 된다. Success Scenario는 정상 케이스 테스트가 되고, Extension Scenario는 예외 케이스 테스트가 된다.
3. 구현 세부사항과 독립적이다. "어떻게 구현할 것인가"가 아닌 "무엇을 해야 하는가"에 집중한다.
4. 시스템 기능을 분해하는 수단이 된다. 하나의 큰 시스템을 여러 개의 Use Case로 쪼개면서 기능의 경계를 명확히 할 수 있다.

 

---

 

POS 판매 예시로 살펴보는 Use Case

Use Case를 이해하는 가장 빠른 방법은 예시를 보는 것이다. 아래는 편의점이나 마트의 POS(Point of Sale) 시스템에서의 판매 처리 시나리오다.

고객이 구매할 물건을 들고 계산대에 도착한다. 캐셔는 POS를 이용해 각 상품을 등록한다. 시스템은 누적 합계와 상품별 정보를 유지한다. 고객이 결제 정보를 입력하면 시스템이 이를 검증하고 기록한다. 시스템은 매장 재고도 업데이트한다. 고객은 영수증을 받고 구매한 물건과 함께 떠난다.

 

 

이걸 다시 한 번 읽어보면, 색깔로 구분할 수 있는 부분들이 보인다. 캐셔의 행동이 있고, 시스템의 반응이 있고, 고객의 행동이 있다. 그리고 이 세 가지가 서로 맞물려 하나의 목표(결제 완료)를 향해 흘러간다. 이것이 Use Case의 본질이다.

 

 

 

 

핵심 개념: Actor, Goal, Scenario

Use Case를 구성하는 핵심 개념은 세 가지다.

• Actor는 시스템과 상호작용하는 사람 또는 다른 시스템을 말한다. 여기서 중요한 구분은 Primary Actor와 Secondary Actor다. Primary Actor는 시나리오를 시작하는 사람이다. POS 예시에서는 캐셔가 POS에 상품을 스캔하면서 시나리오를 시작하므로 캐셔가 Primary Actor다. 고객은 결제 정보를 입력하는 등 시나리오에 참여하지만, 시나리오를 시작하지는 않으므로 Secondary Actor다.
• Goal은 Primary Actor가 달성하고자 하는 결과다. POS 예시에서 목표는 "결제를 성공적으로 완료하는 것"이다.
• Scenario(시나리오)는 두 종류로 나뉜다.
  • Success Scenario는 모든 것이 계획대로 흘러가서 목표가 달성되는 것이다.
  • Extension Scenario는 비정상적인 조건, 예외 상황, 또는 선택적 경로에 의해 분기되는 시나리오다.

 

Extension Scenario: 예외를 고려

Use Case의 진가는 Extension Scenario를 작성할 때 드러난다. 성공 경로만 그리는 것은 반쪽짜리 명세다. 시스템이 실제로 동작하는 환경에서는 예외가 항상 발생한다. Extension Scenario는 "이 단계에서 이런 일이 생기면 어떻게 할 것인가"를 명시적으로 다룬다.

 

POS 예시의 Extension Scenario들을 보면 성격이 두 가지로 나뉜다.

• 예외(Exception) 케이스로는 바코드를 스캔할 수 없는 경우(수동으로 상품 코드 입력), 결제가 거절된 경우(다른 결제 수단 제시), 시스템 오류로 재고가 업데이트되지 않은 경우(지원팀 알림 또는 재시도)가 있다.
• 대안 경로(Alternative Path) 케이스로는 고객이 쿠폰을 사용하는 경우(할인 적용)가 있다. 이건 오류가 아니라 유효한 선택지다.

Extension Scenario를 작성할 때 지켜야 할 원칙들이 있다. 개별 행동이 어떻게 실패하거나 다르게 동작할 수 있는지 고려해야 하고, 각 확장에 대해 합리적인 대응을 제시해야 한다(다른 시나리오로 점프하거나, 상호작용을 종료하거나)

"사용자는 절대 비밀번호를 잊지 않는다"처럼 비현실적인 가정을 피해야 하며, 원래 시나리오의 범위를 벗어나서는 안 된다. 자연재해나 정전 같은 상황까지 Extension으로 다루기 시작하면 이전 글에서 이야기했던 Scope Creep과 같은 문제가 된다.

 

 

Use Case 작성 3단계

Use Case를 작성하는 과정은 세 단계로 정리할 수 있다.

 

1단계: Actor와 Goal 식별

어떤 사용자와 서브시스템이 우리 시스템과 상호작용하는가? 각 Actor가 필요로 하는 것은 무엇인가? 이 두 질문에 답하면 Use Case의 뼈대가 잡힌다.

 

2단계: 메인 Success Scenario 기술

"해피 엔딩" 이야기를 상상해보는 것이 핵심이다. 모든 것이 완벽하게 잘 됐을 때 어떤 순서로 일이 벌어지는가? 각 Actor가 정보를 제공하며 이 해피 엔딩에 기여하는 방식을 서술한다. 이 시나리오에서 벗어나는 모든 것은 다음 단계인 Extension이 된다.

 

3단계: 잠재적 실패 Extension 목록화

어느 단계에서 실패할 수 있는지 상상한다. 실패가 발생했을 때 복구 경로를 제공할 수 있다면(즉, 다시 해피 엔딩 시나리오로 돌아올 수 있다면) 그 경로를 명시한다. 복구가 불가능하다면 그것은 비복구 예외(exceptional ending)로 처리한다.

 

 

---

 

 

Agile 개발에서의 Use Case: User Story

Use Case는 Agile 개발 방식과도 잘 어울린다. 하나의 Use Case는 여러 개의 User Story로 분해될 수 있고, 이는 점진적인 구현과 전달을 가능하게 한다.

User Story의 형식은 다음과 같다.

As a [role], I want to [do something], so that [goal].

 

POS 판매 Use Case를 User Story로 분해하면 이렇게 된다.

• As a cashier, I want to scan items, so that the POS can record each item being purchased.
• As a cashier, I want POS to display a running total and per-item details, so that I and customer can verify the purchase.
• As a customer, I want to enter my payment information, so that I can complete the purchase.
• As the cashier, I want all payments to be validated and recorded, so that the transaction is securely completed.
• As an inventory manager, I want the system to automatically update the inventory, so that stock levels remain accurate.
• As a customer, I want to receive a receipt, so that I have proof of purchase.

여기서 한 가지 주목할 점이 있다. 슬라이드에는 두 버전의 User Story가 등장하는데, 한 버전에서는 "As a system"이라는 표현을 쓰고 다른 버전(개선된 버전)에서는 이를 실제 사람 역할로 교체한다. "As the system, I want to update inventory"보다 "As an inventory manager, I want the system to update inventory"가 더 좋은 이유는 User Story의 목적이 사람의 필요를 표현하는 것이기 때문이다. 시스템 자체는 Actor가 아니다.

 

 

---

 

 

Use Case 다이어그램

Use Case는 텍스트 명세뿐만 아니라 다이어그램으로도 표현된다. UML Use Case 다이어그램은 Actor(사람 모양 아이콘), Use Case(타원), 그리고 이들 사이의 관계(선)로 구성된다.

 

• POS 예시의 다이어그램에는 Cashier와 Customer, Inventory라는 세 Actor가 등장한다.
• 다양한 Use Case들이 배치된다.
• <<include>> 관계는 하나의 Use Case가 다른 Use Case를 반드시 포함함을 나타낸다. 예를 들어 scan item은 display scanned, record purchased item, update and display total을 include한다.

주목해야 할 것은 슬라이드에서 이 다이어그램을 "a possible use case diagram"이라고 표현한다는 점이다. Use Case 다이어그램에는 고정된 정답이 없다. 같은 시스템을 어떻게 분해하고 어떤 관계를 강조하느냐에 따라 다양한 형태의 다이어그램이 나올 수 있다.

 

 

Formal Use Case: 구조화된 명세

Use Case를 자연어로만 기술하면 여전히 모호함이 남는다. 이를 보완하기 위해 Formal Use Case, 즉 구조화된 형식으로 작성하는 방법이 있다. 다만 이 형식에도 고정된 표준은 없다. 프로젝트나 조직마다 조금씩 다른 템플릿을 쓴다.

POS 예시의 Formal Use Case를 보면 다음과 같은 항목들로 구성된다.

 

 

 

Use Case와 Scenario의 관계 정리

마지막으로 두 개념의 관계를 정리하면 이렇다.

Use Case는 사용자가 특정 목표를 달성하기 위해 시스템과 상호작용하는 방식을 설명한다. 하나의 Use Case는 여러 시나리오(메인, 대안, 예외)를 포함한다.

 

Scenario는 시스템의 예시 동작을 설명하는 일련의 행동 순서다. Use Case 안의 각각의 경로 하나하나가 Scenario다.

즉, Use Case는 컨테이너이고 Scenario는 그 안의 내용물이다.

 

 

---

 

Software Requirement Specification (SRS)

Use Case를 비롯한 모든 요구사항 명세의 결과물은 SRS(소프트웨어 요구사항 명세서)로 통합된다. SRS는 "개발될 소프트웨어 시스템에 대한 설명"이다.

 

SRS에 대해 오해하기 쉬운 점이 몇 가지 있다. 먼저 SRS는 자연어 문서다. 컴파일되지 않고, 고정된 공식 구조도 없다. 하지만 이것이 SRS를 덜 중요하게 만들지는 않는다. 오히려 반대다. 이 문서를 얼마나 올바르게 작성하느냐가 프로젝트 전체의 방향을 결정한다. 개발 중에, 그리고 개발이 끝난 후에도 시스템이 올바른지 판단하기 위해 계속해서 이 문서를 참조하게 된다.

 

SRS는 클라이언트, 관리자, 시스템 엔지니어, 테스트 엔지니어, 유지보수 엔지니어 등 다양한 역할을 가진 사람들이 읽는다. 그렇기 때문에 간결하고 일관된 언어를 쓰는 것이 중요하며, UML 다이어그램 같은 시각적 도구를 활용해 이해를 돕는 것이 좋다.

 

 

---

 

정리

Use Case는 요구사항 명세의 도구이지만, 잘 작성된 Use Case는 그 이상의 가치를 갖는다. 개발자와 고객이 같은 그림을 보며 대화할 수 있는 공통 언어가 되고, 테스트 케이스의 기반이 되며, 시스템의 경계를 명확히 하는 데 도움이 된다.

 

Use Case를 작성할 때 가장 중요한 원칙은 하나다. 목표와 상호작용에 집중하고, 내부 시스템 동작, 구현 선택, 사용자 인터페이스에 대해서는 언급하지 않는 것이다.

 

"버튼을 누르면 HTTP POST 요청이 전송된다"는 Use Case가 아니다. "고객이 결제를 완료한다"가 Use Case다. 요구사항은 무엇을 할 것인가에 관한 것이지, 어떻게 할 것인가에 관한 것이 아니기 때문이다.

 

 

출처: 경북대학교 손정주 교수님, "소프트웨어공학" 강의 자료