유스 케이스

3. 유스케이스 구성 요소

액터는 시스템을 사용하는 외부 존재로, 사람, 시스템, 장치가 될 수 있다.^[10] 액터는 사용자가 인식 가능한 기능 단위이며, 유스 케이스 다이어그램과 UML 구성 요소의 일부로 표현된다.

요구 사항 분석에서 유스 케이스는 식별 시 기본 액터에 대해 나타내는 특정 사용자 목표에 따라 이름이 지정된다.^[1] 유스 케이스는 시스템이 액터와 상호 작용하여 수행하는 일련의 동작이며, 시스템 목표에 기여하는 관찰 가능한 결과를 생성한다. 액터는 인간 사용자 또는 다른 시스템이 상호 작용에서 갖는 역할을 나타낸다.

유스 케이스는 다음과 같은 종류와 변형이 있다.

• 시스템 유스 케이스: 개발될 시스템의 요구 사항을 명시한다.^[2] 액터와의 상호 작용뿐만 아니라 처리에 관련된 엔티티도 식별하며, 추가 분석 모델 및 설계 활동의 시작점이다.
• 비즈니스 유스 케이스: 소프트웨어 시스템 대신 비즈니스 조직에 초점을 맞춘다.^[5] 비즈니스 프로세스 재설계 이니셔티브의 맥락에서 비즈니스 모델 및 비즈니스 프로세스 요구 사항을 지정하는 데 사용된다.
• 필수 유스 케이스 (추상 유스 케이스): 시퀀스를 정의하거나 시나리오를 설명하지 않고, 액터의 잠재적 의도와 시스템이 이를 어떻게 다루는지를 설명한다.^[8] 사용자 중심 설계를 지원하고 시스템 사양 초기 단계에서 사용자 인터페이스에 대한 편견을 유발하지 않도록 하기 위해 개발되었다.^[7]
• 유스 케이스 2.0: 애자일 개발 방법의 맥락에 맞춰 기술을 적용한 것이다.^[1] 사용자 스토리 내러티브에 대한 지원을 통해 요구 사항 수집 관행을 풍부하게 하고, 요구 사항의 점진적 유도와 점진적 구현을 용이하게 하기 위해 유스 케이스 "슬라이스"를 제공한다.

• 주체는 상호 작용을 제공할 시스템, 하위 시스템 또는 구성 요소를 식별한다.
• 목표는 목표에 관심 있는 조직 수준(예: 회사, 부서, 사용자)과 사용자의 목표를 하위 목표로 분해하는 것을 고려하여 계층적으로 구조화될 수 있다.^[9]

• 특정 목표를 달성하기 위해 시스템을 액터가 어떻게 사용하는지를 묘사한다.
• 구현을 한정하는 듯한 단어를 사용하지 않는다.
• 적절한 수준의 상세함으로 묘사한다.
• 사용자 인터페이스나 표시 등의 세부 사항을 포함하지 않는다.

4. 유스케이스 모델링

이바 야콥슨은 1987년 OOPSLA'87 컨퍼런스에서 유스 케이스에 대한 첫 번째 논문을 발표했다.^[1] 1992년에는 객체 지향 소프트웨어 공학 시스템 공학 방법의 토대를 마련하고, 소프트웨어 개발에서 기능 요구 사항을 캡처하기 위해 유스 케이스를 대중화하는 데 기여한 책, ''객체 지향 소프트웨어 공학 - 유스 케이스 주도 접근 방식''을 공동 저술했다.^[4]

그레이디 부치와 제임스 럼바우는 객체 모델링 기법(OMT)이라는 객체 지향 분석 및 설계 방법을 통합하는 작업을 하였고, 1995년 이바 야콥슨이 그들과 합류하여 함께 통합 모델링 언어(UML)를 만들었으며, 여기에는 유스 케이스 모델링이 포함된다.^[6]

