가이드라인: 비즈니스 유스 케이스 모델
비즈니스 유스 케이스 모델은 해당 고객, 파트너 및 기타 외부 에이전시에서 비즈니스를 사용하는 방법에 대해 설명합니다. 이 가이드라인은 비즈니스 유스 케이스 모델링에 대한 입문서입니다.
관계
기본 설명

설명

비즈니스 유스 케이스 및 액터를 모델링하는 주된 목적은 외부 구성원, 특히 해당 고객과 파트너가 비즈니스를 사용하는 방법을 설명하기 위해서입니다. 고객 또는 파트너와 직접적인 관련이 있는 타스크와, 외부 관계자와 간접적인 관련만 있는 지원 또는 관리 타스크가 표시됩니다.

모델은 비즈니스 유스 케이스 관점에서 비즈니스를 설명합니다. 비즈니스 유스 케이스는 일반적으로 "프로세스"에 해당합니다.

함께 표시된 텍스트에서 설명되는 다이어그램.

탑승 수속 카운터의 액터와 유스 케이스

비즈니스 유스 케이스 카테고리

비즈니스 타스크를 검사할 때 다음 세 가지 비즈니스 유스 케이스 카테고리에 해당하는 세 개 이상의 작업 카테고리를 식별할 수 있습니다.

  • 코어 - 가치 사슬을 제공하는 외부 연결 비즈니스 유스 케이스입니다(예: 제품 구매)
  • 관리 - 가치 사슬을 조정하는 내부 비즈니스 유스 케이스입니다(예: 전략 계획)
  • 지원 - 가치 사슬을 지원하는 내부 비즈니스 유스 케이스입니다(예: 원료 조달)

'내부 비즈니스 유스 케이스'에 대한 표시와 해당 의미는 나중에 설명합니다.

일반적으로 관리 유형의 비즈니스 유스 케이스는 CEO와 비즈니스 유스 케이스 작업자와의 관계를 설명합니다. 이 유스 케이스는 또한 비즈니스 유스 케이스를 개발하고 인스턴스화(시작)하는 방법에 대해 설명합니다.

함께 표시된 텍스트에서 설명되는 다이어그램.

이 그림은 음식점의 예로서, 코어 비즈니스 유스 케이스는 마케팅 및 저녁 식사 제공이며 지원 비즈니스 유스 케이스는 재료 구매입니다.

코어 비즈니스 유스 케이스로 간주하는 대상이 경우에 따라 다른 비즈니스에서 지원 비즈니스 유스 케이스가 될 수도 있습니다. 예를 들어, 소프트웨어 개발의 경우 소프트웨어 개발 회사에서는 코어 비즈니스 유스 케이스인 반면 은행 또는 보험 회사에서는 지원 비즈니스 유스 케이스로 분류될 수 있습니다. 즉, 소프트웨어 개발 비즈니스를 모델링할 때 개발되는 여러 가지 세부 비즈니스 유스 케이스가 자체 소프트웨어를 개발하기도 하는 은행의 비즈니스 유스 케이스에서는 최상위 레벨에 표시되지 않으며 지원 비즈니스 유스 케이스로도 표시되지 않을 수 있습니다. 이러한 유스 케이스는 나중에 하위 유스 케이스로 표시될 수 있습니다(개념: 대규모 조직 모델링 참조). 은행 레벨에서는 은행의 전략목적을 반영하는 지원 유스 케이스만 표시되며 이러한 유스 케이스 중 하나가 "소프트웨어 개발 운영 비즈니스 단위"가 됩니다.

하나의 비즈니스에 여러 비즈니스 유스 케이스 포함

서로 다른 여러 비즈니스 유스 케이스의 인스턴스와 단일 비즈니스 유스 케이스의 여러 인스턴스는 일반적으로 동시에 실행됩니다. 하나의 유스 케이스 인스턴스가 따르는 경로의 수는 거의 무제한입니다. 이처럼 서로 다른 경로는 워크플로우 설명에서 유스 케이스 인스턴스에 대해 공개된 선택사항을 나타냅니다. 유스 케이스 인스턴스는 특정 이벤트 또는 사실에 따라, 다음과 같이 가능한 여러 경로 중 지정된 경로에 따라 진행할 수 있습니다.

  • 액터 입력
  • 비즈니스 규칙

