dev 2.3 유스케이스정의서

1. 개요(Overview)

유스케이스 다이어그램에서 정의된 유스케이스 별로 액터로부터 시작하여 시스템 범위내에 있는 특정 기능(functionality)을 수행하는 일련의 작업흐름(일련의 사건) 또는 트랜잭션의 순차적인 흐름을 기술한다.

1. 작성기준
   1. 미작성시 영향

• 유스케이스로 도출된 사용자 요구사항에 대해 사용자와 시스템간의 상호작용과 트랜잭션의 순차적인 흐름을 파악하기 어렵다.
• 해당 유스케이스가 수행되기 전후의 조건들을 파악하기 어렵다.
• 공통 비즈니스 트랜잭션을 파악하기 어렵다.
• 향후 개발할 기능에 대한 정의가 불충분하여 어느 정도까지 개발을 해야 하는 지가 명확하지 않아서 문제의 소지가 있다.

1. 1. 작성이 불필요한 경우

N/A

1. 1. 제출시 고려사항

N/A

1. 작성항목
   1. 시스템명/업무명

• 프로젝트에서 분류한 시스템명과 업무명을 기술한다.

1. 1. 작성자/작성일

• 작성내용이 명확하지 않은 경우 작성자에게 작성내용의 의미를 확인하고, 작성내용에 대한 작성일을 확인하기 위한 목적으로 작성자와 작성일을 기재한다.

1. 1. 유스케이스 명

• 해당 유스케이스 다이어그램에 기재된 유스케이스 명과 동일하게 부여한다.

1. 1. 유스케이스 시나리오
2. 개요

• 유스케이스가 수행하는 기능을 간략하게 기술한다.

1. 관계(Relationships)

• 관계(Relationships)는 액터, 선행 조건 및 후행 조건으로 구성된다.
• 액터(Initiator) : 유스케이스를 동기화하는 액터를 나열한다.
• 선행 조건(Pre-condition) : 유스케이스의 성공적인 완료를 보증할 수 있는 사전조건을 기술한다.
• 후행 조건(Post-condition) : 유스케이스가 성공적으로 종료되었음을 보증하는 완료조건을 기술한다.

3) 처리 흐름(Flow of Event)

• 상호작용하는 액터와 유스케이스간의 관계를 표현한다.
• 고객이 이해할 수 있는 업무용어를 사용하며, 가능하면 용어사전에 정의된 용어를 사용하여 작성하도록 한다.
• 애매한 표현은 삼가한다. (예를들면, 기타, 정보 등).
• 이해를 쉽게 하기 위하여 그림을 삽입할 수 있다.
• 문장은 간결하고 명확하게 기록한다.
• 주어, 목적어, 서술어를 정확하게 기술한다.
• 필요 없는 수식어나 미사어구는 사용하지 않는다.
• 장표나 업무적으로 사용되는 비즈니스정보 데이터는 빠짐없이 기술한다.
• 해당 Use case 의 범위에 속하는 것들을 기술한다.
• 다음과 같은 내용으로 기술한다.
• 언제 어떻게 유스케이스가 시작되고 종료하는가?
• Indentation을 사용하여 Actor의 행위와 시스템의 반응 기능이 구분되도록 작성한다.
• 해당 flow에서 전달되는 비즈니스 attribute 등을 [ ]안에 명시하도록 한다.
• 해당 flow에서 연결되는 유스케이스와 Alternative, Exception flow의 이름은 ( )안에 명시하도록 한다.
• 수행 처리 흐름은 다음과 같이 기본흐름, 선택 흐름, 예외 흐름으로 구성된다.

1. 1. 기본 흐름(Main Flows)

• 유스케이스의 Overview를 나타내는 Normal한 경우의 Flow of Event를 기술한다.

1. 1. 선택 흐름(Alternative Flows)(선택)

• 기본 흐름(Main Flows)과 다른 프로세스를 통해서 액터가 원래 의도했던 결과값을 충족시키는 경우를 기술한다. 선택 흐름(Alternative Flows)이 다수 개일 경우에는 A-1, A-2… 등으로 번호를 부여하여 구분한다. 하나의 선택 흐름(Alternative Flows)이 다수의 기본 흐름(Main Flows)을 커버하는 경우에는 해당 기본 흐름(Main Flows)에 같은 선택 흐름(Alternative Flows)의 이름을 넣어준다.

1. 1. 예외 흐름(Exception Flows)

• 기본 흐름(Main Flows)으로 진행하다가 원래 의도했던 결과를 얻기에 불충분한 경우 또는 기본 흐름(Main Flows)에서 특정 step을 제외할 수 있는 경우에 대한 예외적인 경우에 대한 처리 흐름를 기술한다. E-1, E-2… 등으로 번호를 부여하여 구분한다.

