유스 케이스

위키 시스템의 매우 단순한 유스 케이스 다이어그램. 위키의 등록된 사용자가 문서를 편집한다.

소프트웨어 및 시스템 공학 모두에서 유스 케이스(use case)는 특정 목표를 달성하기 위해 외부 액터의 요청에 응답하는 시스템 동작에 대한 구조화된 설명이다. 이 용어는 소프트웨어/시스템 공학 이외의 분야에서 사물이 어떻게 사용될 수 있는지 설명하는 데에도 사용된다.

소프트웨어(및 소프트웨어 기반 시스템) 공학에서 유스 케이스는 기능적 요구사항을 정의하고 검증하는 데 사용된다. 유스 케이스는 일반적으로 목표를 달성하기 위해 역할(통합 모델링 언어(UML)에서는 액터라고 함)과 시스템 간의 상호작용을 정의하는 일련의 활동 또는 이벤트 단계의 목록이다. 액터는 사람일 수도 있고 다른 외부 시스템일 수도 있다. 시스템 공학에서 유스 케이스는 소프트웨어 공학보다 더 높은 수준에서 사용되며, 종종 미션이나 이해관계자의 목표를 나타낸다. 상세 요구사항은 시스템 모델링 언어(SysML)나 계약서의 형태로 캡처될 수 있다.

시스템 공학과 소프트웨어 공학 유스 케이스의 차이점

소프트웨어 공학에서 유스 케이스는 외부 요청(사용자 입력 등)에 응답하는 소프트웨어의 잠재적 시나리오를 정의한다. 시스템 공학에서 유스 케이스는 기술적 구성 요소와 인간 구성 요소 전반에 걸친 상위 수준의 기능적 동작을 모델링한다.

정의

소프트웨어 및 시스템 공학에서 유스 케이스라는 문구는 두 가지 의미를 가진 다의어이다.

1. 소프트웨어의 사용 시나리오. 소프트웨어가 유용하게 쓰일 수 있는 상황을 제안하기 위해 복수형으로 자주 사용된다.
2. 시스템이 외부 요청(사용자 입력 등)을 받고 그에 응답하는 잠재적인 시나리오.

이 문서는 후자의 의미를 다룬다. (다른 의미에 대한 자세한 내용은 페르소나 (사용자 경험) 문서를 참고하라.)

역사

1987년, 이바르 야콥슨은 OOPSLA'87 컨퍼런스에서 유스 케이스에 관한 첫 번째 논문을 발표했다. 그는 객체 지향 분석 및 설계를 추진하기 위해 텍스트, 구조 및 시각적 모델링 기법을 사용하여 시스템의 요구사항을 캡처하고 명세하기 위해 에릭슨에서 이 기법이 어떻게 사용되었는지 설명했다. 원래 그는 usage scenarios와 usage case라는 용어를 사용했는데, 후자는 스웨덴어 용어인 användningsfall을 직역한 것이었다. 하지만 그는 이 용어들이 영어에서 자연스럽게 들리지 않는다는 것을 발견하고 결국 use case로 결정했다.

1992년 그는 "Object-Oriented Software Engineering - A Use Case Driven Approach"라는 책을 공동 집필했다. 이 책은 OOSE 시스템 공학 방법론의 토대를 마련했으며, 특히 소프트웨어 개발에서 기능적 요구사항을 캡처하는 데 유스 케이스를 대중화하는 데 기여했다. 1994년에 그는 사업 모형과 업무 재설계에 적용된 유스 케이스 및 객체 지향 기술에 관한 책을 출판했다.

같은 시기에 그래디 부치와 제임스 럼버는 각각의 객체 지향 분석 및 설계 방법론인 부치 방법론과 객체 모델링 기술(OMT)을 통합하는 작업을 수행했다. 1995년 이바르 야콥슨이 합류하여 함께 유스 케이스 모델링을 포함하는 통합 모델링 언어(UML)를 만들었다. UML은 1997년에 OMG에 의해 표준화되었다. 야콥슨, 부치, 럼버는 또한 Objectory 소프트웨어 개발 프로세스의 개선 작업도 진행했다. 그 결과로 탄생한 통합 프로세스는 1999년에 출판되었으며 유스 케이스 기반 접근 방식을 장려했다.