비즈니스 유스 케이스 모델링에서는 유스 케이스 인스턴스가 충돌 없이 동시에 활성화될 수 있는 것으로 가정할 수 있습니다. 이 비즈니스 개발 단계에서는 비즈니스가 수행해야 하는 내용에 초점을 두어야 합니다. 잠재적인 자원 충돌 문제는 나중에 비즈니스 유스 케이스 실현(realization)을 모델링할 때 비즈니스 작업 수행 방법에 대한 이해가 필요한 단계에서 해결합니다. 또는 새 조직을 구현할 때 예를 들어, 중요 타스크를 수행할 수 있는 직원 수를 늘려 이 문제점을 해결할 수 있습니다.

비즈니스 유스 케이스와 비즈니스 액터와의 관련성

모든 코어 비즈니스 유스 케이스에는 커뮤니케이션 관계 또는 비즈니스 액터와의 관계가 필요합니다. 이 규칙은 해당 사용자가 요청하는 서비스를 중심으로 비즈니스가 빌드되어야 한다는 목적을 구현하기 위한 것입니다. 비즈니스 유스 케이스 모델의 코어 비즈니스 유스 케이스를 아무도 요청하지 않는 경우 모델이 잘못되었음을 나타냅니다.

비즈니스 유스 케이스는 주기적으로 트리거되거나 장시간 실행될 수 있습니다. 후자의 예로 감시 기능을 들 수 있습니다. 이러한 비즈니스 유스 케이스에도 최초에 유스 케이스를 시작한 비즈니스 액터가 있으며 해당 비즈니스 액터에서 다른 서비스를 예상할 수 있습니다. 그렇지 않은 경우 비즈니스 유스 케이스가 비즈니스에 속하지 않습니다. 다른 비즈니스 유스 케이스는 비즈니스 액터에 대한 결과를 생성하지만 비즈니스 액터에 의해 명시적으로 시작되지는 않습니다. 예를 들어, 널리 배포되는 제품의 개발이 식별 가능한 고객에 의해 시작되는 경우는 매우 드뭅니다. 대신 신제품에 대한 요구는 시장 조사와 많은 사용자의 지속적인 요청에 의해 실현됩니다.

내부 비즈니스 유스 케이스

관리 및 지원 비즈니스 유스 케이스(앞에서는 내부로 설명)는 일반적으로 외부 접촉도 가능하지만 반드시 비즈니스 액터와 연결할 필요는 없습니다. 예를 들어, 관리 비즈니스 유스 케이스는 비즈니스 소유자 또는 이사회를 비즈니스 액터로 간주할 수 있습니다.

'유스 케이스'란 비즈니스와 상호작용하는 '사람' 또는 '대상'을 나타내며 가치를 제공해야 한다는 관점에서 볼 때 액터가 없는 비즈니스 유스 케이스가 이상하게 보일 수 있지만, 이 비즈니스 유스 케이스 클래스는 비즈니스 액터가 있는 비즈니스 유스 케이스 개념의 확장으로 간주할 수 있습니다. 명시적 확장 사용에 대해서는 가이드라인: 비즈니스 유스 케이스 모델의 확장 관계에서 설명하지만 여기서 기본 (확장) 비즈니스 유스 케이스는 개념적인 정의이므로 모델링하지 않을 수 있습니다. 관리 및 지원 비즈니스 유스 케이스는 이 기본 개념에 대한 확장으로서, 비즈니스 수행 시 발생하는 조건(중간 산출물: 비즈니스 이벤트의 결과)에 의해 트리거됩니다. 이러한 관점에서 보면 인위적인 비즈니스 액터를 사용하지 않아도 되지만 지원 및 관리 비즈니스 유스 케이스가 가치를 추가하는 방법에 대해 생각해보아야 합니다.

추상 비즈니스 유스 케이스의 경우 자체적으로 인스턴스화(시작)되지 않으므로 비즈니스 액터가 필요하지 않습니다.

비즈니스 유스 케이스의 비즈니스 목적 지원 필요성

비즈니스 프로세스는 비즈니스 업무 수행을 위해 사용하는 수단입니다. 비즈니스 전략은 조치로 직접 변환되기 어려우므로 다른 도구가 필요하며 이 도구가 바로 비즈니스 목적입니다. 비즈니스 목적은 비즈니스 프로세스를 통해 모든 조직 레벨에서 궁극적인 비즈니스 목적(비즈니스 아이디어)에 대한 조치를 수행함으로써 비즈니스 전략을 실행할 수 있도록 해줍니다.