유스 케이스는 시스템의 요구 사항을 캡처, 모델링 및 명세하기 위한 기법이다.^[10] 유스 케이스는 시스템이 액터와 상호 작용하여 수행할 수 있는 일련의 동작에 해당하며, 이는 시스템의 목표에 기여하는 관찰 가능한 결과를 생성한다. 액터는 인간 사용자 또는 다른 시스템이 상호 작용에서 갖는 역할을 나타낸다.

요구 사항 분석에서 유스 케이스는 식별 시 기본 액터에 대해 나타내는 특정 사용자 목표에 따라 이름이 지정된다. 이 케이스는 일반적인 활동 및 이벤트의 시퀀스, 특수 조건, 예외 또는 오류 상황과 같은 변형을 설명하는 텍스트 설명 또는 추가 그래픽 모델로 추가적으로 상세화된다.

소프트웨어 공학 지식 체계(SWEBOK)에 따르면,^[16] 유스 케이스는 시나리오 기반 요구 사항 수집 기법뿐만 아니라 모델 기반 시스템 엔지니어링 분석 기법에도 속한다. 그러나 유스 케이스는 내러티브 기반 요구 사항 수집, 점진적 요구 사항 획득, 시스템 문서화 및 인수 테스트도 지원한다.^[1]

유스 케이스의 범위는 주체와 목표에 의해 정의될 수 있다.

• 주체는 상호 작용을 제공할 시스템, 하위 시스템 또는 구성 요소를 식별한다.^[17]
• 목표는 목표에 관심 있는 조직 수준(예: 회사, 부서, 사용자)과 사용자의 목표를 하위 목표로 분해하는 것을 고려하여 계층적으로 구조화될 수 있다.^[9] 목표의 분해는 사용자의 관점에서 수행되며, 시스템과 독립적으로 수행되는데, 이는 전통적인 기능적 분해와는 다릅니다.^[10]

• 특정 골을 달성하기 위해 시스템을 액터가 어떻게 사용하는지를 묘사한다.
• 구현을 한정하는 듯한 단어를 사용하지 않는다.
• 적절한 수준의 상세함으로 묘사한다.
• 사용자 인터페이스나 표시 등의 세부 사항을 포함하지 않는다. 이는 사용자 인터페이스 설계의 범주이다.

5. 유스케이스 작성 방법

유스 케이스는 사용자가 인식 가능한 기능 단위이며, 유스 케이스 다이어그램으로 나타낼 수 있는 UML의 구성 요소 중 하나이다. 유스 케이스를 텍스트로 작성하는 방법은 여러 가지가 있으며, 업계에서는 다양한 템플릿을 활용하여 기능적 시스템 요구 사항을 확보하는 것이 일반적인 관행이다.

앨리스테어 콕번의 《효과적인 유스 케이스 작성》에서 제시된 템플릿은 널리 사용되는 스타일 중 하나이다.

유스 케이스 작성 시 주의점은 다음과 같다.

• 특정 목표를 달성하기 위해 액터(사용자)가 시스템을 어떻게 사용하는지 묘사한다.
• 구현을 한정하는 단어를 사용하지 않는다.
• 적절한 수준의 상세함으로 묘사한다.
• 사용자 인터페이스나 표시 등의 세부 사항은 포함하지 않는다. (이는 사용자 인터페이스 설계의 영역이다.)

• 요약(brief) 유스 케이스: 몇 문장으로 요약한 것으로, 스프레드시트를 이용한 소프트웨어 개발 계획에 적합하다.
• 약식(casual) 유스 케이스: 요약 유스 케이스보다 자세하게 문장으로 나타낸 것이다.
• 상세 유스 케이스: 여러 절로 나뉜 템플릿에 따라 작성되는 정형 문서이다. 일반적으로 유스 케이스라고 하면 이를 지칭한다.

• 유스 케이스 명칭
• 버전
• 개요
• 사전 조건
• 트리거
• 기본 경로
• 대체 경로
• 사후 조건
• 비즈니스 규칙
• 주석
• 작성자 및 작성일

5. 1. 코번 스타일

범위	아이콘
조직 (블랙 박스)
조직 (화이트 박스)
시스템 (블랙 박스)
시스템 (화이트 박스)
컴포넌트