그 이후로 많은 저자가 이 기술의 발전에 기여했다. 특히 래리 콘스탄틴은 1995년 사용자 중심 설계의 맥락에서, 사용자 인터페이스 설계를 제약하거나 편향시킬 수 있는 일련의 동작이나 시나리오보다는 사용자의 의도를 설명하는 것을 목표로 하는 소위 "본질적 유스 케이스"(essential use-cases)를 개발했다. 알리스테어 콕번은 2000년에 텍스트 서사와 표 형식의 명세를 기반으로 한 목표 지향적 유스 케이스 실무를 발표했다. 커트 비트너와 이언 스펜스는 2002년에 유스 케이스를 사용하여 기능적 요구사항을 분석하기 위한 고급 실무를 개발했다. 딘 레핑웰과 돈 위드릭은 유스 케이스를 변경 관리 및 이해관계자 커뮤니케이션 활동에 적용할 것을 제안했다. 군나르 오버가드는 2004년에 디자인 패턴의 원리를 유스 케이스로 확장할 것을 제안했다.

2011년 야콥슨은 이언 스펜스, 커트 비트너와 함께 이 기술을 애자일 환경에 맞게 조정하고, 점진적인 유스 케이스 "슬라이스"(slices)로 보강하며, 전체 개발 수명 주기 전반에 걸친 사용을 장려하기 위해 "Use Case 2.0" 전자책을 출판했다. 이는 연례 IIBA 컨퍼런스에서 갱신된 접근 방식을 발표한 이후였다.

일반 원칙

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

요구사항 분석 단계에서 유스 케이스는 주요 액터에게 나타내는 특정 사용자 목표에 따라 명명된다. 유스 케이스는 활동과 이벤트의 일반적인 순서뿐만 아니라 특별 조건, 예외 또는 오류 상황과 같은 변형을 설명하는 텍스트 설명이나 추가적인 그래픽 모델을 통해 더 상세해진다.

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

변형

유스 케이스의 종류와 기법에는 여러 가지 변형이 있다.

• 시스템 유스 케이스는 개발될 시스템의 요구사항을 명세한다. 상세 설명에서 액터와의 상호작용뿐만 아니라 처리에 관여하는 엔티티도 식별한다. 이는 추가 분석 모델 및 설계 활동의 시작점이 된다.
• 비즈니스 유스 케이스는 소프트웨어 시스템 대신 비즈니스 조직에 초점을 맞춘다. 업무 재설계 이니셔티브의 맥락에서 사업 모형 및 비즈니스 프로세스 요구사항을 명세하는 데 사용된다.
• 추상 유스 케이스라고도 불리는 본질적 유스 케이스는 일련의 순서를 정의하거나 시나리오를 설명하지 않고 액터의 잠재적 의도와 시스템이 이를 처리하는 방식을 설명한다. 이 방식은 사용자 중심 설계를 지원하고 시스템 명세 초기 단계에서 사용자 인터페이스에 대한 편향을 유도하지 않기 위해 개발되었다.
• Use Case 2.0은 애자일 개발 방법론의 맥락에 맞게 기법을 조정한 것이다. 이 기법은 요구사항 수집 실무에 유저 스토리 서사 지원을 보강한다. 또한 요구사항의 점진적 도출을 용이하게 하고 점진적 구현을 가능하게 하는 유스 케이스 "슬라이스"를 제공한다.

범위

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

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

사용처

유스 케이스는 다음과 같은 맥락에서 적용되는 것으로 알려져 있다.

• 주동적인 요소로서의 객체 지향 소프트웨어 공학(OOSE);
• 동작 모델링 도구로서의 통합 모델링 언어(UML);
• 통합 소프트웨어 개발 프로세스(UP) 및 그 전신인 IBM 래셔널 통합 프로세스(RUP);
• 기능적 요구사항의 대안적 구조로서의 소프트웨어 요구 명세(SRS)의 선행 문서화;
• entity–control–boundary 접근 방식을 사용하여 요구사항으로부터 설계를 도출;
• 그리고 애자일 개발.

템플릿

텍스트로 유스 케이스를 작성하는 방법은 요약형, 일반형, 개요형부터 완전형 등 다양하며 템플릿도 여러 가지이다. 다양한 벤더나 전문가들이 고안한 템플릿에 유스 케이스를 작성하는 것은 고품질의 기능적 시스템 요구사항을 얻기 위한 일반적인 업계 관행이다.

콕번 스타일

알리스테어 콕번이 그의 저서 "Writing Effective Use Cases"에서 정의한 템플릿은 가장 널리 사용되는 유스 케이스 작성 스타일 중 하나이다.

설계 범위

콕번은 각 유스 케이스에 "설계 범위"(Design Scope)를 나타내는 기호를 표시할 것을 제안한다. 이는 블랙박스(내부 세부 사항이 숨겨짐) 또는 화이트박스(내부 세부 사항이 표시됨)일 수 있다. 다섯 가지 기호를 사용할 수 있다.