이러한 이유로 각 비즈니스 유스 케이스는 하나 이상의 비즈니스 목적을 지원해야 합니다. 전략을 다양한 레벨의 목적으로 변환함으로써 구체적이고 측정 가능한 목표를 제공할 수 있으며 비즈니스 프로세스에서 이 목표를 직접 지원할 수 있습니다. 목적과 프로세스 간에 지원 관계를 정의함으로써 비즈니스 전략에 맞게 비즈니스 프로세스를 조정할 수 있습니다. 또한 이를 통해 일반적으로 판별하기 어려운 올바른 비즈니스 유스 케이스 레벨을 확인할 수 있습니다. 엔터프라이즈의 전략적 목표를 직접 지원하는 하나의 비즈니스 유스 케이스(예: 수익 창출)만 일련의 타스크로 모델링하는 것은 너무 복잡하고 번거로운 작업입니다. 반면에 조직 내 각 개별 운영 타스크에 대해 개별 비즈니스 유스 케이스를 작성하는 경우(예: 전화 호출 전송 또는 회의실 예약) 비즈니스 유스 케이스가 너무 많아져 이해하기 어렵습니다. 비즈니스 유스 케이스에서 지원하는 비즈니스 목적을 정의함으로써 해당 비즈니스 유스 케이스의 "너무 높음" 또는 "너무 낮음" 여부를 나타낼 수 있습니다. 

비즈니스 유스 케이스가 하나 이상의 비즈니스 목적을 명시적으로 지원하는 경우 해당 비즈니스 유스 케이스의 가치를 쉽게 정량화할 수 있습니다. 해당 목적에 대한 비즈니스 유스 케이스 결과의 컨트리뷰션을 측정할 수 있습니다. 또한 비즈니스 유스 케이스의 성능을 모니터함으로써 가치 대 비용을 객관적으로 비교할 수 있습니다.

이러한 관계를 통해 비즈니스 유스 케이스의 우선순위를 쉽게 결정할 수 있습니다. 많은 비즈니스 목적을 지원하거나 중요하지만 위험을 감수해야 하는 비즈니스 목적을 지원하는 비즈니스 유스 케이스는 구조적으로 중요한 경우가 많습니다. 목적이 많다는 것은 동시에 불필요한 복잡성이 존재함을 나타낼 수 있습니다. 즉, 하나의 비즈니스 유스 케이스가 서로 다른 여러 목적을 지원하는 경우 충돌이 발생할 가능성이 높습니다. 이러한 경우 중요한 우선순위를 쉽게 결정할 수 없어 조치의 효율성이 저하됩니다.

비즈니스 유스 케이스의 카테고리(코어, 지원 또는 관리)는 지원 대상 비즈니스 목적 유형을 직접 결정하지 않습니다. 카테고리는 가이드라인만 제공하며, 특정 비즈니스 유스 케이스가 지원하는 비즈니스 목적은 궁극적으로 비즈니스 전략으로 결정됩니다. 예를 들어, 제품 마케팅 및 판매 비즈니스 유스 케이스는 공격적인 성장 전략을 취하는 비즈니스의 가격 경쟁력 비즈니스 목적을 지원할 수 있습니다. 몇 년 후 동일한 비즈니스에서 목표 고객 만족 및 보유를 통해 해당 제품과 시장에 대한 투자를 극대화할 수 있습니다. 이러한 경우 제품 마케팅 및 판매 비즈니스 유스 케이스는 이전과 아주 다른 품질 향상 비즈니스 목적을 지원해야 합니다. 비즈니스 목적 모델링에 대한 자세한 정보는 가이드라인: 비즈니스 목적을 참조하십시오.

예를 들어, 가이드라인: 비즈니스 목적에서 예제로 사용된 대형 가구점의 경우 다음과 같은 가구점의 비즈니스 유스 케이스 모델을 예상할 수 있습니다.

이 다이어그램은 가구점의 비즈니스 유스 케이스 모델을 보여줍니다.

고객은 제품을 선택한 후 쇼룸에 인접한 창고에서 직접 제품을 확인하고 비용을 지불할 수 있습니다. 또한 제품에 결함이 있는 경우 즉시 반품할 수 있습니다. 고객 요구 식별 비즈니스 유스 케이스는 일반적으로 시장 조사라고도 합니다. 적합한 제품을 찾아 출고 준비까지 완료되면 벤더가 공급자가 됩니다. 이를 위의 그림과 같은 별도 비즈니스 유스 케이스 또는 시장 조사의 일부로 간주해야 하는지 여부에 대한 논란의 여지가 있지만 제품 판매도 모니터해야 합니다. 위의 비즈니스 유스 케이스를 가이드라인: 비즈니스 목적에서 설명하는 비즈니스 목적으로 맵핑하려면 다음 사항을 고려해야 합니다.