1. 특별 요구사항(Special Requirement)(선택)

• 유스케이스에 대한 기능 외적인 또는 설계/개발 시 고려해야 할 요구사항 등을 기술한다.

5) 주석(Note)(선택)

• 유스케이스에 대한 이해에 도움이 되는 고려사항이나 참조사항을 기술한다.

1. 시나리오(Scenario)(선택)

• 객체간의 상호작용으로써 수행 처리 흐름(Flow of Event)을 기술한 것이다.
• 유스케이스의 실행을 위해 필요한 객체, 클래스, 객체간의 상호작용을 찾는 데 도움을 주기 위해 작성한다.
• 또 시나리오는 고객과의 훌륭한 의사소통의 매체로 최종 사용자 또는 관련 도메인 전문가가 그들의 기대를 개발조직으로 전달하고자 유용하게 활용될 수 있다.
• 상세화된 시나리오는 해당 유스케이스에 대한 테스트 시나리오로 활용될 수 있다.

1. 작성시 고려사항

• 유스케이스내에 유스케이스와 관련된 비기능요구사항을 함께 기술할 수 있다.
• 유스케이스 정의서는 액터와의 상호작용에 초점을 맞추어 기술한다. 액터의 요구와 유스케이스의 응답의 관점에서 기술한다.
• 물리적인 설계 및 개발 관점의 용어가 언급되지 않도록 주의한다.
• 기술적인 관점이 아닌 사용자의 사용관점에서 기술하도록 한다.
• 사람이나 직책이 아니라 Role 중심으로 Actor를 정의한다.
• 기본 흐름(Main Flow)에 대한 처리 흐름을 이해가 쉽도록 구체적으로 정의한다.
• 액터(Actor)의 행위와 시스템의 행위를 구분되어 작성한다.
• 유스케이스 정의서의 기술내용을 고객이 이해할 수 있는 용어로 작성한다.
• 유스케이스 정의서의 기술내용은 유스케이스 다이어그램과 일관성을 유지한다.
• 유스케이스를 사용하는 액터(Actor)를 정의한다.
• 업무기능과 무관한 UI 처리흐름이나 설계 개발 관점의 기술은 배제한다.
• 유스케이스 수행의 선행조건, 후행조건이 있다면 이를 표시한다.
• 유스케이스 처리 흐름을 시작하는 Business Event에 대한 설명을 포함한다.
• 문장은 간결하고 명확하게 기록한다.
• 필요없는 수식어나 미사어구는 사용하지 않는다.
• 장표나 업무목적으로 사용되는 정보 데이터는 빠짐없이 기술한다.
• 모든 유스케이스에 대해서 고려되었는지 확인한다.

Tip
유스케이스 정의서에서 Basic Flow / Alternative Flows / Exceptional Flows를 구분하는 기준은 무엇인가?
Basic Flow는 한 유스케이스가 initiator에게 서비스를 제공하기 위한 가장 기본적인 시나리오를 나타낸다. 각 유스케이스는 반드시 하나의 Basic Flow를 갖는다. Basic Flow 내에서 Sub-Flow가 있을 수도 있다. 정의서를 작성하다보면 Basic Flow가 복수 개의 경우가 있는데, 이 때에 Sub-Flow를 활용하도록 한다.
Alternative Flows는 Basic Flow 중에 어떤 조건에 의해 분기되지만, 결과적으로 유스케이스가 Success 하는 시나리오이다. 즉, Basic Flow에서 분기된 이후 다시 Basic Flow로 되돌아간다.
Exceptional Flows는 Negative한 조건에 의해 분기되어 유스케이스가 Fail 되는 시나리오이다. 이 Flow에서는 Fail 된 경우에 수행해야 하는 기능을 명확히 명시해야 한다. 따라서 이와 같은 구분을 명확히 하기 위해 유스케이스 종료를 하나의 Step으로 명시하는 것이 좋다.
요구분석단계에서는 가급적 Basic Flow만 기술해도 된다.
유스케이스 정의서에서 어떤 조건에 대해 Pre-Condition에 기재하는 경우와 Basic Flow에 기재하는 경우의 차이점은 무엇인가?
예를 들어 "대출이 있는 고객"의 경우 Pre-Condition에 기재되었을 때는 이미 대출유무에 대한 검사가 어디에서인가 이루어졌다는 의미이고, Basic Flow에 기재하는 경우는 해당 유스케이스가 수행될 때마다 대출유무 검사가 일어나고 이로 인한 Flow의 분기가 일어날 수도 있다는 의미이다.

1. 관련기법(Related Technique)

N/A