범위	아이콘
조직 (블랙박스)	채워진 집
조직 (화이트박스)	비어있는 집	Scope-icons-unfilled-house
시스템 (블랙박스)	채워진 상자	Scope-icons-filled-box
시스템 (화이트박스)	비어있는 상자	Scope-icons-unfilled-box
구성 요소	나사 또는 볼트	Scope-icons-screw-bolt

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

목표 수준

목표 수준의 계층 구조

콕번은 "목표 수준"(Goal Level)을 표시하기 위해 각 유스 케이스에 기호를 추가할 것을 제안한다. 선호되는 수준은 "사용자 목표"(User-goal, 또는 구어로 "해수면")이다.

목표 수준	아이콘	기호
매우 높은 요약	구름	++
요약	날아가는 연	+
사용자 목표	바다의 파도	!
하위 기능	물고기	-
너무 낮음	해저 조개껍데기	--

때로는 텍스트 작성 시 유스 케이스 이름 뒤에 대체 텍스트 기호(!, +, - 등)를 붙이는 것이 수준을 나타내는 데 더 간결하고 편리한 방법이다(예: 주문하기!, 로그인-).

완전형

콕번은 유스 케이스에 대해 더 상세한 구조를 설명하지만, 세부 사항이 덜 필요할 때는 이를 단순화할 수 있도록 허용한다. 그의 완전형(fully dressed) 유스 케이스 템플릿에는 다음과 같은 필드들이 나열되어 있다.

• 제목: "주요 액터의 목표를 명명하는 능동 동사 목표 구문"
• 주요 액터
• 문맥상의 목표
• 범위
• 수준
• 이해관계자 및 관심사
• 사전 조건
• 최소 보장
• 성공 보장
• 트리거
• 기본 성공 시나리오
• 확장
• 기술 및 데이터 변형 목록

또한 콕번은 각 유스 케이스의 성격을 나타내기 위해 설계 범위와 목표 수준에 대한 아이콘을 사용할 것을 제안한다.

콕번의 접근 방식은 다른 저자들에게도 영향을 미쳤다. 예를 들어, 알렉산더와 베우스-듀키치는 콕번의 "완전형 유스 케이스" 템플릿을 소프트웨어에서 모든 종류의 시스템으로 일반화했으며, 콕번과 다른 다음과 같은 필드들을 포함했다.

• 변형 시나리오 "(기본 시나리오에서 분기하거나 다시 돌아올 수 있음)"
• 예외 "즉, 예외 이벤트 및 그에 따른 예외 처리 시나리오"

일반형

콕번은 프로젝트에서 항상 상세한 "완전형" 유스 케이스가 필요한 것은 아니라는 점을 인정한다. 그는 다음과 같은 필드를 가진 일반형(Casual) 유스 케이스를 설명한다.

• 제목 (목표)
• 주요 액터
• 범위
• 수준
• (이야기): 유스 케이스의 본문은 단순히 한두 단락의 텍스트로, 일어나는 일을 비형식적으로 설명한다.

파울러 스타일

마틴 파울러는 "유스 케이스의 내용을 작성하는 표준화된 방법은 없으며, 상황에 따라 서로 다른 형식이 잘 작동한다"고 말한다. 그는 "자주 사용되는 일반적인 스타일"을 다음과 같이 설명한다.

• 제목: "유스 케이스가 충족시키려는 목표"
• 기본 성공 시나리오: 번호가 매겨진 단계 목록
  • 단계: "액터와 시스템 간의 상호작용에 대한 단순한 문장"
• 확장: 별도로 번호가 매겨진 목록, 확장당 하나씩
  • 확장: "기본 성공 시나리오와는 다른 상호작용을 초래하는 조건". 기본 3단계에서의 확장은 3a 등으로 번호가 매겨진다.

파울러 스타일은 콕번 템플릿의 단순화된 변형으로 볼 수도 있다. 이 변형은 유저 스토리라고 불린다.

알리스테어 콕번은 다음과 같이 말했다.

유저 스토리를 2비트 정밀도의 유스 케이스라고 생각하라. 정밀도의 1비트는 유스 케이스의 목표를 명명하고, 2비트는 주요 시나리오를 추가한다. 3비트는 실패 조건을 추가하고, 4비트는 실패 동작을 추가한다. 5비트는 입출력 데이터에 대한 데이터 설명을 추가한다. 카탈리시스(Catalysis)는 메시지 수신자의 모델도 포함하므로 6비트 정밀도라고 할 수 있다. Crystal 방법론 제품군에서는 서로 다르게 설립된 프로젝트들이 서로 다른 정밀도 수준의 유스 케이스를 사용한다. 방법론적으로 가벼운 프로젝트는 유저 스토리를 사용하고, 방법론적으로 더 무거운 프로젝트는 4비트 정밀도의 유스 케이스를 사용하며, 카탈리시스는 6비트 정밀도를 사용한다.

