UseCase Description

1. 개요

유즈케이스 정의서는 "유즈케이스 다이어그램의 각 유즈케이스에 대해 처리 흐름을 상세히 정의한 문서"입니다. 이 문서는 통상 자연어로 기술됩니다. 그러나 자연어로 기술하라는 것이 정해진 것은 아닙니다. 문서의 내용이 유즈케이스의 처리 흐름을 정의한 것이기 때문에 그 목적을 만족하는 것이라면 형태에 구애받지는 않습니다. 즉, 수학적인 표식이어도 되고, 처리 흐름을 알 수 있는 도표로 표현되어도 됩니다. 단, 혼자만 알 수 있는 표현이면 안 되고, 모든 사람, 특히 전산지식이 없는 사람도 쉽게 이해할 수 있는 표현이어야 하고, 표준화가 전제되어야 합니다. 유즈케이스 정의서는 UML을 적용하는 대부분의 현장에서 작성하고 있으며, 이 산출물을 작성하는 것을 당연한 것으로 생각하고 있습니다.

유즈케이스 다이어그램은 SW 시스템의 외부환경과 SW 시스템간의 교류를 표현하는 다이어그램입니다. 유즈케이스 다이어그램은 사용자의 관점으로 작성하고, SW 지식이 깊지 않은 사용자라도 이해해야 하기 때문에 그 형식과 내용이 매우 간결하게 표현됩니다. 이런점 때문에 유즈케이스 다이어그램이 전달하고자 하는 내용은 부족한 점이 많습니다. 유즈케이스는 액터와 시스템의 일련의 교류 유즈케이스 다이어그램에서는 단지 교류가 있음을 나타내고 있을 뿐 시스템 내·외부간 교류의 세부적인 사항은 유즈케이스 다이어그램에서는 정의되지 않습니다. 따라서 보다 정확한 시스템의 이해를 위해서는 유즈케이스 다이어그램을 보완하여 내부의 자세한 처리 내용을 기술하여 정의하는 것이 필요합니다. 바로 유즈케이스 정의서는 이러한 필요성에 따라 유즈케이스의 처리 흐름을 상세하게 정의하는 문서인 것입니다. 그럼 유즈케이스 정의서를 작성하는 목적은 무엇일까요? 유즈케이스 정의서의 작성목적은 다음과 같습니다. 유즈케이스별 처리 흐름을 기술함으로써 SW 시스템에 대한 기능적 요구사항을 더욱 명확히 합니다. 유즈케이스 모델링 이후 계속되는 분석 작업의 기준을 세웁니다. 유즈케이스 정의서 작성과정에서 공통 서비스("include"관계의 유즈케이스)를 발견함으로써 유즈케이스 모델을 완전하게 합니다. SW 시스템 개발 후 사용자가 요구한 대로 개발되었는지를 테스트하는 기준을 정의합니다.

유즈케이스 정의서의 작성시기는 유즈케이스 다이어그램이 만들어진 직후입니다. 그러나 모든 UML로 작성되는 모델들이 그렇지만 한번에 완전한 산출물을 만드는 것은 아닙니다. 다른 모델들이 반복적으로 정련되는 것처럼 유즈케이스 정의서도 그렇습니다. 최초로 작성되는 시점은 유즈케이스 다이어그램이 작성된 직후이지만, 다음과 같은 시기에 정렬을 위해 내용이 수정됩니다. include관계, extend관계의 유즈케이스가 정의될 경우 이 경우 공통의 처리흐름을 기술한 부분이 독립적인 유즈케이스로 정의되는 것이므로 해당 부분이 수정되어야 합니다. 사용자의 요구사항이 변경되는 경우 시스템 기능에 대한 사용자의 요구사항은 때때로 변경됩니다. 그 경우마다 유즈케이스 다이어그램은 물론 유즈케이스 정의서는 변경되어야 합니다. SW 시스템의 설계 도중 시스템의 기능이 변경될 경우 SW 시스템의 설계가 진행되면서 기술상의 이유로 시스템의 기능이 변경될 수 있습니다. 이럴 경우 역시 유즈케이스 다이어그램은 물론 유즈케이스 정의서는 변경되어야 합니다. 유즈케이스 정의서 작성 시기를 결정한 후 정의서를 작성하기 위해서는 먼저,유즈케이스 다이어그램이 그려져 있어야 합니다.