다른 저자들은 때때로 조직 수준의 유스 케이스를 "비즈니스 유스 케이스"라고 부르기도 한다.

콕번은 목표 레벨에 따라 다음과 같은 기호를 사용했다.

목표 레벨	아이콘
매우 높은 요약
요약
사용자 목표
하위 기능
너무 낮음

텍스트를 작성할 때 유스 케이스 이름 뒤에 대체 텍스트 기호(!, +, -, 등)를 붙이는 것이 레벨을 표시하는 더 간결하고 편리한 방법이 될 수 있다. 예를 들어, ''주문하기!'', ''로그인-'' 와 같이 사용할 수 있다.

콕번은 유스 케이스에 대한 보다 자세한 구조를 설명했지만, 세부 정보가 덜 필요할 때는 단순화하는 것을 허용한다. 그의 Fully Dressed 유스 케이스 템플릿은 다음과 같은 필드를 나열한다.^[23]

• 제목: "주요 액터의 목표를 명시하는 능동형 동사 구문"^[24]
• 주요 액터
• 컨텍스트 내 목표
• 범위
• 레벨
• 이해 관계자 및 관심사
• 사전 조건
• 최소 보장 사항
• 성공 보장 사항
• 트리거
• 주요 성공 시나리오
• 확장
• 기술 및 데이터 변형 목록

• 변형 시나리오 "(아마도 메인 시나리오에서 분기되거나 다시 돌아올 수 있음)"
• 예외 "즉, 예외 이벤트 및 해당 예외 처리 시나리오"

• 제목(목표)
• 주(主) 행위자
• 범위
• 레벨
• (스토리): 유스 케이스의 본문은 일어나는 일을 비공식적으로 설명하는 한두 단락의 텍스트이다.

• 제목: "유스 케이스가 만족시키려는 목표"^[26]
• 주요 성공 시나리오: 단계별 번호 목록^[26]
• 단계: "액터와 시스템 간의 상호 작용에 대한 간단한 설명"^[26]
• 확장: 각 확장에 대해 별도로 번호가 매겨진 목록^[26]
• 확장: "주요 성공 시나리오와 다른 상호 작용을 초래하는 조건". 주요 단계 3의 확장은 3a 등으로 번호가 매겨진다.^[26]

5. 2. 기타 템플릿

• 유스 케이스 명칭
• 버전
• 개요
• 사전 조건
• 트리거
• 기본 경로
• 대체 경로
• 사후 조건
• 비즈니스 규칙
• 주석
• 작성자 및 작성일

6. 유스케이스의 종류

유스 케이스에는 여러 종류와 변형이 존재한다.

• 시스템 유스 케이스는 개발될 시스템의 요구 사항을 명시한다.^[2] 시스템 유스 케이스는 액터와의 상호 작용뿐만 아니라 처리에 관련된 엔티티도 식별하며, 추가 분석 모델 및 설계 활동의 시작점이다.
• 비즈니스 유스 케이스는 소프트웨어 시스템 대신 비즈니스 조직에 초점을 맞춘다.^[5] 비즈니스 유스 케이스는 비즈니스 프로세스 재설계 이니셔티브의 맥락에서 비즈니스 모델 및 비즈니스 프로세스 요구 사항을 지정하는 데 사용된다.
• 필수 유스 케이스(추상 유스 케이스)는 시퀀스를 정의하거나 시나리오를 설명하지 않고, 액터의 잠재적 의도와 시스템이 이를 어떻게 다루는지를 설명한다.^[8] 이 방식은 사용자 중심 설계를 지원하고 시스템 사양 초기 단계에서 사용자 인터페이스에 대한 편견을 유발하지 않도록 하기 위해 개발되었다.^[7]
• 유스 케이스 2.0은 애자일 개발 방법의 맥락에 맞춰 기술을 적용한 것이다.^[1] 이 기술은 사용자 스토리 내러티브에 대한 지원을 통해 요구 사항 수집 관행을 풍부하게 한다. 또한 요구 사항의 점진적 유도와 점진적 구현을 용이하게 하기 위해 유스 케이스 "슬라이스"를 제공한다.