마틴 파울러는 다음과 같이 말했다.

핵심은 사람들이 유스 케이스를 어떻게 사용하느냐에 달려 있다. 나는 많은 사람들이 유스 케이스를 매우 형식적인 방식으로 사용하는 것을 보았다. 켄트(Kent)는 그의 유저 스토리를 훨씬 더 접근하기 쉬운 방식으로 수행한다. 나는 켄트가 유저 스토리를 하는 방식으로 유스 케이스를 작성한다. 다른 개발자들과 더 잘 소통하고 그들이 더 가벼운 접근 방식을 사용하도록 유도하기 위해 이를 유스 케이스라고 부른다.

액터

 이 부분의 본문은 액터 (UML)입니다.

유스 케이스는 목표를 달성하기 위해 외부 액터와 고려 중인 시스템 간의 상호작용을 정의한다. 액터는 의사결정을 내릴 수 있어야 하지만, 반드시 인간일 필요는 없다. "액터는 사람, 회사나 조직, 컴퓨터 프로그램, 또는 하드웨어, 소프트웨어 혹은 둘 다인 컴퓨터 시스템일 수 있다." 액터는 항상 이해관계자이지만, 모든 이해관계자가 액터인 것은 아니다. 왜냐하면 그들은 "시스템이 어떻게 동작하는지 관심을 가질 권리가 있더라도 시스템과 직접 상호작용하지 않을 수도 있기 때문이다." 예를 들어, "시스템의 소유자, 회사의 이사회, 국세청이나 보험국과 같은 규제 기관"은 모두 이해관계자일 수 있지만 액터일 가능성은 낮다.

마찬가지로 시스템을 사용하는 한 개인은 서로 다른 역할을 수행하기 때문에 서로 다른 액터로 표현될 수 있다. 예를 들어, 사용자 "Joe"가 자신의 계좌에서 현금을 인출하기 위해 자동 현금 입출금기를 사용할 때는 '고객' 역할을 수행할 수 있고, 은행을 대신하여 현금 서랍을 채우기 위해 시스템을 사용할 때는 '은행원' 역할을 수행할 수 있다.

액터는 종종 다른 누군가를 대신하여 작업한다. 콕번은 "요즘 나는 시스템 사용자가 다른 누군가를 위해 행동하고 있음을 포착하기 위해 '고객을 위한 영업 담당자' 또는 '마케팅 부서를 위한 서기'라고 쓴다"고 기술했다. 이는 프로젝트 팀에게 "사용자 인터페이스와 보안 승인"은 영업 담당자와 서기를 위해 설계되어야 하지만, 고객과 마케팅 부서가 결과에 관심을 갖는 역할임을 알려준다.

이해관계자는 능동적인 역할과 수동적인 역할을 모두 수행할 수 있다. 예를 들어, 소비자는 (시스템과 상호작용하지 않는) "대중 시장 구매자"인 동시에 (구매한 제품과 능동적으로 상호작용하는 액터인) "사용자"이기도 하다. 결국 사용자는 (의도된 목적으로 시스템을 사용하는 액터인) "일반 운영자"인 동시에 (시스템 사용으로 혜택을 받는 이해관계자인) "기능적 수혜자"이기도 하다. 예를 들어, 사용자 "Joe"가 자신의 계좌에서 현금을 인출할 때, 그는 자동 현금 입출금기를 운영하는 동시에 자신을 위해 결과를 얻는 것이다.

콕번은 시스템의 이해관계자, 유스 케이스의 주요 및 보조 액터, 설계 대상 시스템(SuD) 자체, 그리고 마지막으로 설계 대상 시스템의 구성 요소인 "내부 액터" 중에서 액터를 찾아볼 것을 권장한다.

비즈니스 유스 케이스

유스 케이스가 가치 있는 결과(목표)를 생성하기 위해 사용자(또는 다른 유형의 액터)와 시스템 간의 일련의 이벤트 및 상호작용을 설명하는 것과 같은 방식으로, 비즈니스 유스 케이스는 가치 있는 비즈니스 결과를 생성하기 위해 비즈니스 시스템과 해당 시스템의 사용자/액터 간의 더 일반적인 상호작용을 설명한다. 주요 차이점은 비즈니스 유스 케이스 모델에서 고려되는 시스템이 기술적 시스템 외에도 사람을 포함할 수 있다는 점이다. 이러한 "시스템 내의 사람들"을 비즈니스 작업자(business workers)라고 부른다. 레스토랑의 예에서 각 사람을 액터(따라서 시스템 외부)로 취급할지 아니면 비즈니스 작업자(시스템 내부)로 취급할지 결정해야 한다. 아래 예시와 같이 웨이터를 액터로 간주한다면 레스토랑 시스템에는 웨이터가 포함되지 않으며, 모델은 웨이터와 레스토랑 간의 상호작용을 노출한다. 대안으로는 웨이터를 레스토랑 시스템의 일부(비즈니스 작업자)로 간주하면서 고객을 시스템 외부(액터)로 간주하는 것이 있다.