함께 표시된 텍스트에서 설명되는 다이어그램.

적합한 제품 찾기 비즈니스 유스 케이스는 다소 충돌하는 비즈니스 목적을 지원합니다. 따라서 두 가지 비즈니스 목적을 모두 충족시킬 수 있도록 가격과 품질을 절충하는 방법을 명확히 해야 합니다. 결함이 있어 반품된 제품 수(또는 백분율)로 제품 품질을 평가하는 경우 공급자에게 해당 제품을 보내 결함의 원인을 밝혀야 합니다. 예를 들어, 전달 팀의 과실로 제품이 손상되어 고객에게 전달된 제품 중 상당 수가 반품된 경우일 수 있습니다. 그러나 전달 수량만 측정한다면 전달 과정에서의 문제를 밝혀낼 수 없습니다.

제품 비용 지불 비즈니스 유스 케이스는 지불 방법은 지원하고 낮은 가격 책정은 지원하지 않을 수 있습니다. 가격 책정은 별도의 적합한 제품 찾기 비즈니스 유스 케이스에서 결정되기 때문입니다.

특정 회사의 경우 여러 비즈니스 유스 케이스가 비즈니스 목적을 지원하지 않는 경우도 있습니다. 이러한 경우 모니터 판매가 직접 지원하는 비즈니스 목적이 없으므로 모니터 판매를 고객 요구 식별에 병합해야 합니다. 그러나 비즈니스 목적에 대한 지원 부족은 비즈니스 목적을 보다 구체적으로 작성해야 함을 알려주는 것일 수 있으므로 이러한 병합을 서둘러서는 안됩니다. 최악의 경우 모니터 판매가 고객 요구 식별에 대한 입력을 제공합니다.

제품 전달 비즈니스 유스 케이스는 전달 시간 준수 비즈니스 목적을 지원합니다. 고객은 자신이 구입한 제품이 전달될 때까지 너무 오래 기다려서는 안됩니다. 이 목적을 달성하기 위한 방법을 고려하는 데 있어 획기적인 아이디어를 제공할 수 있습니다. 예를 들어, 창고와 시내 주택가 사이에 지하 통로를 만들어 100MPH의 속도로 제품을 전달함으로써 고객보다 먼저 집에 도착하게 할 수 있습니다. 이 아이디어는 지극히 비현실적이지만 이러한 브레인스토밍 사고 방식을 통해 비즈니스 개선을 위한 많은 아이디어를 개발할 수 있습니다.

다음은 비즈니스 목적을 고려함으로써 표면적으로 사소하게 보이는 비즈니스 유스 케이스의 중요성을 밝혀낼 수 있는 예입니다. 먼저 많은 고객이 식사 시간에 구매를 하는 것으로 가정합니다. 이 때 비즈니스 목적은 설비의 품질을 향상시키는 것과 고객을 유인하는 것이므로 고객이 쇼핑 전후에 간단한 스낵을 먹을 수 있는 식당을 제공하기로 결정합니다. 이 목적을 지원하는 식사 비즈니스 유스 케이스가 아래 표시됩니다. 결과적으로 이 식당이 해당 비즈니스의 주요 경쟁력 중 하나가 될 수 있습니다.

함께 표시된 텍스트에서 설명되는 다이어그램.

위의 다이어그램에서 또한 비즈니스 경계를 조정한 효과를 확인할 수 있습니다. 즉, 운송업자라는 새로운 비즈니스 액터가 도입됩니다. 이 비즈니스 액터는 창고에서 제품을 가져와 고객에게 전달하는 역할을 수행하는 파트너입니다. 이러한 접근 방식을 통해 비즈니스 목적 중 하나인 전달 시간 최소화 효과를 얻을 수 있습니다.

비즈니스 유스 케이스 모델 구조화

비즈니스 유스 케이스 모델을 구조화하는 세 가지 주된 이유는 다음과 같습니다.

  • 비즈니스 유스 케이스를 보다 쉽게 이해할 수 있습니다.
  • 여러 비즈니스 유스 케이스에서 공유하는 워크플로우 파트를 공유합니다.
  • 비즈니스 유스 케이스 모델을 보다 쉽게 유지보수할 수 있습니다.