7. 유스케이스 활용 분야

유스 케이스는 다음과 같은 분야에서 활용되는 것으로 알려져 있다.

• 객체 지향 소프트웨어 공학(OOSE)의 추진 요소^[4]
• 통합 모델링 언어(UML)의 행동 모델링 도구^[17]
• 통합 소프트웨어 개발 프로세스(UP) 및 그 전신인 IBM Rational Unified Process(RUP)^[7]
• 소프트웨어 요구사항 명세(SRS)의 사전 문서화, 기능 요구사항의 대체 구조^[18]
• 개체-제어-경계 접근 방식을 사용하여 요구사항으로부터 설계를 도출^[7]
• 애자일 개발^[1][19]

8. 장점

유스 케이스는 사용자 중심의 소프트웨어 요구 사항 명세에 유용한 도구이다.^[33] 유스 케이스 모델링은 시스템과 상호작용하는 주요 이해 관계자 역할(''액터'')과 시스템이 달성해야 하는 목표를 식별하는 것에서 시작한다. 이러한 사용자 중심 접근 방식은 실제 비즈니스 가치가 있고 사용자가 원하는 것을 개발하도록 돕는다.

유스 케이스는 구조화된 템플릿을 사용하여 자연어로 작성되므로, 고객, 최종 사용자, 개발자, 테스터 및 관리자를 포함한 모든 이해 관계자 간의 의사 소통을 향상시킨다.^[33] 이는 더 나은 품질의 요구 사항과 시스템으로 이어진다.

유스 케이스 템플릿은 주요 성공 시나리오(기본 흐름) 및 확장 시나리오(확장, 예외, 대체 흐름)를 분석하여 요구 사항을 체계적으로 파악하도록 돕는다.^[33] 사용자 목표 달성을 위해 유스 케이스의 액션 단계를 최소화하고 최적화하면 더 나은 상호 작용 디자인 및 사용자 경험에 기여한다.

잘 작성된 유스 케이스 모델은 시스템 테스트 케이스 및 사용자 매뉴얼 설계를 위한 훌륭한 기반을 제공한다.^[34] 유스 케이스의 흐름 경로와 해당 테스트 케이스 간에는 명확한 연결이 있으며, 시나리오를 통해 유스 케이스에서 기능 테스트 케이스를 도출하는 것은 간단하다.

앨리스테어 코크번은 애자일 개발에서 유스 케이스를 작성하는 다섯 가지 이유를 다음과 같이 나열한다.^[32]

• 목표 이름 목록은 시스템이 제공할 내용에 대한 간결한 요약을 제공하며, 프로젝트 계획의 골격을 제공한다.
• 각 유스 케이스의 주요 성공 시나리오는 모든 관련 당사자 간의 합의를 제공하고, 각 요구 사항에 대한 컨텍스트를 제공한다.
• 각 유스 케이스의 확장 조건은 개발 시간과 예산에 큰 영향을 미치는 문제들을 사전에 파악하도록 돕는다.
• 유스 케이스 확장 시나리오 조각은 비즈니스 질문에 대한 답변을 제공하며, 프로그래머가 문제를 생각하는 데 도움을 준다.
• 전체 유스 케이스 세트는 모든 사용자의 요구 사항, 목표 및 비즈니스 변형을 고려했음을 보여준다.

9. 한계