비즈니스 유스 케이스 다이어그램은 레스토랑(비즈니스 시스템)과 주요 이해관계자(비즈니스 액터 및 비즈니스 작업자) 간의 상호작용을 나타내는 여러 비즈니스 유스 케이스(목표) 모델을 묘사한다.

시각적 모델링

유스 케이스는 텍스트일 뿐만 아니라 필요한 경우 다이어그램이기도 하다. 통합 모델링 언어에서 유스 케이스와 액터 간의 관계는 원래 이바르 야콥슨의 Objectory 표기법을 기반으로 한 유스 케이스 다이어그램으로 표현된다. SysML은 시스템 블록 수준에서 동일한 표기법을 사용한다.

또한 활동 다이어그램, 시퀀스 다이어그램, 통신 다이어그램 및 상태 머신 다이어그램과 같은 다른 동작 UML 다이어그램도 유스 케이스를 시각화하는 데 사용될 수 있다. 구체적으로, 시스템 시퀀스 다이어그램(SSD)은 외부 액터와 설계 대상 시스템(SuD) 간의 상호작용을 보여주기 위해 자주 사용되는 시퀀스 다이어그램으로, 보통 유스 케이스의 특정 시나리오를 시각화하는 데 쓰인다.

유스 케이스 분석은 보통 유스 케이스 다이어그램을 그리는 것으로 시작된다. 애자일 개발의 경우, 유스 케이스를 묘사하는 많은 UML 다이어그램에 약간의 텍스트 설명, 노트 또는 유스 케이스 요약을 더한 요구사항 모델은 매우 가벼우며 소규모나 쉬운 프로젝트에 충분할 것이다. 유스 케이스 텍스트의 좋은 보완책으로서, 유스 케이스의 시각적 다이어그램 표현은 복잡한 시스템 동작 요구사항에 대한 더 나은 이해, 커뮤니케이션 및 설계를 촉진하는 효과적인 도구이기도 하다.

예시

아래는 콕번 스타일 템플릿의 약간 변형된 버전으로 작성된 샘플 유스 케이스이다. 기본 유스 케이스 설명에는 버튼, 컨트롤, 폼 또는 기타 UI 요소와 조작이 없으며, 기본 흐름이나 확장의 모든 단계에서 사용자 목표, 하위 목표 또는 의도만이 표현되어 있음에 유의하라. 이러한 관행은 요구 명세를 더 명확하게 만들고 설계 및 구현의 유연성을 극대화한다.

유스 케이스: 문서 편집하기

주요 액터: 회원 (등록된 사용자)

범위: 위키 시스템

수준: ! (사용자 목표 또는 해수면)

요약: (유저 스토리 또는 에픽과 동일)

회원은 자신이 읽고 있는 문서의 어느 부분(문서 전체 또는 특정 섹션)이든 편집한다. 편집 중에 미리보기 및 변경 사항 비교가 허용된다.

이해관계자

...

사후 조건

최소 보장:

성공 보장:

• 문서가 저장되고 업데이트된 뷰가 표시된다.
• 시스템에 의해 문서 편집 기록이 생성되어, 나중에 해당 문서의 주시자들이 업데이트 소식을 알 수 있게 된다.

사전 조건:

편집 기능이 활성화된 문서가 회원에게 표시된다.

트리거:

회원이 문서에 대해 (전체 문서 또는 한 섹션에 대한) 편집 요청을 호출한다.

기본 흐름:

1. 시스템은 회원이 편집할 수 있도록 문서의 모든 관련 내용이 채워진 새 편집기 영역/상자와 정보가 담긴 편집 요약을 제공한다. 회원이 보고서의 한 섹션만 편집하려는 경우 해당 섹션의 원래 내용만 표시되며, 섹션 제목이 편집 요약에 자동으로 채워진다.
2. 회원은 만족할 때까지 문서의 내용을 수정한다.
3. 회원은 편집 요약을 작성하고, 이 문서를 주시할지 여부를 시스템에 알린 후 편집 내용을 제출한다.
4. 시스템은 문서를 저장하고 편집 이벤트를 기록하며 필요한 후처리를 마무리한다.
5. 시스템은 업데이트된 문서 뷰를 회원에게 보여준다.

확장:

2–3.

a. 미리보기 표시:

1. 회원이 수정한 내용을 제출하는 '미리보기 표시'를 선택한다.
2. 시스템은 렌더링된 업데이트된 내용을 미리보기 위해 추가하여 1단계를 다시 실행하고, 회원에게 편집 내용이 아직 저장되지 않았음을 알린 후 계속한다.

b. 차이 표시:

1. 회원이 수정한 내용을 제출하는 '차이 표시'를 선택한다.
2. 시스템은 회원의 현재 편집 내용과 가장 최근에 저장된 문서 버전 간의 차이를 비교한 결과를 보여주는 내용을 추가하여 1단계를 다시 실행한 후 계속한다.

c. 편집 취소:

1. 회원이 '취소'를 선택한다.
2. 시스템은 회원이 변경한 모든 내용을 폐기하고 5단계로 이동한다.

4a. 타임아웃:

...

장점

애자일 운동이 시작된 이후 익스트림 프로그래밍의 유저 스토리 기법이 매우 대중화되어 많은 이들이 이것이 모든 프로젝트의 애자일 요구사항에 대한 유일하고 최선의 해결책이라고 생각한다. 알리스테어 콕번은 그가 여전히 애자일 개발에서 유스 케이스를 작성하는 다섯 가지 이유를 나열한다.

1. 목표 이름의 목록은 시스템이 제공할 기능에 대한 가장 짧은 요약을 제공한다(유저 스토리보다도 짧다). 또한 초기 우선순위, 추정, 팀 할당 및 타이밍을 구축하는 데 사용되는 프로젝트 계획 골격을 제공한다.
2. 각 유스 케이스의 기본 성공 시나리오는 시스템이 기본적으로 수행할 작업과 수행하지 않을 작업에 대해 관련된 모든 이들에게 합의를 제공한다. 이는 다른 곳에서는 얻기 매우 어려운 문맥(예: 세분화된 유저 스토리)을 각 특정 항목 요구사항에 제공한다.
3. 각 유스 케이스의 확장 조건은 개발 시간과 예산의 80%를 차지하는 작고 사소한 모든 것들을 조사하기 위한 프레임워크를 제공한다. 이는 이해관계자가 답변을 얻는 데 오랜 시간이 걸릴 것 같은 문제를 찾아낼 수 있는 선행 메커니즘을 제공한다. 이러한 문제들은 개발 팀이 해당 작업을 시작할 때 답변이 준비될 수 있도록 일정보다 앞서 배치될 수 있고 배치되어야 한다.
4. 유스 케이스 확장 시나리오 조각들은 "이 경우에는 어떻게 해야 합니까?"와 같이 상세하고 종종 까다로우며 무시되는 많은 비즈니스 질문에 대한 답을 제공한다. 이는 프로그래머가 문제를 생각하는 데 도움을 주는 if...then...else 문과 일치하는 사고/문서화 프레임워크이다. 단, 프로그래밍 시간이 아니라 조사 시간에 수행된다는 점이 다르다.
5. 전체 유스 케이스 세트는 조사자가 모든 사용자의 니즈, 시스템과 관련된 모든 목표, 그리고 관련된 모든 비즈니스 변형을 철저히 생각했음을 보여준다.

요약하자면, 유스 케이스로 시스템 요구사항을 명세하는 것은 전통적 또는 다른 접근 방식에 비해 다음과 같은 분명한 이점이 있다.

사용자 중심

유스 케이스는 소프트웨어 요구 명세 프로세스를 위한 강력한 사용자 중심 도구이다. 유스 케이스 모델링은 일반적으로 시스템과 상호작용하는 주요 이해관계자 역할(액터)과 시스템이 충족해야 하는 그들의 목표나 목적을 식별하는 것(외부 관점)에서 시작한다. 이러한 사용자 목표는 시스템이 제공하는 원하는 기능적 특징이나 서비스를 나타내는 유스 케이스의 이름이나 제목이 된다. 이러한 사용자 중심 접근 방식은 개발자나 시스템(내부) 관점에서 추측된 사소한 기능이 아니라, 실제 비즈니스 가치가 있고 사용자가 정말로 원하는 것이 개발되도록 보장한다.

유스 케이스 작성은 수년 동안 사용자 중심 설계(UCD) 영역에서 중요하고 가치 있는 분석 도구였다.

더 나은 의사소통

유스 케이스는 종종 구조화된 템플릿과 함께 자연어로 작성된다. 거의 모든 사람이 이해할 수 있는 이러한 서사적 텍스트 형식(읽기 쉬운 요구사항 이야기)은 시각적 UML 다이어그램으로 보완되어 고객, 최종 사용자, 개발자, 테스터 및 관리자를 포함한 모든 이해관계자 간의 더 깊고 나은 의사소통을 촉진한다. 더 나은 의사소통은 양질의 요구사항을 낳고, 결과적으로 양질의 시스템이 전달된다.

