예제 유스 케이스 모델링 가이드라인

 

버전 <n.m>

마지막 갱신 날짜 <yyyymmdd>

 

 


개정 히스토리

날짜

버전

설명

작성자

 

 

 

 

 

 

 

 

 


목차

1.     소개

1.1   목적

1.2   범위

1.3   용어의 정의 

1.4   참조  

1.5   개요

2.     일반 유스 케이스 모델링 가이드라인

2.1   일반 스타일 

2.2   <<통신>> 관계 사용  

2.3   <<포함>> 및 <<확장>> 관계 사용   

2.3.1  <<포함>> 관계 사용 

2.3.2  <<확장>> 관계 사용

2.4   액터-일반화 사용

2.5   상호작용 다이어그램 사용

2.6   활동 다이어그램 사용

3.     유스 케이스 설명 방법

3.1   액터 가이드라인

3.1.1  각각의 구체적 유스 케이스는 하나 이상의 액터와 관련됨

3.1.2  직관적이고 설명적인 액터 이름 

3.1.3  액터 이름의 일관적 사용 

3.2   유스 케이스 이름

3.3   유스 케이스 간략한 설명 

3.3.1  하나 이상의 단락 

3.3.2  예제(선택적)

3.4   명령문: Will의 일관적 사용 

3.5   용어집 용어 사용

3.6   "조치" 용어 사용

3.6.1  시스템이 조치 옵션을 제공해야 하는 위치 정의 

3.6.2  유스 케이스에서의 일관된 용어 사용 

3.7   액터 및 시스템 동작에 대한 별도 단락 

3.8   대체 및 서브플로우 

3.9   전제 조건 및 사후 조건

3.10 세부사항 누락에 대한 플레이스홀더 사용(TBD)

3.11 보충 스펙에 대한 참조 및 정의

3.12 UI 프로토타입/디자인과의 상호 점검

3.13 예외 플로우(선택적)

3.13.1 가능한 문제


유스 케이스 모델링 가이드라인

 

1.                  소개  페이지 맨 위로 이동합니다.

1.1               목적 페이지 맨 위로 이동합니다.

이 가이드라인 세트의 목적은 유스 케이스 모델의 일관성을 확보하는 것입니다. 이 가이드라인은 유스 케이스의 문서화 방법에 대한 지침과, 요구사항 지정자 및 시스템 분석가와 관련하여 발생할 수 있는 관련 주제에 대한 일반 도움말을 제공합니다.

1.2               범위 페이지 맨 위로 이동합니다.

이 가이드라인은 대부분 프로젝트의 요구사항을 충족시키도록 있는 그대로 또는 수정하여 사용할 수 있습니다.

1.3               용어의 정의 페이지 맨 위로 이동합니다.

Rational Unified Process 용어집을 참조하십시오.

1.4               참조 페이지 맨 위로 이동합니다.

없음

1.5               개요 페이지 맨 위로 이동합니다.

이 가이드라인 세트는 두 개 섹션으로 구성됩니다. 첫 번째 파트는 선호되는 유스 케이스 모델링 방법에 대해 설명하고 두 번째 파트는 유스 케이스 모델의 컨텐츠와 모델 내 요소 이름 지정을 위한 가이드라인을 제공합니다.

2.                  일반 유스 케이스 모델링 가이드라인 페이지 맨 위로 이동합니다.

2.1               일반 스타일 페이지 맨 위로 이동합니다.

유스 케이스는 Rational Unified Process와 함께 제공되는 템플리트를 사용하여 작성되며, 해당 프로젝트 문서화 표준을 따르는 특정 스타일 및 레이아웃 수정사항이 제공됩니다.

2.2               <<통신>> 관계 사용 페이지 맨 위로 이동합니다.

액터와 유스 케이스 간의 연관을 커뮤니케이션 관계라고 합니다. 이 연관은 단방향 연관이 바람직합니다. 이 모델링 전략을 사용하면 다음 두 액터를 구분할 수 있습니다.