• 유스 케이스는 시스템의 비상호 작용 기반 요구사항(예: 알고리즘 또는 수학적 요구사항) 또는 비기능적 요구사항(예: 플랫폼, 성능, 타이밍 또는 안전 관련 측면)을 캡처하는 데 적합하지 않다. 이러한 사항은 다른 곳에서 선언적으로 지정하는 것이 좋다.
• 유스 케이스에 대한 완전한 표준 정의가 없으므로, 각 프로젝트는 자체적인 해석을 형성해야 한다.^[35]
• '확장'과 같은 일부 유스 케이스 관계는 해석이 모호하며 이해 관계자가 이해하기 어려울 수 있다.^[35]
• 유스 케이스 개발자는 유스 케이스에 통합할 사용자 인터페이스(UI) 종속성의 수준을 결정하는 데 어려움을 겪는 경우가 많다. 유스 케이스 이론은 UI가 유스 케이스에 반영되지 않아야 한다고 제안하지만, 설계를 이러한 측면에서 추상화하는 것은 유스 케이스를 시각화하기 어렵게 만들므로 어색할 수 있다. 소프트웨어 엔지니어링에서 이러한 어려움은 요구사항 추적성을 적용하여 해결된다. 예를 들어 추적성 행렬을 사용하는 것이다. UI 요소를 유스 케이스와 연결하는 또 다른 방법은 유스 케이스의 각 단계에 UI 디자인을 첨부하는 것이다. 이를 유스 케이스 스토리보드라고 한다.
• 유스 케이스는 과도하게 강조될 수 있다. 베르트랑 메이어는 유스 케이스에서 시스템 설계를 너무 문자 그대로 이끌어가는 문제, 그리고 다른 잠재적으로 가치 있는 요구사항 분석 기법을 배제하고 유스 케이스를 사용하는 문제 등을 논의한다.^[36]
• 유스 케이스는 테스트 설계를 위한 시작점이지만,^[37] 각 테스트에는 자체 성공 기준이 필요하므로 각 경로에 대한 별도의 사후 조건을 제공하기 위해 유스 케이스를 수정해야 할 수 있다.^[38]
• 유스 케이스는 목표와 맥락을 포함하지만, 이러한 목표와 목표 뒤에 숨겨진 동기(이해 관계자의 관심사 및 비상호 작용을 포함한 평가)가 다른 시스템 목표와 충돌하거나 부정적/긍정적으로 영향을 미치는지 여부는 BMM, I*, KAOS 및 ArchiMate ARMOR와 같은 목표 지향적 요구사항 모델링 기법의 대상이다.
• 유스 케이스는 시스템 관련 기능 이외의 요구 사항을 파악하는 데 적합하지 않다.
• 유스 케이스 템플릿은 명확성을 자동으로 보장할 수 없다. 명확성은 작성자의 기량에 달려 있다.
• 정확성이 중요한 미션 크리티컬 시스템이나 실시간 시스템에는 적합하지 않다.
• 최종 사용자 및 프로그래머에 대해 유스 케이스를 올바르게 이해하는 데 학습 곡선이 존재한다. 표준화된 정의가 없기 때문에 이해는 점차 깊어질 수밖에 없다.
• 익스트림 프로그래밍에서는 유스 케이스가 불필요하게 문서적이라고 여기며, 오히려 더 단순한 사용자 스토리라는 방법을 선호한다.
• 유스 케이스를 작성할 때, 사용자 인터페이스에 의존하는 수준을 어떻게 해야 할지에 대해 고민하는 경우가 있다. 이론적으로 유스 케이스는 어떠한 사용자 인터페이스도 전제로 하지 않지만, 어떤 인터페이스를 전제로 하지 않으면 유스 케이스를 시각화할 수 없다.
• 유스 케이스는 플랫폼의 요구 사양 기술에 적합하지 않다. 유스 케이스는 구현해야 할 하나의 시스템을 상정하고 있지만, 플랫폼(하드웨어 및 운영 체제)은 그 위에서 여러 시스템이 동작한다.
• 유스 케이스는 지나치게 강조되는 경향이 있다. ''객체 지향 소프트웨어 구축''(제2판)에서 베르트랑 메이어는 유스 케이스에 충실하게 시스템을 설계하다가 다른 유용한 요구 사항 분석 기법을 배제해 버리는 문제를 논하고 있다.

10. 오해

유스 케이스와 관련하여 다음과 같은 일반적인 오해가 있다.

• '''사용자 스토리는 애자일(Agile)하고 유스 케이스는 그렇지 않다.'''

• '''유스 케이스는 주로 다이어그램이다.'''

• '''유스 케이스는 UI 관련 내용이 너무 많다.'''

• '''대규모 시스템의 유스 케이스를 작성하는 것은 지루하고 시간 낭비이다.'''