비즈니스 유스 케이스를 구조화하기 위해서는 세 가지 유형의 관계가 필요합니다. 이 관계를 이용하여 다른 비즈니스 유스 케이스에 재사용할 수 있거나 비즈니스 유스 케이스의 전문화 또는 옵션에 해당하는 비즈니스 유스 케이스의 일부를 분리할 수 있습니다. 수정을 나타내는 비즈니스 유스 케이스를 추가 유스 케이스라고 하며 수정되는 비즈니스 유스 케이스를 기본 유스 케이스라고 합니다.

  • 기본 유스 케이스의 특정 파트가 해당 비즈니스 유스 케이스가 결과를 생성하는 데 사용되는 방법이 아닌 해당 결과에만 의존하는 기능을 나타내는 경우 해당 파트를 추가 유스 케이스로 분리할 수 있습니다. 이 추가는 포함 관계를 사용하여 기본 유스 케이스에 명시적으로 포함됩니다. 또한 가이드라인: 비즈니스 유스 케이스 모델의 포함 관계를 참조하십시오.
  • 선택적이거나 유스 케이스의 기본 목적을 이해하는 데 필요하지 않은 기본 유스 케이스의 파트가 있는 경우, 기본 유스 케이스의 구조를 단순화하기 위해 해당 파트를 추가 유스 케이스로 분리할 수 있습니다. 이 추가는 확장 관계를 사용하여 기본 유스 케이스에 내재적으로 포함됩니다.또한 가이드라인: 비즈니스 유스 케이스 모델의 확장 관계를 참조하십시오.
  • 동작 및 구조에 공통점이 있고 목적이 유사한 비즈니스 유스 케이스가 있는 경우, 해당 공통 파트는 추가 유스 케이스(하위)에 의해 상속되는 기본 유스 케이스(상위)로 분리될 수 있습니다. 하위 유스 케이스는 상위 유스 케이스에서 상속하는 구조에 새 동작을 삽입하고 기존 동작을 수정할 수 있습니다. 또한 가이드라인: 비즈니스 유스 케이스 모델의 유스 케이스 일반화를 참조하십시오.

함께 표시된 텍스트에서 설명되는 다이어그램.

위의 그림은 액터 및 유스 케이스와 탑승 수속 카운터를 보여줍니다. 또한 수화물 처리 포함 유스 케이스와 탑승 수속 수행 확장 유스 케이스가 표시됩니다.

액터 일반화를 사용하여 액터 각각의 전문화 방식을 표시할 수 있습니다. 또한 가이드라인: 비즈니스 유스 케이스 모델의 액터 일반화를 참조하십시오.

또한 가이드라인: 유스 케이스 모델에서 시스템 유스 케이스 구성에 대한 내용을 참조하십시오.

모델링 노력 한계 설정

특히 소프트웨어 엔지니어링 프로젝트에 있어 "성장 촉진"에 초점을 두는 비즈니스 모델을 개발하는 경우 비즈니스 모델링 노력에 대한 한계를 주의깊게 설정해야 합니다. 이러한 경우 비즈니스 프로세스의 서브세트만 모델링하더라도 전체 조직을 범위로 정할 필요는 없습니다. 예상 가치가 있는 결과에 초점을 두고 원하는 결과를 얻으려면 전체 회사의 특정 파트를 "비즈니스 시스템"으로 고려해야 합니다. 선택하는 파트는 빌드될 시스템을 직접 사용하는 파트여야 합니다. 모델 외부로 간주할 조직 파트는 비즈니스 액터로 나타낼 수 있습니다.

예제:

회사에서 판매 및 주문 관리를 위해 새 응용프로그램을 빌드하는 노력을 수행하기로 결정했습니다. 조직의 요구를 탐색하고 조직의 비즈니스 수행 방법을 조정하기 위한 첫 번째 단계는 비즈니스 모델 세트를 빌드하는 것입니다. 새 주문 응용프로그램을 적극적으로 사용하지 않는 부서는 모델 외부로 간주되며 비즈니스 액터로 표시됩니다.

함께 표시된 텍스트에서 설명되는 다이어그램.

위의 그림은 주문 관리 조직의 비즈니스 유스 케이스 모델의 비즈니스 액터 및 비즈니스 유스 케이스를 보여줍니다. 이 조직은 각 고객에 맞게 주문 제작되는 복잡한 솔루션을 판매합니다.

다음은 비즈니스 유스 케이스에 대한 몇 가지 간략한 설명입니다.