q       활성 액터
이 액터는 액터가 유스 케이스 실행을 시작(또는 트리거)할 때 액터-유스 케이스 쌍에서 활성 상태가 되는 것으로 간주됩니다. 통신  관계의 화살표는 유스 케이스를 가리킵니다.

q       수동 액터
이 액터는 유스 케이스가 통신을 시작할 때 액터-유스 케이스 쌍에서 수동 상태가 되는 것으로 간주됩니다. 수동 액터는 일반적으로 시스템이 통신해야 하는 외부 시스템 또는 장치입니다. 커뮤니케이션 관계의 화살표는 액터를 가리킵니다.

이 권장사항을 제공하는 이유는 활성 및 수동 액터에 대한 개념이 유스 케이스 모델 사용자에게 가치를 추가하기 때문입니다.

2.3               <<포함>> 및 <<확장>> 관계 사용 페이지 맨 위로 이동합니다.

우선 이러한 관계는 사용하지 않는 것이 좋습니다. 이 권장사항을 제공하는 이유는 이러한 관계를 잘못 사용하는 경우 유스 케이스 모델을 단순화하는 것보다 모델을 어지럽히고 혼란스럽게 할 가능성이 더 많기 때문입니다. 가장 좋은 방법은 처음에는 이러한 분할 유형을 사용하지 않고 프로세스 후반부에서 이러한 관계를 사용하도록 고려하는 것입니다. 이러한 관계는 다음과 같은 목적으로 사용할 수 있습니다.

1.       두 개 이상의 유스 케이스에 공통적인 동작을 분할합니다.

2.       기본 유스 케이스에서 유스 케이스의 기본 목적을 이해하는 데 필요하지 않고 해당 결과만 중요한 동작을 분할합니다.

3.       기본 유스 케이스의 확장점에서 하나 이상을 삽입할 수 있는 동작 세그먼트의 세트가 있음을 보여줍니다.

그러나 이 관계는 유스 케이스 모델을 단순화하고 관리할 수 있도록 도와줌으로써 가치를 추가하는 경우에만 사용해야 합니다.

2.3.1          <<Include>> 관계 사용 페이지 맨 위로 이동합니다.

포함 관계는 기본 유스 케이스를 실행하는 유스 케이스 인스턴스에 삽입되는 동작 세그먼트에 대해 설명합니다. 이 관계는 서브루틴과 그 특성이 유사한 메커니즘으로서, 일반적으로 공통 동작을 분할하는 데 사용됩니다. 

자세한 내용은 Rational Unified Process의 포함 관계에 대한 가이드라인을 참조하십시오.

2.3.2          <<확장>> 관계 사용 페이지 맨 위로 이동합니다.

확장 관계는 사용하기가 더 어려운 관계로서, 이는 기본 유스 케이스에서 확장 유스 케이스를 인식할 수 없기 때문입니다. 일반적으로, 대부분의 비즈니스 시스템에서 이 관계가 유용한 경우는 거의 없습니다. 그러나 항상 규칙에는 예외가 있듯이 특정 상황에서 이 메커니즘을 유용하게 활용할 수 있습니다.

자세한 내용은 Rational Unified Process의 확장 관계에 대한 가이드라인을 참조하십시오.

2.4               액터-일반화 사용 페이지 맨 위로 이동합니다.

일반적으로, 액터-일반화는 개발될 시스템의 사용자가 수행하는 다른 역할을 보다 효과적으로 정의하는 데 사용할 수 있습니다.  이는 일반 사용자의 "카테고리"가 다른 응용프로그램에서 유용합니다. 이러한 방법을 사용하는 경우, 각 사용자 카테고리에는 관련 기능만 표시되므로 이 그룹핑에 따라 액세스 권한을 제어할 수 있습니다.

일반 규칙: 각 유스 케이스는 하나의 액터만 시작할 수 있습니다. 이 "규칙"은 유스 케이스 설명이 해당 결정사항을 충족시켜야 하는 경우 무시할 수 있습니다.

대학교 비즈니스 도메인 예제:  사서 및 교수는 대학교 도메인의 두 가지 기존 역할(액터)의 예제입니다. 이 역할에는 몇 가지 공통 타스크와 각 비즈니스 역할에 고유한 몇 가지 타스크가 있습니다. 이 액터에 대해 선호되는 모델링 방법은 다음을 참조하십시오. 컨텐츠 위쪽의 이미지 세부사항