유즈케이스 정의서는 다음과 같이 구성됩니다. 유즈케이스 정의서는 통상 자연어로 기술되기 때문에 본 구성은 문서의 목차와 비슷합니다.                                                        목차                     Use Case 명 : 유즈케이스 정의서 개요                     이벤트흐름 : 기본흐름, 선택흐름                     특별요구사항                     사전조건                     사후조건                     향후조건 유즈케이스 정의서의 표준양식 유즈케이스 정의서의 표준 양식은 없다고 할 수 있습니다. UML의 사양을 정의한 공식문서인 "OMG Unified Modeling Language Specification"에는 유즈케이스 정의서(Use case Specification)에 대한 표준은 언급하고 있지 않기 때문입니다. 유즈케이스 정의서의 내용은 UML을 더 풍부하게 응용하는 차원이기 때문에 적절한 형식을 정의하여 쓰면 됩니다. 다만, RUP(Rational Unified Method)라는 UML적용 방법론에서 정의된 양식이 많이 쓰이는 실정입니다. 여기에서 소개하는 내용도 RUP(Rational Unified Method)에서 제시한 양식을 소개합니다. 또한 차별성을 위해 사례는 모회사에서 자체적으로 표준으로 쓰는 것을 해설과 함께 소개하도록 하겠습니다. 앞서 언급한 UML의 사양을 정의한 공식 문서는 인터넷 주소 "www.omg.org"에서 무료로 공개하고 있습니다.

 

Use case 명 유즈케이스 정의서의 제목 부분에 해당합니다. 유즈케이스 정의서는 유즈케이스 하나마다 작성됩니다. 따라서 유즈케이스 정의서가 어떤 유즈케이스에 대한 것인지를 명시합니다. 이 내용 후에는 유즈케이스가 하는 일에 대한 간략한 개요를 기술합니다. 이벤트 흐름(Flow of events) 유즈케이스는 액터의 이벤트로 그 동작을 개시합니다. 이벤트란 응답을 유발하는 사건을 의미합니다. 예를 들면, "상품정보 요청" 이벤트는 시스템으로부터 상품정보를 제공하는 응답을 유발합니다. 이렇게 SW시스템 외부의 이벤트와 그 이벤트에 대한 시스템의 응답을 알면 시스템이 하는 일을 알 수 있습니다. 이렇게 이벤트 흐름(Flow of events)부분은 액터와 유즈케이스 사이의 이벤트 흐름, 즉 처리 흐름을 상세하게 정의하는 부분입니다.

자, 그러면 이벤트 흐름의 종류인 기본 흐름(Basic flow), 선택 흐름(Alternative flow)에 대하여 자세히 살펴봅시다.

    기본흐름(Basic flow)

이 유즈케이스가 실행되면 반드시 발생하는 기본적 처리 흐름을 기술합니다. 즉, 경우에 따라서 조건에 따라서 실행되는 처리 흐름이 아닌 무조건적으로 실행하는 처리 흐름이 기술되어야 합니다. 또한 처리 흐름 중에 반드시 하나를 선택해야 할 경우에는 대표적인 선택과 그에 따른 처리 흐름을 기술합니다. 이벤트 흐름이므로 기술되는 방식은 외부 이벤트글, 그에 대한 유즈케이스의 응답이 쌍으로 기술되도록 합니다. 각각의 처리 흐름을 구분하고 번호를 매겨 처리 순서도 표현합니다. 위 그림에서 처리 1과 처리 3 부분이 기본 흐름에 해당됩니다.

  선택흐름(Alternative flow)

기본 흐름과는 달리 조건과 상황에 따라 추가적으로 혹은 달리 실행되는 처리 흐름에 대하여 기술하는 부분입니다. 유즈케이스가 액터의 선택 결과에 따라 다른 처리 흐름으로 진행해야 할 경우가 있을 때 기술합니다. 선택 흐름은 기본 흐름에서 가지 쳐 나온 처리 흐름입니다. 위 그림에서 처리 2에 해당되는 부분이 선택 흐름에 기술됩니다.

특별 요구사항(Special Requirement) 이 유즈케이스가 실행될 때 기능 외의 특별한 요구사항을 기술하는 부분입니다. 특별 요구사항에 정의될 수 있는 것들은 다음과 같습니다. 표준에 관한 요구사항(어플리케이션 표준) 품질과 관련된 요구사항(성능, 신뢰성 등) 기술관련 요구사항(OS, 호환성, 기타 설계 제한사항) 등 사전 조건(Pre-Conditions) 유즈케이스가 실행되기 위한 전제 조건을 명시하는 부분입니다. 이 사전 조건을 만족하지 못하는 한 유즈케이스는 실행될 수 없습니다. 사전 조건은 다른 유즈케이스가 실행된 후에 만족하는 경우가 많습니다. 이 부분도 자연어로 기술되고 사전 조건이 여러 개인 경우 번호를 붙여 나열합니다. 사후 조건(Post-Conditions) 유즈케이스가 실행한 후의 시스템 상태가 변화한다면 이를 명시하는 부분입니다. 시스템의 상태가 변화한다는 것은 다른 유즈케이스의 실행에 영향을 주는 변화를 의미합니다. 이러한 사후 조건을 기술하는 유즈케이스는 많지 않습니다. 확장 조건(Extension Points) 유즈케이스가 다른 유즈케이스를 <<extend>>할 경우 다른 유즈케이스를 실행하는 조건을 정의합니다. 즉 특정 조건이 만족하면 다른 유즈케이스를 사용(실행)하는 extend 관계를 가질 경우, 그 조건을 명시하는 부분입니다. extend 관계가 없는 유즈케이스의 경우 이 부분은 생략됩니다.

