#softwareengineering > [!abstract] Information > 유스케이스*Use Case*는 소프트웨어 설계 기법 중 하나로, 사용자와 시스템의 상호작용을 기준으로 설계를 시작한다. 시스템의 기능성에 초점을 맞추고 있지만, 사용자의 관점에서 만들어지기 때문에 [[Requirement Development#^4bb6e2|비기능 요구사항]]*Non-Functional Requirement*을 효과적으로 발견할 수 있는 도구이기도 하다. 이번 글에서는 유스케이스를 만들고 관리하는 방법에 대해 알아본다. # Definition 유스케이스에는 여러가지 정의가 존재하지만, 여기서는 크게 세가지만 살펴보자. > [!info] Definition > - in UML, a complete task of a system that provides a measurable result of value for an actor \[ISO/IEC/IEEE 24765:2017\] > - description of behavioral requirements of a system and its interaction with a user \[ISO/IEC/IEEE 26515:2018\] > - specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system \[ISO/IEC 23643:2020\] 첫번째 정의는 유스케이스를 유스케이스 인스턴스*instance*들의 집합으로 정의하고 있는데, 여기서 각 인스턴스는 시스템이 특정 사용자에게 관측 가능한 결과를 제공하는 일련의 행동 과정을 일컫는다. 두번째 정의는 유스케이스를 UML*Unified Modeling Language*의 일종으로, 어떤 목적을 달성하기 위한 사용자와 시스템의 상호작용을 정리한 시나리오로 정의하고 있다. 마지막 정의는 유스케이스를 사용자들이 목적을 달성하기 위해 시스템을 사용하는 과정을 담은 시나리오의 모음집으로 정의한다. 이 시나리오는 성공할 수도 있고 실패할 수도 있지만, 동일한 시스템이 서로 다를 수도 있는 사용자와 빚어내는 상호작용이라는 점에서 서로 연관성이 있다. 유스케이스의 의의는 기존의 시스템 중심 관점에서 사용자 중심 관점으로 소프트웨어 설계의 중심이 바뀌었다는 점에 있다. System Context Diagram에서 시스템을 중심으로 무엇이 내부에 있고 무엇이 시스템과 상호작용하는지 고려했던 것과 달리, 사용자와 시스템의 상호작용이 시스템에 필요한 기능을 구성하기 때문에 사용자의 관점에서 요구사항을 도출할 수 있다. ## Use Case vs User Story 그런 점에서 애자일 기법의 사용자 스토리*User Story*와 닮았다고 볼 수도 있지만, 둘의 정의는 약간 다르다. 유스케이스가 하나의 목적을 이루기 위한 시나리오의 모음집이라면, 사용자 스토리는 각각의 시나리오를 간략하게 요약한 것이다. # 유스케이스 작성하기 유스케이스를 작성한다는 것은 시스템을 사용하는 과정에 대한 이야기를 쓰는 것이다. 이를 통해 요구사항을 간단하게 이해하고 쓸 수 있고, 다양한 이해관계자의 목표를 이루는 데 도움을 준다. 유스케이스는 그저 기능의 목록에 끝나는 것이 아니라, "시스템의 사용이 어떻게 사용자에게 눈으로 보이는 결과를 제공하거나 목적을 이룰 수 있게 해주는지"에 초점을 맞춘다. ## System Boundary 유스케이스를 작성하기 위해서는 우선 시스템 경계*System Boundary*를 정해야 한다. 시스템 경계란 어디까지가 시스템인지를 정하는 경계로, 주로 무엇이 시스템의 안에 있고 무엇이 시스템의 밖에 있는지를 정의하기 위해 사용한다. 구현해야 할 것은 시스템 안에 두고, 상호작용이 필요한 것은 시스템의 밖에 둔다. ![[PrimaryActorsAndGoalsAtDifferentSystemBoundaries.png]] 이때 시스템 경계가 반드시 한개는 아니라는 점을 염두에 두어야 한다. 시스템 경계는 여러개일 수 있으며, 어떤 시스템에서는 사용자여도 기존 시스템과 이용자를 합친 새로운 시스템 경계의 바깥에서 볼 때는 시스템의 일부일 뿐이다. ## Actor 이제 앞서 정의한 시스템을 이용하는 객체가 필요하다. 유스케이스에서는 사용자*Actor*가 그 역할을 맡고 있다. 사용자는 시스템과 상호작용하는 외재적 객체이며 사용자라고 해서 꼭 사람에 국한되는 것이 아니다. 조직, 컴퓨터 시스템, 하드웨어 장치 등 시스템과 상호작용한다면 무엇이든 사용자가 될 수 있다. 각 사용자는 상호작용으로 통해 특정한 역할*role*을 정의한다. 그중에서도 시스템과의 상호작용을 시작하는 사용자를 주요 사용자*Primary Actor*라 부르며 이미 구축된 시스템에 서비스를 제공하는 사용자를 보조 사용자*Supporting Actor*라 부른다. ### Primary Actor 주요 사용자는 시스템과의 상호작용을 시작하는 당사자이며 시스템이 제공하는 서비스를 통해 자신의 목적을 이룰 수 있다. 시스템 경계를 제대로 정의했다면 보통 시스템 바깥에 컴퓨터 시스템이 존재하기 때문에 외재적 컴퓨터 시스템이 있다면 스스로 시스템 경계를 잘 정의했는지 의심해볼 만하다. ### Supporting Actor 보조 사용자는 시스템으로부터 서비스를 받지 않고 오히려 이미 설계된 시스템 위에 서비스를 제공한다. 시스템이 특정 시간이나 주기에 어떤 이벤트를 수행한다고 해서 타이머가 주요 사용자가 되는 것이 아니듯이 구글 연동, 결제 시스템 등은 주요 사용자가 아닌 보조 사용자로써 시스템에 서비스를 제공한다. 니즈를 제공하는 것은 주요 사용자다. 그래서 기능을 설계할 때는 당연히 이 시스템으로부터 서비스를 제공받는 주요 사용자를 중심으로 설계한다. 그렇다면 누가 사용자일까? 이를 알기 위해서는 시스템을 사용하는 것은 누구인지, 이 시스템을 사용하는 다른 시스템이 있는지, 누가 이 시스템으로부터 정보를 얻는지, 자동 주식 매수과 같이 현재 자동으로 일어나는 일이 있는지를 파악해야 한다. - 누가 시스템을 사용하는가? - 이 시스템을 사용하는 다른 시스템이 있는가? - 이 시스템으로부터 정보를 얻는 것은 누구인가? - 현재 자동으로 일어나는 일이 있는가? ## Actor-Goal List 다음으로는 각 사용자의 목표, 특히 주요 사용자의 목표를 찾아야 한다. 이때의 목표는 최종 목적이 아닌, 필요로 하는 기능에 가깝다. 이를 위해 사용자마다 목표를 찾아 이들의 목표를 하나의 표에 담은 것이 바로 Actor-Goal list이다. ![[Actor-GoalList.png]] Actor-Goal List를 작성할 때는 위와 같이 사용자별로 목표를 분류해 어떤 사용자가 어떤 목표를 가지고 있는지 한눈에 볼 수 있도록 한다. 그리고 이때는 비슷해보이는 목표라 하더라도 우선 다 적는 것을 원칙으로 하는데, 이는 결과적으로 비슷할 수는 있어도 어디까지나 결과론적으로 그런 것일 뿐, 분석할 때는 서로 다른 것으로 간주하고 접근해야 하기 때문이다. ## Identifying Use Cases 이렇게 만든 Actor-Goal List는 유스케이스를 만들 때 사용하는데, 나중에 하나가 되더라도 가능하면 유스케이스를 목표와 1:1 대응하도록 쪼갠다. ![[IdentifyUseCases.png]] 일견 비슷해보이는 목표라 해도 유스케이스를 분석하는 이 단계에서는 분리해야 하는데, 이는 유스케이스의 통합이 결과론적이기 때문이다. 어디까지나 분석해봤더니 통합하는 게 나을 것 같다는 것이고 그 전에는 분리하는 것이 원칙이다. ## Use Case Diagram 이제 지금까지 조사한 내용을 바탕으로 Use Case Diagram을 그리게 된다. ![[PartialUseCaseContextDiagram.png]] 컴퓨터 시스템의 성격을 지니는 사용자는 직사각형 상자로 표시하고, 사람인 사용자는 사람 형태로 그려놓는다. 전체 시스템은 직사각형으로, 각 유스케이스는 타원형으로 그리고 각 유스케이스와 연관된 사용자는 직선으로 연결한다. ## Scenarios 시스템이 있으면 언제나 입력이 있고 출력이 있다. 그래서 사용자와 시스템의 상호작용은 사용자 입력과 그에 대한 시스템의 응답이 꼬리를 물고 이어진 형태를 띄고 있다. 그래서 유스케이스를 만들 때는 이것을 글의 형태로 정리하는 것이 중요한데, 이것이 바로 시나리오*Scenario*다. ![[usecase.jpg]] 시나리오는 중앙에 위치하는 가장 기본적인 시나리오인 주요 시나리오*Basic Flow*와 그 과정 중에서 어떤 분기점을 기준으로 갈라지는 대체 시나리오*Extension*들로 구분된다. 이 개념이 잘 이해가 되지 않는다면 유스케이스의 일부라고 생각하면 된다. 앞서 살펴본 유스케이스 인스턴스가 바로 시나리오다. > [!info] Definition > A scenario is a specific sequence of actions and interactions between actors and the system; it is also called a use case instance.[^1] Use Case Stakeholder -> 주인공은 아닌데 연관은 되어 있는 것들도 포함. 여러 개의 Happy Path 중에 나를 선택해서 메인 시나리오로 지정. ### Use Case Description 여기까지는 주로 그림을 통해 유스케이스를 설명해왔지만, 유스케이스는 다이어그램이 아니라 텍스트로 된 문서다. 유스케이스 모델링*Use Case Modeling*은 글쓰기 위주의 작업이지 다이어그램을 그리는 작업이 아니다. 그래서 유스케이스 모델링의 꽃이라 할 수 있는 작업은 바로 유스케이스 서술*Use Case Description*이라 부를 수 있다. 유스케이스 서술은 다음의 8가지 요소를 포함한다. 1. Use Case Name : 유스케이스의 이름이다. Actor-Goal List에서 사용자와 목표를 하나씩 묶고 그 순서쌍마다 하나의 유스케이스를 추출한다. 2. Primary Actor : 주요 사용자다. 이 사용자가 목표를 이루기 위해 시스템의 서비스를 호출하는 당사자다. 3. Stakeholder and Interests : 이해관계자*Stakeholder*란 서비스를 이용하는 당사자는 아닌데 시스템과 무언가 관계는 있는 객체다. 유스케이스는 이들을 만족시키기 위해 필요한 모든 기능을 가지고 있다. 4. Precondition : 전제*Precondition*는 유스케이스의 시나리오가 시작하기 전에 반드시 만족시켜야 하는 명제다. 여기에 기록되는 모든 것은 해당 유스케이스 내에서 참으로 간주된다. 5. Postcondition : 후제*Postcondition*는 유스케이스가 성공적으로 끝났을 때 반드시 참이어야 하는 명제다. 이때 모든 이해관계자의 니즈가 충족되어야 한다. 6. Main Success Scenario (or Basic Flow) : 이 시나리오는 이해관계자들을 만족시킨 성공적인 상황의 전형이다. 여러 개의 "happy path"[^2] 시나리오 중에서 하나로 정하며, 일직선의 형태로 그려진다. 7. Extensions (or Alternative Flows) : 이제 대체 시나리오를 찾는다. 이 시나리오는 주요 시나리오에서 가지처럼 뻗어나오는 형태로 그려지며 성공하든 실패하든 가능한 시나리오는 모두 조건과 그 과정을 명시한 상태로 그린다. 실패하는 시나리오는 도착 지점을 주요 시나리오와 다르게 한다. 대체 시나리오의 끝에서는 기본적으로 주요 시나리오로 돌아가도록 하며, 그것이 아닌 경우는 별도로 표시한다. 8. Special requirements : 가능한 경로를 모두 찾고 나면 기능적 요구사항 이외의 다른 요구사항들 - 비기능적 요구사항*Non-Functional Requirements*, 품질 요구사항*Quality Requirements*, 디자인 제약*Design Constraints* - 을 채워넣는다. 이 8가지 데이터를 모두 채워넣으면 유스케이스 서술이 끝난다. ### Finding Alternative Flows 기능적 요구사항 외의 특수 요구사항을 채워넣기 전에 가능한 경로를 모두 포함시켰는지 점검해야 한다. 기본 경로를 따라가며 현재 보고 있는 지점에서 다른 행동을 취할 수는 없었는지, 현재 보고 있는 지점에서 뭔가 일이 잘못되는 경우는 없는지, 어떤 순간이든 나타날 수 있는 양상이 있는지 스스로 물어보며 대체 시나리오를 찾는다. 또다른 방법으로는 카테고리를 만들어 카테고리별로 분류하는 방법이 있다. 아래와 같은 카테고리를 이용하면 이 과정에서 찾은 시나리오가 어떤 종류의 시나리오인지 파악하고 가능하다면 합칠 수도 있다. - 사용자가 애플리케이션을 설치한다. - 사용자가 특정 작업을 취소한다. - 사용자가 도움을 요청한다. - 사용자가 안좋은 데이터를 제공한다. - 사용자가 불완전한 데이터를 제공한다. - 사용자가 유스케이스를 수행하는 다른 방법을 선택한다. - 시스템이 터진다. - 시스템을 이용할 수 없다. 이 단계를 반드시 짚고 넘어가야 하는 이유는 바로 이 단계에서 실제 사용 환경에서 발생할 수 있는 예외 상황을 대비하는 것이 실제 개발 단계 혹은 배포 단계에서 새롭게 발생한 예외 상황에 대비하는 것보다 훨씬 효율적이기 때문이다. 분석 단계에서 잡아내지 못하면 기술 부채가 발생하고, 이는 기획 단계에서 발생한, 온전한 기획자의 잘못이다. ## Use Case Reviews 다음 단계는 유스케이스 전체를 점검하는 것이다. 유스케이스를 하나의 전체로 보았을 때, 이 유스케이스가 하나의 단위인가를 살펴볼 수 있다. 유스케이스의 단위는 걔좌 선택이나 비밀번호 입력처럼 단순 작업이 아닌, 현금 인출처럼 사용자의 입장에서 보았을 때 완전하고 비교적 짧은 시간 안에 수행할 수 있는 행위, 해당 유스케이스에 관여하는 주요 사용자가 한명이고 그 사용자가 시작하는 행위가 된다. 유스케이스를 테스트하는 가장 대표적인 방법은 EBP*Elementary Business Process* 테스트와 크기*Size* 테스트다. EBP는 한 사람이 어떤 시간에 한 장소에서 실행 가능한 비즈니스 활동을 의미하는데, 이를 테스트한다는 것은 곧 이 유스케이스가 사업적으로 의미가 있는지를 테스트한다는 뜻이다. 또다른 테스트인 크기 테스트는 유스케이스가 몇가지 단계로 이루어져 있는지를 보는데, 유스케이스가 하나의 단계만 있거나 하나의 행위만 있는 경우는 거의 없기 때문에 이를 검사하면서 유스케이스를 너무 작게 잡은 것은 아닌지 점검하는 것이다. ## Relationship 여기까지가 유스케이스를 설계하는 방법에 대한 모든 것이었다면, 이제부터는 유지보수를 위한 조직 방법이다.[^3] 유스케이스를 더 쉽게 이해하고 중복되는 부분을 지우며 유스케이스에 대한 문서를 더 쉽게 관리하기 위해 관계*Relationship*이라는 개념이 등장한다. 유스케이스 모델링에서의 관계는 유스케이스 간의 관계로, 유스케이스를 관리할 때는 유스케이스를 다른 유스케이스에 포함*include*시키거나 연장*extend*한다. ### Include Relationship 여러 유스케이스에서 똑같은 상황을 찾는 것은 그리 어려운 일이 아니다. 이러한 중복을 피하기 위해 공통 부분을 독립된 유스케이스로 덜어내고, 기존의 유스케이스들이 새로운 유스케이스를 포함하는 것으로 변경하는 것이 포함 관계*Include Relationship*다. ![[UseCaseIncludeRelationship.png]] ### Extend Relationship 연장 관계*Extend Relationship*는 기존의 유스케이스를 변경하지 않고도 기능을 추가하거나 변화를 주기 위한 기법이다. 기본적으로는 유스케이스에 조건부 연장을 부여하는 방식으로 이루어지며, 연장 기준은 기본 유스케이스에 레이블로 적힌다. ![[UseCaseExtendRelationship.png]] --- # 출처 - Larman, C. (2010) _Applying UML and patterns: an introduction to object oriented analysis and design and iterative development_. 3. ed., 13. print. Upper Saddle River, NJ: Prentice Hall PTR. [^1]: Larman, C. (2010) _Applying UML and patterns: an introduction to object oriented analysis and design and iterative development_. 3. ed., 13. print. Upper Saddle River, NJ: Prentice Hall PTR. p.63 [^2]: 소프트웨어나 시스템이 아무런 오류나 예외 상황 없이 원활하게 동작하는 이상적인 시나리오를 뜻하는 표현이다. 즉, 사용자가 기대한 대로, 계획한 대로 모든 것이 문제없이 진행되는 최상의 경우를 가리키며, 테스트나 시연 과정에서 자주 언급된다. [^3]: 그래서 처음부터 쓰면 오히려 유스케이스 분석을 해친다. 요구사항을 만드는 것은 유스케이스의 관리가 아니라 직접 쓰는 것이다.