자세한 내용은 Rational Unified Process의 액터-일반화에 대한 가이드라인을 참조하십시오.

2.5               상호작용 다이어그램 사용 페이지 맨 위로 이동합니다.

경우에 따라, 유스 케이스 이벤트의 "상위 레벨" 플로우를 나타내기 위해 이벤트의 텍스트 플로우 이외에 상호작용 다이어그램을 포함하는 것이 유용합니다. 이러한 시퀀스 다이어그램은 Rational Rose에서 작성하는 것이 바람직합니다. 액터와 경계 오브젝트(입력 및 출력 메시지를 모두 포함) 간의 통신만 포함하고 시스템을 블랙 박스로 간주합니다. 논리적 이름을 사용하는 경계 오브젝트를 이벤트의 유스 케이스 플로우에 정의된 대로 사용합니다. 여기서는 해당 오브젝트를 클래스에 지정하지 않습니다.

모든 유스 케이스가 해당 상호작용 다이어그램을 가질 필요는 없으며 단지 선택적 중간 산출물입니다.

2.6              활동 다이어그램 사용 페이지 맨 위로 이동합니다.

활동 다이어그램이 유스 케이스에서 이벤트 플로우를 정의, 규정 및 완료하는 데 유용한 가치를 추가하는 경우, Rational Rose에서 모델링하는 것이 바람직합니다. 올바른 일반 규칙은 복잡한 유스 케이스(여러 대체 및/또는 예외 플로우 포함)에 대한 활동 다이어그램을 고려하는 것입니다. 활동 다이어그램은 유스 케이스에 플로우 결정 트리를 보여줍니다.

모든 유스 케이스가 해당 활동 다이어그램을 가질 필요는 없으며 단지 선택적 중간 산출물입니다.

3.                  유스 케이스 설명 방법 페이지 맨 위로 이동합니다.

유스 케이스에 대한 일반 정보 및 추가 가이드라인은 Rational Unified Process를 참조하십시오.

3.1               액터 가이드라인 페이지 맨 위로 이동합니다.

액터에 대한 일반 정보 및 추가 가이드라인은 Rational Unified Process를 참조하십시오.

3.1.1          각각의 구체적 유스 케이스는 하나 이상의 액터와 관련됨 페이지 맨 위로 이동합니다.

각각의 구체적 유스 케이스는 하나 이상의 액터와 관련됩니까? 그렇지 않은 경우 문제가 발생한 것입니다. 액터와 상호작용하지 않는 유스 케이스는 불필요한 유스 케이스이므로 제거하거나 해당 액터를 식별합니다.

경우에 따라, 두 개 이상의 액터가 유스 케이스 상호작용을 수행할 수 있습니다. 이 경우, 하나의 유스 케이스에서 여러 액터를 사용할 수 있는지 확인해야 합니다(액터 일반화 참조).

3.1.2          직관적이고 설명적인 액터 이름 페이지 맨 위로 이동합니다.

액터 이름이 직관적이고 설명적입니까? 사용자와 고객이 모두 해당 이름을 이해할 수 있습니까? 액터 이름은 해당 역할과 일치해야 하며 일치하지 않는 경우 이름을 변경해야 합니다.

유스 케이스 모델을 참조하여 유스 케이스의 모든 액터에 올바른 액터 이름을 사용하고 있는지 확인해야 합니다.

3.1.3          액터 이름의 일관적 사용 페이지 맨 위로 이동합니다.

유스 케이스 명세는 액터 이름을 일관되게 사용하여 작성합니다. 따라서 액터 이름이 명확하고 모호하지 않은지 확인해야 합니다.

"액터"를 일반적으로 나타내지 않고, 대신 액터를 고유하게 식별하거나 정의하기 위해 사용되는 실제 이름을 사용합니다. 액터 이름은 일련의 시스템 상호작용에서 수행되는 역할로 간주될 수 있습니다.