주문 프로세스 - 이 프로세스는 회사에서 고객 요구사항 세트에 정의된 대로 고객에게 솔루션을 제공하기 위해 적합한 조치를 수행하는 방법에 대해 설명합니다. 이 프로세스는 합의된 솔루션 진행을 위한 비즈니스 의사결정이 이루어질 때 시작됩니다. 이 프로세스는 일반적으로 고객에게 구매 주문서를 받는 회사의 양식으로 작성됩니다. 이 프로세스는 또한 고객이 분납 형식에 만족하고 솔루션 및 지불에 대한 위임장을 제출하면 종료됩니다. 이 프로세스의 목표는 고객 요구사항을 만족시키면서 동시에 수익성을 얻는 것입니다.

제안 프로세스 - 이 프로세스는 고객 요구사항의 응답으로 제안을 생성하는 프로세스입니다. 이 프로세스는 고객의 조회로 트리거되며 고객이 제안의 견적을 승인 또는 거부하면서 종료됩니다. 이 프로세스의 목표는 고객과 회사가 모두 허용 가능한 견적에 동의하는 것입니다.

견적 프로세스 - 견적 프로세스는 제안 프로세스와 주문 프로세스에 모두 포함되는 추상 비즈니스 유스 케이스입니다. 이 프로세스는 프로세스에 대해 생성된 견적이 필요한 고객 요구사항이 있을 때 시작됩니다. 견적 프로세스의 목표는 고객 요구사항을 충족시키는 솔루션을 생성하여 가격과 함께 제공하는 것입니다.

조사 설명

비즈니스 유스 케이스 모델에 대한 조사 설명의 필수 요소는 다음과 같습니다.

  • 조직의 목적 요약
  • 모델의 한계, 즉 포함되지 않은 내용과 해당 이유 지적
  • 기본 비즈니스 유스 케이스 지정

예제:

이 비즈니스 유스 케이스 모델은 회사에서 고객 주문을 관리하는 파트에 대해서만 다룹니다. 이 파트만이 비즈니스 모델링 결과를 입력으로 사용하는 소프트웨어 엔지니어링 프로젝트와 관련이 있기 때문입니다. 이러한 이유로, 회사에서 청구, 제조, 제품 관리 및 제품 개발을 처리하는 회사의 파트는 포함하지 않습니다. 해당 파트는 외부로 간주되어 비즈니스 액터로 표시됩니다.

이 조직에서 판매는 솔루션 계약뿐만 아니라 솔루션의 실제 빌드까지 포함합니다. 솔루션 가격을 정의하려면 솔루션을 엔지니어링하고 특정 세부 레벨까지 빌드해야 합니다. 이 작업은 제안 프로세스에서 수행됩니다. 고객과의 계약이 작성되면 모든 세부 요소까지 솔루션이 엔지니어링되고 고객 사이트에 설치됩니다. 이 내용은 주문 프로세스에서 설명합니다. 제안 프로세스 및 주문 프로세스에는 모두 추상 비즈니스 유스 케이스인 견적 프로세스가 포함됩니다.

올바른 비즈니스 유스 케이스 모델의 특성

  • 비즈니스 유스 케이스가 구체적인 비즈니스 목적에서 설명하는 대로 비즈니스 전략에 맞게 작성됩니다.
  • 유스 케이스가 해당 비즈니스를 준수합니다.
  • 모든 유스 케이스를 찾았으며 유스 케이스를 함께 사용하여 비즈니스 내 모든 타스크를 수행합니다.
  • 모든 비즈니스 타스크는 하나 이상의 유스 케이스에 포함되어야 합니다.
  • 유스 케이스 수와 유스 케이스 크기가 밸런스를 이루어야 합니다.
  • 유스 케이스가 적으면 모델을 쉽게 이해할 수 있습니다.
  • 유스 케이스가 많으면 모델을 이해하기가 어렵습니다.
  • 대규모 유스 케이스는 복잡하여 이해하기가 어렵습니다.
  • 소규모 유스 케이스는 일반적으로 쉽게 이해할 수 있습니다. 그러나 유스 케이스는 고객에게 가치있는 대상을 생성하는 전체 워크플로우에 대해 설명해야 합니다.
  • 각 유스 케이스는 고유해야 합니다. 워크플로우가 다른 유스 케이스와 같거나 유사한 경우 나중에 동기화 상태를 유지하기 어려우므로 단일 유스 케이스로 병합해야 합니다.
  • 비즈니스 유스 케이스 모델에 대한 조사 설명은 조직에 대한 모든 정보를 정확하게 제공해야 합니다.