유스케이스 명세서

• 유스케이스가 뜻하는 시스템의 기능을 간결하고 명확하게 기술하 ㄴ것
• 개요 작성시
  • 주어: 유스케이스를 사용하는 액터
  • 간결하게 기술하되 유스케이스가 제공하는 모든 기능을 명시

관련 액터

• 유스케이스와 상호작용을 하는 액터
• 주액터와 보조액터
  • 주액터: 실제 유스케이스를 사용하는 액터
  • 보조액터: 주액터를 제외하고 해당 유스케이스와 연관된 모든 액터들

조건

선행조건 Precondition

• 유스케이스의 수행이 시작되기 위하여 필요한 조건
• 선행조건이 만족하지 않으면 유스케이스의 동작이 시작되지 않
  음

예시

• 유스케이스명
  • 강좌 삭제
• 선행조건
  • 1) 수업 담당자는 로그인된 상태이다.
  • 2) 삭제하려는 강좌에 대한 강의가 개설되어 있지 않아야 한다

후행조건 Postcondition

• 수행이 완료된 후에 만족되어야 하는 조건
• 해당 유스케이스의 정상 동작에 대한 최소한의 판단 기준
  • 만약 이 조건이 만족되지 않으면 시스템이 정상적으로 동작했다
    고 판단하기 힘들다.

예시

• 유스케이스명
  • 출석부조회
• 후행 조건
  • 화면에 사용자가 요청한 강의의 출석부가 등록된 출석상황은 변경되지 않아야 한다

이벤트 Event

• 이벤트는 항상 발생의 주체가 있다.
• 이벤트는 상대가 발생된 이벤트에 대해서 어떤 형태로든 반응
  (response)을 보이는 것
  • 발생한 이벤트에 대한 반응도 또 다른 이벤트로 표현 된다.

유스케이스의 이벤트 흐름 Flows of Events

• 유스케이스의 수행: 액터와 시스템이 발생시키는 이벤트의 연
  속
• 이벤트 흐름은 항상 액터가 발생시킨 이벤트에 의해서 시작
• 이벤트 흐름의 첫 문장에 기술되는 액터 = 유스케이스 다이어그
  램의 액터
• 이벤트 흐름은 액터가 발생시키는 이벤트와 시스템에 의한 이벤
  트가 번갈아 가면서 기술된다.

이벤트 흐름의 종류

1. 기본 흐름

• 
• 유스케이스의 여러 시나리오 중에서 가장 일반적이고 정상적인 상황을 나타내는 하나의 이벤트 흐름

2. 대안 흐름 Alternative Flow

• 하나의 유스케이스에서 기본 흐름이 표현하는 상황을 제외한 모든 다른 상황
• 수행이 끝나면 기본 흐름으로 돌아오는 경우도 있고 대안 흐
  름에서 종료되는 경우도 있다.

2-1. 선택 흐름

• 1) 사용자의 선택에 의한 선택 흐름
  • 사용자가 선택할 수 있는 여러 상황이 있는 경우, 어떤 상황을
    선택하는 가에 따라서 이 후의 이벤트 흐름이 달라질 수 있다.
    - 유스케이스명: 수강신청
    - 이벤트 흐름: ... 5. 수강신청 내용이 옳은지 확인하는 메세지 출력. 6. 사용자가 수강 신청 내역이 옳다고 확인한다 ...
    - 대안 흐름: 6-1. 사용자가 취소버튼을 누르는 경우, 시스템은...
• 2) 시스템 상태에 의한 선택 흐름
  • 사용자의 선택에 따라서 선택 흐름이 발생하는 것과 더불어,
    시스템의 상태에 따라서 다른 이벤트 흐름이 수행되는 경우
    도 있다.
    - 유스케이스명: 수강신청
    - 이벤트 흐름: ... 8. 시스템은 수강 정원을 확인하고 시스템에 수강 정보를 저장한다...
    - 대안 흐름: 8-1. 수강 정원이 초과된 경우, 시스템은...
• 3) 데이터 종류에 의한 선택 흐름
  • 상이한 데이터를 다룬다고 해서 별도의 유스케이스로 파악하
    지 않고, 각 상이한 데이터를 다루는 것을 별도의 선택 흐름으
    로 기술한다.
    - 유스케이스명: 학생 등록
    - 이벤트 흐름: ... 3. 학사 관리자는 이름, 주민등록번호, 전화번호, 학과를 입력하고 “입력”버튼을 선택한다...
    - 대안 흐름: 3-1. 대학원생을 등록할 경우, 학사관리자는 추가정보를 입력한다...