3.2               유스 케이스 이름 페이지 맨 위로 이동합니다.

유스 케이스 이름은 고유하고 직관적이며 설명적인 이름으로서, 유스 케이스에서 확보하는 값의 관찰 가능한 결과를 명확하게 정의해야 합니다.

유스 케이스 이름에 대한 올바른 검사는 고객, 비즈니스 담당자, 분석가 및 개발자가 모두 유스 케이스의 이름과 설명을 이해하는지 확인하는 것입니다. 이 경우, 액터 관점에서 관찰 가능한 값 결과를 정의해야 합니다.

각 유스 케이스 이름은 유스 케이스가 지원하는 동작에 대해 설명합니다. 이 이름은 수행되는 조치와 "조치가 수행되는" 키 요소를 모두 결합합니다. 일반적으로 간단한 동사와 명사의 조합입니다. 유스 케이스 이름은 유스 케이스를 트리거하는 액터의 관점에서 지정해야 합니다(예: "수강 신청", "개설 과정 선택").

3.3               유스 케이스 간략한 설명 페이지 맨 위로 이동합니다.

3.3.1          최소 하나의 단락 페이지 맨 위로 이동합니다.

유스 케이스에는 간략한 설명이 포함됩니다. 이 설명의 길이는 1 - 3개 단락입니다. 이 설명에는 유스 케이스의 핵심 목적, 값 제안 및 해당 개념에 대한 설명이 포함됩니다.

3.3.2          예제(선택적) 페이지 맨 위로 이동합니다.

가치가 있는 경우, 추가 컨텍스트를 제공할 수 있는 간략한 설명과 함께 간단한 "스토리" 예제가 포함될 수 있습니다. 이 예제는 일반적으로 기본 플로우를 따르며 필요한 경우 데이터 값을 포함합니다.

3.4               일관된 명령형, Will 사용 페이지 맨 위로 이동합니다.

유스 케이스의 시스템 요구사항은 명령형을 사용하여 작성됩니다. 이 경우, 요구사항을 일관되게 설명하기 위해 "Shall" 및 "Must" 대신 "Will"을 선택합니다. "should", "possibly", "etc", "might" 또는 "may"와 같이 요구사항이 선택적이거나 정의되지 않았음을 의미하는 수동적인 용어는 사용하지 않습니다.

3.5               용어집 용어 사용 페이지 맨 위로 이동합니다.

유스 케이스에서 사용되는 모든 비즈니스 용어는 프로젝트 용어집에 정의됩니다. 유스 케이스에 용어집에 없는 비즈니스 용어가 있는 경우 해당 용어는 다음과 같이 처리합니다.

1.       용어집에 추가됩니다(간략한 설명 포함, 최대 길이는 한 단락).

2.       용어집에 정의된 올바른 비즈니스 용어를 반영하여 유스 케이스에서 변경시킵니다.

3.6               "조치" 용어 사용 페이지 맨 위로 이동합니다.

3.6.1          시스템이 조치 옵션을 제공해야 하는 경우를 정의합니다. 페이지 맨 위로 이동합니다.

유스 케이스는 시스템이 액터가 선택할 수 있는 옵션으로 조치를 제공해야 하는 경우를 명시적으로 설명해야 합니다. 대부분의 경우, 사용 가능한 옵션은 기본 플로우의 일부로 제공되어야 하며 해당 대체 플로우의 첫 번째 명령문에서 시작점으로 참조되어야 합니다.

3.6.2          유스 케이스 전체에서 일관된 용어 사용 페이지 맨 위로 이동합니다.

새로 작성, 수정, 취소, 삭제, 확인 및 인쇄와 같은 용어는 유스 케이스에서 일관되게 사용합니다. 즉, 동일한 논리 조치를 다른 용어를 사용하여 설명하지 않습니다. 따라서 대체 플로우에서 사용되는 조치 용어가 기본 플로우에서 사용되는 용어와 일치하는지 확인해야 합니다.

3.7               액터 및 시스템 동작에 대한 단락 분리 페이지 맨 위로 이동합니다.