구조화된 탐색을 통한 품질 요구사항

유스 케이스의 가장 강력한 점 중 하나는 유스 케이스 템플릿의 형식, 특히 기본 성공 시나리오(기본 흐름)와 확장 시나리오 조각(확장, 예외 및 대안 흐름)에 있다. 사전 조건에서 사후 조건까지 유스 케이스를 단계별로 분석하고, 기본 흐름에서 확장 흐름까지 유스 케이스 흐름의 모든 동작 단계를 조사하여 까다롭고 보통 숨겨져 있거나 무시되는, 겉보기에는 사소하지만 실제로는 종종 비용이 많이 드는 요구사항(콕번이 위에서 언급한 것들)을 식별하는 것은 명확하고 안정적이며 품질 높은 요구사항을 체계적으로 얻는 구조화되고 유익한 방법이다.

사용자 목표를 달성하기 위해 유스 케이스의 동작 단계를 최소화하고 최적화하는 것은 시스템의 더 나은 인터랙션 디자인 및 사용자 경험 디자인에도 기여한다.

테스트 및 사용자 문서화 촉진

동작 또는 이벤트 흐름 구조를 기반으로 하는 잘 작성된 유스 케이스 모델은 시스템이나 제품의 테스트 케이스 및 사용자 매뉴얼 설계를 위한 훌륭한 기초이자 가치 있는 가이드라인 역할을 하며, 이는 사전 투자할 가치가 있는 노력이다. 유스 케이스의 흐름 경로와 테스트 케이스 사이에는 명확한 연결 고리가 있다. 시나리오(유스 케이스의 실행 인스턴스)를 통해 유스 케이스로부터 기능 테스트 케이스를 도출하는 것은 매우 직관적이다.

한계

유스 케이스의 한계는 다음과 같다.