다음 제시되는 것은 RUP의 Use case specification 템플리트를 기본으로 해서 정의한 양식사례입니다. 실제 프로젝트에서 작성한 것이며, 현업에 적용하기 쉽게 정의된 형태입니다. 유즈케이스 정의서 시스템명 XX시스템 작성일 2001.09.14 페이지 1/2 Use Case 명 개인고객등록 작성자 홍 길 동 1. 개요      영업담당자가 개인고객(키맨, 협력자, 가망고객, 가족, 친구)의 정보를 등록한다. 2. Relationships      ▶ Initiator                 영업담당자      ▶ Pre-condition      ▶ Post-condition 3. Flows of Events      3.1 Main Flows            1. 영업담당자가 고객유형(N-1)을 '키맨'으로 선택한다(A-1).            2. 영업담당자가 고객소속구분(N-2)을 'XXX'로 선택한다(A-2).                         3. 시스템은 XXX 리스트를 로드한다.            4. 영업담당자가 등록하고자 하는 개인이 속한 회사를 선택한다.            5. 영업담당자가 개인고객정보(N-3)를 입력하고 저장을 요청한다.                         6. 시스템은 성공적으로 저장되었음을 알려주고 Use Case를                             종료한다.      3.2 Alternative Flows        A-1. '가족' 또는 '친구'를 선택할 경우            1. 영업담당자가 고객유형을 '가족'(또는 '친구')로 선택한다.                → Main Flow의 5번으로        A-2. '활동담당사업장'을 선택할 경우            2. 영업담당자가 고객소속구분을 'YYY'로 선택한다.            3. 시스템은 YYY를 로드한다.            4. 영업담당자는 개인고객이 속한 회사를 선택한다.                → Main Flow의 5번으로        A-3. '개별'을 선택할 경우(가망고객의 경우만 가능)            1. 영업담당자가 고객소속구분을 '개별'로 선택한다.                → Main Flow의 5번으로      3.3 Exception Flows 4. Note       N-1. 고객유형 : 키맨, 협력자, 가망고객, 가족, 친구       N-2. 고객소속 구분 : 활동담당 기업, 활동담당 사업장, 개별(가망고객의 경우만)       N-3. 개인정보 항목 구분 항목   성명, 주민등록번호(미입력시 Warning) 기본정보 실제생일(양/음), 결혼기념일, 취미, 혈액형, 출신지, 종교, 주량, 흡연, Mobile Phone, e-mail 자택정보 주소, 전화, 부인생년월일(양/음), 가족특이사항(부인/ 자녀-출산, 진학,취직, 결혼 등) 직장정보 직장명, 주소, 부서명, 직책, 직급, 직업, 전화, FAX, 입사일 학력/재무정보 출신고, 출신대, 대학전공, 대학원, 대학원전공, 경력사항, 년소득, 특기사항

유즈케이스 정의서의 작성단계는 특별히 존재하지는 않습니다. 정해진 목차의 순서에 따라 작성하면 됩니다. 작성하는 시점에 결정되지 않은 항목에 대해서는 생략하고 넘어간 후 추후 작성하도록 합니다. 유즈케이스 정의서 작성 시 주의사항은 다음과 같습니다. 유즈케이스 정의서 작성 시 간결하고 명료한 표현을 사용해야 합니다. 불 필요하게 장황한 설명을 하거나 처리 흐름을 명확하지 않게 표현해서는 안됩니다. 유즈케이스 정의서는 액터와의 상호작용에 초점을 맞추어 기술해야 합니다. 즉, 액터의 요구(이벤트)와 유즈케이스의 응답의 관점에서 기술합니다. 물리적인 구현 관점의 용어가 언급되지 않도록 주의해야 합니다. 유즈케이스 정의서는 구현 사양을 기술한 것이 아닙니다. 이후 어떤 구현 환경으로도 구현될 수 있다는 생각으로 정의해야 합니다. 또한 유즈케이스 정의서는 SW 지식이 없는 사람도 이해할 수 있어야 합니다. GUI(Graphic User Interface) 용어 화면, 버튼, 프레임, 그리드, 리스트, 더블클릭 등 시스템 용어 EJB, Socket, JDBC, JNDI 등 Entity, Table, Row, Column 등 모호한 용어나, 지나치게 추상화된 처리 흐름으로 기술하지 말아야 합니다. 유즈케이스 정의서 작성 도중 유즈케이스 다이어그램을 수정해야 할 경우에는 바로 수정합니다. 단 수정의 결과로 기능의 변경으로 인해 사용자와 합의가 필요한 경우, 합의를 먼저 득한 후 수정합니다.