액터와 시스템 간의 상호작용 초점이 변경될 때마다 다음 동작 세그먼트가 새 단락으로 시작됩니다. 이때 액터와 시스템의 순서로 시작합니다.

문장은 '<액터 이름>은 xxxxx' 또는 '시스템은 xxxx' 형태로 시작됩니다. 액터 이름은 약어가 아닌 전체 이름을 정확히 표기해야 합니다.

3.8               대체 및 서브플로우 페이지 맨 위로 이동합니다.

각 대체 및 서브플로우는 플로우에 대한 가능한 모든 시작점을 명확하게 정의하며 플로우의 가능한 모든 종료점을 함께 포함합니다.

대체 플로우는 또한 종료점과 액터의 다음 위치(  기본 플로우의 특정 단계로 리턴 또는 종료 여부)를 명시적으로 표시합니다.

복잡한 동작으로 인해 이벤트 플로우가 복잡해지거나 단일 플로우의 길이가 실제 인쇄 페이지 범위를 벗어나는 경우, 서브플로우를 사용하여 명확성을 향상시키고 복잡도를 관리할 수 있습니다. 서브플로우는 세부 동작의 자체 포함된 논리 그룹을 서브플로우로 이동하고 이 동작을 이벤트 플로우 내에서 요약 양식으로 참조하여 작성합니다.

3.9               전제 조건 및 사후 조건 페이지 맨 위로 이동합니다.

유스 케이스 명세에는 유스 케이스가 시작되기 전(전제 조건)과 유스 케이스가 종료된 후(사후 조건) true 상태가 될 수 있는 조건(가정이라고도 함) 세트가 포함됩니다. 유스 케이스는 여러 가지 방법으로 종료될 수 있지만 그에 따른 "사후 조건"을 설명해야 합니다.

3.10           세부사항 누락에 대한 플레이스홀더 사용(TBD) 페이지 맨 위로 이동합니다.

정보가 아직 정의되지 않았거나 결정되지 않은 경우, 유스 케이스에는 해당 문제 또는 요소에 대한 참조가 포함되며 플레이스홀더가 포함됩니다. TBD

3.11            보충 스펙에 대한 참조 및 정의 페이지 맨 위로 이동합니다.

이벤트 플로우에서 정확히 설명할 수 없는 추가 요구사항이 있는 경우, 보충 요구사항으로 정의됩니다. 유스 케이스의 특정 요구사항의 경우, 유스 케이스 명세의 특별 요구사항 섹션에 정의됩니다.

특히 비기능적 특성을 갖는 요구사항과 같이 시스템 전체에 적용할 수 있는 요구사항의 경우, 하나 이상의 별도 보충 스펙 문서에 정의됩니다.

예를 들어, 다음과 같습니다.

신뢰성:           - 시스템은 일 주일에 7일, 하루 24시간 사용할 수 있어야 합니다.

                          - 시스템은 48시간의 MTBF 동안 실행되어야 합니다.

성능:       - 시스템은 예상 정상 로드 조건하에서 5초를 초과하지 않는 온라인 응답을 제공해야 합니다.

3.12            UI 프로토타입/디자인과의 상호 점검

유스 케이스 컨텐츠는 UI 프로토타입/디자인에 대한 상호 점검이 수행되어 유스 케이스 또는 UI 프로토타입/디자인에서 시스템 요구사항이 누락되지 않았는지 확인합니다. 유스 케이스를 변경해야 하는 경우, 이러한 점검을 수행합니다. UI 프로토타입에 대한 변경은 향후 조치에서 설명합니다.

3.13            예외 플로우(선택적)

다음 가이드라인은 예외 플로우 발견을 지원하기 위해 제공됩니다.

3.13.1      가능한 문제

유스 케이스의 각 단계에 대해 발생할 수 있는 문제를 고려하십시오. 각각의 고유 예외는 예외 플로우로서 캡처할 수 있습니다. 경우에 따라, 단일 예외 플로우를 유스 케이스에서 공통적으로 사용합니다(예: "제한시간"). 캡처할 중요한 정보는 예외 발생 시 해당 비즈니스 요구사항, 즉 액터가 수행해야 하는 조치입니다.