2-2. 예외 흐름

• 1) 사용자의 무효한 값 입력에 의한 예외 흐름
• 2) 입력 또는 처리 시간 초과에 의한 예외 흐름
• 3) 시스템 오류

비기능적 요구사항

• 유스케이스와 관련된 비기능적 요구사항을 기술
  • 성능, 신뢰성, 편의성, 보안 및 인증체계, 가용성 등
• 예시
  • 유스케이스명: 성적 증명서 출력
  • 비기능적 요구사항
    - 성능: 성적 증명서는 사용자가 “증명서 출력”을 선택한 뒤 15초 이
    내에 출력되어야 한다.
    - 가용성: 성적 증명서 출력은 아침 9시부터 오후 6시까지 가능해야
    한다.

유스케이스 모델의 구조화

액터 사이의 일반화 관계

• 
• 여러 액터들의 의미를 좀 더 명확하게 하고, 다이어그램도 보다 간결하게 작성될 수가 있다
• 액터가 사람모양이지만 사람이 아닐수도있다 (ex 도서판매시스템)
• 상속개념 ─▷
  • 교수, 학생 ─▷ 대출자

액터 사이의 연관 관계

• 
  • '창구직원'이나 '현금자동인출기'가 굳이 필요하지 않음
• 다른 액터에 의한 간접적인 시스템에의 접근을 의미
• 필수적인 표기 사항은 아니다

유스케이스 사이의 포함 관계 ★

• <<스테레오타입>>

1. 포함관계 ≪include≫

• 여러 유스케이스들에서 중복적으로 발생하는 이벤트 흐름을 표현하기 위해서 사용한다
• 
  • 입금, 출금 전 카드판독 필수
  • 카드판독도 별도의 유즈케이스가 될 수 있음
  • 입금의 유즈케이스에 카드판독 유즈케이스가 추가될 수 있음

2. 확장관계 ≪extend≫

• 한 유스케이스에서 흐름이 특정 조건에서 여러가지 형태로 분류될 경우에 사용하는 관계
• 
  • 결제 기능의 확장: 실시간계좌이체, 신용카드 지불

확장 관계 vs. 대안 흐름

확장 관계 vs. 포함 관계

Use Case 보고서 점검사항

유스케이스 간에는 Association 관계(→)를 정의할 수 없다

• 흐름을 표현하기 위해 사용했을 경우:
  • 수행 Actor를 정의하여 독립적인 Use Case로 분리

Actor의 모호성

• 
• 인사관리자, 사용자 관리자의 역할을 명확히 나누어야함

Association의 navigability의 잘못된 표현

• 
• 외부시스템인 경우는 그쪽으로 화살표가 진행됨
• 도서주문 use case는 고객이 수행 actor, 결제시스템은 수행을 협조하는 외부 시스템 actor
  • 외부시스템 actor는 일반적으로 수행actor로 정의하지 않는다.

Use Case 추출시 대응되는 필요기능 누락

잘못된 Use Case 추출

• DB 관리와 웹 서버관리는 관리자에게 필요한 기능이나 설계하려고 하는 시스템 자체의 기능으로 존재할 필요성은 없음
• Use Case는 시스템을 이용하는 사람(고객, 회원...tetc)의 입장에서 추출되어야함

불명확한 Use Case명

잘못된 Acotr추출

• 도서 대출 시스템 개발시
  • 도서 대출 시스템은 액터가 될 수 없음
  • 엑터는 개발될 시스템과 상호작용하는 모든 대상
    • 개발될 시스템 자체는 엑터가 아님

설명출처

부산대학교 Software Engineering Laboratory

게시판 유스케이스다이어그램

1차

• 
• 타원 하나 = 유스케이스 = 후에 유스케이스 명세서가 하나씩 생겨야함
• 내용입력 (제목, 작성자, 내용입력)과 같은 세세한 부분까지 모두 하려면 너무 세밀해짐

2차 수정본

• 
• 큰 기능 중심으로 간략하게 하는게 좋다.

starUML