유스케이스로 사용자 요구 정리하기Organizing User Requirements with Use Cases
📅
🚀
들어가기 전에 🔗
지난 시간에는 사용자의 숨겨진 요구사항을 찾아내기 위한 다양한 분석 기법들에 대해 알아보았습니다.
이렇게 수집된 요구사항들은 명확하고 체계적으로 정리되어야 모든 이해관계자가 동일한 그림을 그리고, 개발팀이 올바른 방향으로 나아갈 수 있습니다.
오늘은 이렇게 수집된 사용자 요구사항을
사용자의 관점에서
, 사용자가 시스템을 통해 무엇을 얻고자 하는지
에 초점을 맞춰 효과적으로 정리하고 표현하는 강력한 도구인 유스케이스(Use Case)
에 대해 자세히 알아보겠습니다.
이 포스팅에서는 유스케이스의 기본 개념, 액터와 시나리오의 역할, 유스케이스 서술서 작성법 등을 살펴보고, 유스케이스 다이어그램 작성법은 다음 포스팅에서 다루도록 하겠습니다.🚀
유스케이스란? (Use Case) 🔗
유스케이스는 스웨덴의 컴퓨터 과학자 이바 야콥슨(Ivar Jacobson)에 의해 처음 개념이 정립되었으며, 시스템이 사용자(또는 다른 시스템)에게 제공하는
가치 있는 기능
을 사용자의 관점에서 기술한 것입니다.
여기서 '사용자'는 시스템과 상호작용하는 사람뿐만 아니라 외부 시스템이나 장치도 포함될 수 있으며, 이를 액터(Actor)
라고 부릅니다.
사용자 목표 달성의 시나리오
쉽게 말해, 유스케이스는 "어떤 액터가 시스템을 사용하여 어떤 목표를 달성하는가?"에 대한 답변을 시나리오 형태로 기술한 것이라고 할 수 있습니다.
예를 들어, 온라인 서점 시스템이라면 다음과 같은 유스케이스들을 생각해 볼 수 있습니다.
- "회원이 도서를 검색한다."
- "회원이 도서를 주문한다."
- "관리자가 신규 도서를 등록한다."
유스케이스는 주로 타원형으로 표현되며, 액터는 사람 모양 아이콘으로 표현되어 유스케이스 다이어그램을 통해 시스템의 전체적인 기능 범위를 시각적으로 나타내는 데 사용됩니다.
하지만 유스케이스의 진정한 가치는 다이어그램보다는 각 유스케이스의 상세한 내용을 기술하는
유스케이스 서술서(Use Case Specification 또는 Use Case Description)
에 있습니다.🚀
유스케이스의 핵심 구성 요소 🔗
유스케이스를 제대로 이해하고 작성하기 위해서는 다음 세 가지 핵심 구성 요소를 명확히 알아야 합니다.
✅
1. 액터 (Actor) 🔗
액터는 시스템
외부
에 있으면서 시스템과 상호작용하여 특정 목표를 달성하려는 사람, 다른 시스템, 또는 장치 등을 의미합니다.
액터는 유스케이스를 시작시키거나 유스케이스의 결과에 영향을 받습니다.➡️
주 액터 (Primary Actor) 🔗
특정 유스케이스의 목표를 달성하기 위해 시스템을 사용하는 주된 액터입니다. 유스케이스를 시작시키는 경우가 많습니다.
(예: "도서 주문" 유스케이스의 주 액터는 "회원")
➡️
부 액터 (Secondary Actor / Supporting Actor) 🔗
주 액터가 목표를 달성하는 과정에서 시스템이 도움을 받거나 정보를 주고받는 액터입니다.
(예: "도서 주문" 유스케이스에서 결제 처리를 위해 시스템이 상호작용하는 "외부 결제 시스템"은 부 액터)
➡️
특징 🔗
액터는 시스템의 일부가 아닙니다.
액터는 역할(Role)을 나타냅니다. 특정 사람이나 시스템이 여러 액터 역할을 수행할 수도 있습니다.
유스케이스 다이어그램에서는 보통 사람 모양 아이콘으로 표현됩니다.
✅
2. 유스케이스 (Use Case) 🔗
유스케이스는 특정 액터가 시스템을 통해 달성하고자 하는
목표
를 나타내며, 시스템이 액터에게 제공하는 하나의 완전한 기능 단위입니다.
유스케이스 이름은 주로 동사구 형태(예: "사용자 로그인", "게시글 작성", "상품 검색")로 명명됩니다.➡️
특징 🔗
액터에게 의미 있는 결과를 제공해야 합니다.
하나의 유스케이스는 여러 시나리오를 포함할 수 있습니다.
유스케이스 다이어그램에서는 타원형으로 표현됩니다.
✅
3. 시나리오 (Scenario) 🔗
시나리오는 특정 유스케이스가 시작되어 종료될 때까지 액터와 시스템 간에 발생하는
일련의 상호작용 단계
들을 구체적으로 기술한 것입니다.
마치 연극의 한 장면처럼, 어떤 조건에서 누가 무엇을 하고, 그 결과 어떤 일이 일어나는지를 순서대로 보여줍니다.➡️
기본 흐름 (Basic Flow / Main Success Scenario) 🔗
유스케이스가 가장 일반적이고 성공적으로 실행되는 "해피 패스(Happy Path)" 시나리오입니다.
아무런 예외나 오류 없이 액터가 목표를 달성하는 과정을 기술합니다.
➡️
대안 흐름 (Alternative Flows) 🔗
기본 흐름에서 벗어나지만 여전히 액터의 목표 달성이 가능한 다른 경로들을 기술합니다.
(예: 다른 옵션 선택, 특정 조건 만족 시 다른 처리)
➡️
예외 흐름 (Exception Flows / Error Flows) 🔗
유스케이스 실행 중 오류가 발생하거나 액터가 목표를 달성하지 못하는 상황을 기술합니다.
(예: 잘못된 입력, 시스템 오류)
하나의 유스케이스는 반드시 하나의 기본 흐름을 가지며, 여러 개의 대안 흐름과 예외 흐름을 가질 수 있습니다. 이러한 시나리오들을 상세히 기술하는 것이 바로 유스케이스 서술서의 핵심입니다.
🚀
유스케이스 서술서 작성하기 🔗
유스케이스 서술서는 각 유스케이스에 대한 상세한 정보를 담고 있는 문서입니다.
정형화된 템플릿은 없지만, 일반적으로 다음과 같은 항목들을 포함합니다.
- 유스케이스 ID (Use Case ID)각 유스케이스를 고유하게 식별하는 번호 (예: UC-001)
- 유스케이스명 (Use Case Name)유스케이스의 목적을 간결하게 나타내는 이름 (예: 회원 가입)
- 액터 (Actors)유스케이스와 관련된 주 액터 및 부 액터
- 개요 (Brief Description)유스케이스의 목적과 주요 기능을 1~2 문장으로 요약
- 사전 조건 (Preconditions)유스케이스가 시작되기 위해 반드시 만족되어야 하는 조건 (예: "사용자가 로그인되어 있어야 한다.")
- 사후 조건 (Postconditions)유스케이스가 성공적으로 완료된 후 시스템의 상태 또는 보장되어야 하는 조건 (예: "새로운 회원 정보가 데이터베이스에 저장된다.", "회원에게 환영 이메일이 발송된다.")
- 기본 흐름 (Basic Flow / Main Success Scenario)유스케이스가 성공적으로 실행되는 주요 단계들을 순서대로 기술
- 대안 흐름 (Alternative Flows)기본 흐름에서 벗어나는 다른 성공 경로들을 기술
- 예외 흐름 (Exception Flows)오류 발생 시 처리 과정이나 유스케이스 실패 시나리오를 기술
- 특수 요구사항 (Special Requirements)관련된 비기능 요구사항(성능, 보안 등)이나 업무 규칙 등
- 기타 정보 (Notes and Issues)추가적인 설명이나 미해결된 문제점 등
✅
유스케이스 서술서 예시: "온라인 서점 도서 주문" 🔗
다음은 "온라인 서점 시스템에서 회원이 도서를 주문하는" 유스케이스에 대한 간략한 서술서 예시입니다.
1. 유스케이스 ID
UC-ORD-001
2. 유스케이스명
도서 주문
3. 액터
- 주 액터: 회원
- 부 액터: 결제 시스템, 재고 관리 시스템
4. 개요
회원이 원하는 도서를 선택하고 결제를 통해 주문을 완료한다.
5. 사전 조건
- 회원이 시스템에 로그인되어 있어야 한다.
- 장바구니에 주문할 도서가 1개 이상 담겨 있어야 한다.
6. 사후 조건
- (성공 시) 주문 정보가 시스템에 기록된다.
- (성공 시) 주문된 도서의 재고가 감소한다.
- (성공 시) 회원에게 주문 완료 알림이 표시되고 이메일이 발송된다.
- (실패 시) 주문 정보는 기록되지 않고, 사용자에게 실패 사유가 안내된다.
7. 기본 흐름 (Main Success Scenario)
:- 회원이 장바구니 페이지에서 '주문하기' 버튼을 클릭한다.
- 시스템은 주문 상품 목록과 총 결제 금액을 표시하고, 배송 정보 입력 화면을 제공한다.
- 회원이 배송 정보를 입력하고 '결제 진행' 버튼을 클릭한다.
- 시스템은 결제 수단 선택 화면을 제공한다.
- 회원이 결제 수단을 선택하고 결제 정보를 입력한 후 '결제' 버튼을 클릭한다.
- 시스템은 재고 관리 시스템에 주문 도서의 재고를 확인 요청한다.
- 재고 관리 시스템이 재고 충분 응답을 반환한다.
- 시스템은 결제 시스템에 결제를 요청한다.
- 결제 시스템이 결제 성공 응답을 반환한다.
- 시스템은 주문 정보를 저장하고, 재고 관리 시스템에 재고 감소를 요청한다.
- 시스템은 회원에게 주문 완료 페이지를 보여주고, 주문 확인 이메일을 발송한다.
8. 대안 흐름 (Alternative Flows)
- 8.1. 배송지 변경기본 흐름 3단계에서, 회원이 기존 배송지가 아닌 새로운 배송지를 입력하거나 선택할 수 있다. 시스템은 새로운 배송 정보를 저장한다.
- 8.2. 쿠폰 사용기본 흐름 4단계에서, 회원이 보유한 할인 쿠폰을 적용할 수 있다. 시스템은 할인된 최종 결제 금액을 계산하여 표시한다.
9. 예외 흐름 (Exception Flows)
- 9.1. 재고 부족기본 흐름 7단계에서, 재고 관리 시스템이 특정 도서의 재고 부족 응답을 반환하는 경우:
- 시스템은 회원에게 해당 도서의 재고 부족 메시지를 표시한다.
- 회원은 해당 도서를 제외하고 주문을 계속 진행하거나, 주문을 취소할 수 있다.
- 9.2. 결제 실패기본 흐름 9단계에서, 결제 시스템이 결제 실패 응답을 반환하는 경우:
- 시스템은 회원에게 결제 실패 메시지와 사유(예: 한도 초과, 유효하지 않은 카드 정보)를 표시한다.
- 회원은 다른 결제 수단을 선택하거나 결제 정보를 수정하여 다시 시도할 수 있다.
- 9.3. 시스템 오류주문 처리 중 예측하지 못한 시스템 오류가 발생하는 경우:
- 시스템은 사용자에게 "일시적인 오류가 발생했습니다. 잠시 후 다시 시도해주세요."와 같은 안내 메시지를 표시한다.
- 시스템은 오류 정보를 로그로 기록한다.
10. 특수 요구사항
- 주문 처리 과정에서의 모든 민감한 정보(개인 정보, 결제 정보)는 암호화되어야 한다.
- 주문 완료까지의 평균 응답 시간은 5초 이내여야 한다.
이처럼 유스케이스 서술서는 각 기능에 대한 상세한 시나리오를 제공하여, 개발팀이 사용자의 요구를 정확히 이해하고 시스템을 구현하는 데 중요한 기준이 됩니다.
🚀
결론 🔗
오늘은 사용자의 관점에서 시스템의 기능을 효과적으로 정의하고 분석하는 데 유용한 도구인 유스케이스에 대해 알아보았습니다.
액터, 유스케이스, 시나리오의 기본 개념을 이해하고, 상세한 유스케이스 서술서를 작성하는 방법과 가이드라인을 살펴보았습니다.
다음 시간에는 시스템의 전체적인 그림을 그리고 외부와의 관계를 정의하는시스템 모델링: 컨텍스트 다이어그램과 활동 다이어그램 사용법에 대해 알아보겠습니다.
✅
참고 🔗
- Use case - Wikipedia↗ (영문, 유스케이스 위키피디아)
- Use Case Tutorial - Visual Paradigm↗ (영문, 유스케이스 튜토리얼)