참조

_[1] 웹사이트 Use-Case 2.0 ebook https://www.ivarjaco[...] 2020-08-09
_[2] 학술지 Object-oriented development in an industrial environment http://portal.acm.or[...] 1987-12-01
_[3] 웹사이트 Use cases, ten years later http://alistair.cock[...] Alistair Cockburn 2013-04-17
_[4] 서적 Object-oriented software engineering: a use case driven approach ACM Press
_[5] 서적 The object advantage : business process reengineering with object technology Addison-Wesley 1995
_[6] 웹사이트 About the Unified Modeling Language Specification Version 2.5.1 https://www.omg.org/[...] 2020-08-09
_[7] 서적 The unified software development process Addison-Wesley 1999
_[8] 학술지 Essential modeling: use cases for user interfaces http://portal.acm.or[...] 1995-04-01
_[9] 서적 Writing effective use cases https://www.academia[...] Addison-Wesley 2001
_[10] 서적 Use case modeling Addison Wesley 2003
_[11] 서적 Managing software requirements : a use case approach Addison-Wesley 2003
_[12] 서적 Use cases : patterns and blueprints Addison-Wesley 2005
_[13] 웹사이트 Use Case 2.0: The Guide to Succeeding with Use Cases http://www.ivarjacob[...] Ivar Jacobson International 2014-05-05
_[14] 웹사이트 Business Analysis Conference Europe 2011 - 26-28 September 2011, London, UK http://www.irmuk.co.[...] Irmuk.co.uk 2013-04-17
_[15] 웹사이트 Use-Case 2.0 Presentation https://www.ivarjaco[...] 2020-08-09
_[16] 서적 SWEBOK: guide to the software engineering body of knowledge IEEE Computer Society
_[17] 웹사이트 Unified Modeling Language Specification Version 2.5.1 https://www.omg.org/[...] 2020-08-16
_[18] 서적 More about software requirements: thorny issues and practical advice Microsoft Press 2010
_[19] 웹사이트 System Use Cases: An Agile Introduction http://agilemodeling[...] 2020-08-16
_[20] 문서 Cockburn, 2001. Inside front cover. Icons "Design Scope".
_[21] 문서 Suzanne Robertson. Scenarios in Requirements Discovery. Chapter 3 in Alexander and Maiden, 2004. Pages 39-59.
_[22] 문서 Cockburn, 2001. Inside front cover. Icons "Goal Level".
_[23] 문서 Cockburn, 2001. Page 120.
_[24] 문서 Cockburn, 2001. Inside rear cover. Field "Use Case Title".
_[25] 문서 Alexander and Beus-Dukic, 2009. Page 121
_[26] 문서 Fowler, 2004.
_[27] 웹사이트 User Story And Use Case Comparison http://wiki.c2.com/?[...] 2024-01-19
_[28] 문서 Cockburn, 2001. Page 53.
_[29] 문서 Cockburn, 2001. Page 55.
_[30] 문서 Alexander and Beus-Dukic, 2009. Page 39.
_[31] 서적 Business Modeling with UML https://archive.org/[...] Wiley Computer Publishing
_[32] 웹사이트 Why I still use cases http://alistair.cock[...] 2008-01-09
_[33] 웹사이트 Listening to the Customer's Voice http://www.processim[...] Software Development 1997-03
_[34] 웹사이트 Traceability from Use Cases to Test Cases http://www.ibm.com/d[...] IBM developerWorks 2006-05
_[35] 웹사이트 Alistair.Cockburn.us - Structuring use cases with goals http://alistair.cock[...] 2018-03-16
_[36] 문헌 Meyer
_[37] 문헌 Armour and Miller
_[38] 문헌 Denney
_[39] 웹사이트 The Scrum Primer: A Lightweight Guide to the Theory and Practice of Scrum (Version 2.0) http://www.infoq.com[...] InfoQ 2012-12-17
_[40] 서적 Applying UML and patterns Prentice Hall
_[41] 웹사이트 Use cases, ten years later - AC http://alistair.cock[...]