• 유스 케이스는 시스템의 비상호작용 기반 요구사항(알고리즘이나 수학적 요구사항 등)이나 비기능적 요구사항(플랫폼, 성능, 타이밍 또는 안전이 중요한 측면 등)을 캡처하는 데 적합하지 않다. 이러한 것들은 다른 곳에서 선언적으로 명세하는 것이 더 낫다.
• 유스 케이스에 대한 완전한 표준 정의가 없기 때문에 각 프로젝트는 자체적인 해석을 내려야 한다.
• 콕번이 지적했듯이(문제 #6), 확장(extends)과 같은 일부 유스 케이스 관계는 해석이 모호하고 이해관계자가 이해하기 어려울 수 있다.
• 유스 케이스 개발자들은 유스 케이스에 포함할 사용자 인터페이스(UI) 의존성 수준을 결정하는 데 종종 어려움을 겪는다. 유스 케이스 이론은 UI가 유스 케이스에 반영되지 않아야 한다고 제안하지만, 이 설계를 추상화하면 유스 케이스를 시각화하기 어려워져 곤란할 수 있다. 소프트웨어 공학에서는 이러한 어려움을 추적성 매트릭스 등을 통한 요구사항 추적성을 적용하여 해결한다. UI 요소를 유스 케이스와 연결하는 또 다른 접근 방식은 유스 케이스의 각 단계에 UI 설계를 첨부하는 것이다. 이를 유스 케이스 스토리보드라고 한다.
• 유스 케이스가 과도하게 강조될 수 있다. 베르트랑 메이어는 시스템 설계를 유스 케이스로부터 너무 문자 그대로 추진하는 문제와 다른 잠재적으로 가치 있는 요구사항 분석 기법을 배제하고 유스 케이스만 사용하는 문제에 대해 논의한다.
• 유스 케이스는 테스트 설계의 시작점이지만, 각 테스트에는 고유한 성공 기준이 필요하므로 각 경로에 대해 별도의 사후 조건을 제공하도록 유스 케이스를 수정해야 할 수도 있다.
• 유스 케이스에 목표와 문맥이 포함되어 있기는 하지만, 이러한 목표와 목표 뒤의 동기(이해관계자의 관심사 및 비상호작용을 포함한 평가)가 다른 시스템 목표와 충돌하는지 또는 부정적/긍정적으로 영향을 미치는지 여부는 목표 지향적 요구사항 모델링 기법(BMM, I*, KAOS 및 ArchiMate ARMOR 등)의 주제이다.

오해

유스 케이스에 대한 흔한 오해는 다음과 같다.

유저 스토리는 애자일이고 유스 케이스는 그렇지 않다.

애자일과 스크럼은 요구사항 기법에 대해 중립적이다. 스크럼 프라이머(Scrum Primer)에 따르면,

제품 백로그 항목은 명확하고 지속 가능한 어떤 방식으로든 표현된다. 일반적인 오해와 달리 제품 백로그에는 "유저 스토리"가 들어있는 것이 아니라 단순히 항목들이 들어있다. 이러한 항목들은 유저 스토리, 유스 케이스 또는 그룹이 유용하다고 생각하는 다른 요구사항 접근 방식으로 표현될 수 있다. 그러나 어떤 접근 방식을 사용하든 대부분의 항목은 고객에게 가치를 제공하는 데 집중해야 한다.

유스 케이스 기법은 유스 케이스 슬라이스를 사용하여 유스 케이스를 점진적으로 보강함으로써 애자일 접근 방식을 고려하도록 진화했다.

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

크레이그 라만은 "유스 케이스는 다이어그램이 아니라 텍스트이다"라고 강조한다.

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

어떤 이들은 다음과 같이 말한다.

유스 케이스는 종종 처음부터 새로운 시스템에 대한 요구사항을 캡처하는 데 적합하지 않게 만드는 세부 수준(즉, 레이블 및 버튼의 이름 지정)을 포함한다.

이는 초보적인 오해이다. 잘 작성된 유스 케이스의 각 단계는 액터의 목표나 의도(기능적 요구사항의 본질)를 제시해야 하며, 일반적으로 레이블 및 버튼의 이름 지정, UI 조작 등과 같은 사용자 인터페이스 세부 사항을 포함해서는 안 된다. 이는 나쁜 관행이며 유스 케이스 작성을 불필요하게 복잡하게 만들고 구현을 제한한다.

처음부터 새로운 시스템에 대한 요구사항을 캡처하는 경우, 유스 케이스 다이어그램과 유스 케이스 요약은 적어도 유저 스토리만큼 가벼우면서도 편리하고 가치 있는 도구로 자주 사용된다.

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

어떤 이들은 다음과 같이 말한다.

유스 케이스의 형식 때문에 대규모 시스템(예: CRM 시스템)을 수백 페이지 이내로 설명하기 어렵다. 시간이 많이 걸리고 불필요한 재작업을 하는 데 시간을 보내게 될 것이다.

가치가 없거나 거의 없는 지루한 유스 케이스를 작성하는 데 많은 시간을 소비하고 그 결과 많은 재작업이 발생하는 것은 작성자가 숙련되지 않았으며 양질의 유스 케이스를 효율적이고 효과적으로 작성하는 방법에 대한 지식이 부족하다는 징후이다. 유스 케이스는 반복적이고 점진적이며 진화적인(애자일) 방식으로 작성되어야 한다. 유스 케이스 템플릿을 적용한다는 것이 유스 케이스 템플릿의 모든 필드를 초기부터 또는 특정 전담 단계(즉, 전통적인 폭포수 개발 모델의 요구사항 단계) 동안 포괄적으로 사용하고 채워야 함을 의미하지는 않는다.

실제로 RUP 스타일이나 콕번 스타일(OUM 방법론에서도 채택됨)과 같은 대중적인 템플릿 스타일로 정식화된 유스 케이스 형식은 대규모 시스템의 복잡한 요구사항을 캡처, 분석 및 문서화하는 데 가치 있고 유용한 도구임이 실무에서 증명되었다. 좋은 유스 케이스 문서(모델)의 품질은 단순히 그 크기로만 판단해서는 안 된다. 대규모 시스템의 양질의 포괄적인 유스 케이스 모델이 작성자의 미숙한 작성 기술 때문이 아니라, 다루고 있는 문제 자체의 고유한 복잡성 때문에 결국 수백 페이지로 진화할 수도 있다.

도구

템플릿 지원 기능이 있는 텍스트 편집기 및 워드 프로세서가 유스 케이스 작성에 자주 사용된다. 크고 복잡한 시스템 요구사항의 경우 전용 유스 케이스 도구가 도움이 된다.

잘 알려진 유스 케이스 도구는 다음과 같다.

• CaseComplete
• Enterprise Architect
• MagicDraw
• Rational Software의 RequisitePro - 1990년대 초기 잘 알려진 유스 케이스 및 요구사항 관리 도구 중 하나이다.
• Software Ideas Modeler
• 위키 소프트웨어 - 팀이 협력하여 유스 케이스를 작성하고 관리하기에 좋은 도구이다.

대부분의 UML 도구는 유스 케이스의 텍스트 작성과 시각적 모델링을 모두 지원한다.

같이 보기

• UML 통합 모델링 언어
• 컴포넌트 기반 소프트웨어 공학 (CBD)