✅ 유스케이스

• 요구사항을 사용자 중심 시나리오 분석을 통해 흐름을 나타내는 것
• 시스템의 동작을 모형화하는 것.
  • 시스템 사용의 사례로서 시스템의 사례들을 그려 놓은 것
  • 시스템의 외부에서 본 기능을 명확하게 정리해나가는 방법이다.
    • 내부 과정은 구현에서고려되는 사항임.
  • 개발자와 사용자와의 상호작용을 표시한 것
  • 목적은 시스템의 기능을 정의하는 것.

🔽 유스케이스(사용사례)

• 도메인 분석과 모델링 사이의 관문 (도메인 분석은 시스템 전반적인 환경을 말하고 실제로 그 환경에서 어떻게 작동할 것인가를 모델링)
• 유스케이스가 중요한 이유는 모델링과 도메인 분석의 설계를 제공하는 빌딩 역할을 하기때문임.
• 도메인 분석의 결과를 액터, 유스케이스, 관계들로 구성된 시스템 명세로 매핑하는 작업

🔽 유스케이스 소개

• 시스템의 사용자에게 서비스를 제공하기 위한 상호작용의 단위
• 사용자 또는 외부 시스템이나 기타 요소들이 시스템과 상호작용 하는 다이얼로그를 모델링
• 시스템 설계자.테스트 프로그래머들이 의사 교환하는데 유용
• 소프트웨어 개발자와 이해 당사자 간의 계약

✔유스케이스 구추 시 주의 사항

• 시스템 내부를 모델링 하는 것이 아님
• 비기능적 요구를 찾아내는 데 효과적인 방법이 아님
• 시스템의 흐름도가 아님 (**** 시스템 흐름도 같은 경우에는 데이터까지 고려해서 흐름을 짜는 것임.)
• 단계적 분할이 아님
• ‘어떻게’가 아니라 ‘무엇을’ 시스템이 하는가 를 담는 것

🔽 유스케이스 모델링

• 사용자 중심 요구사항 모델링
  • 작업 중심적 : 다이어그램으로 요구사항을 이해
• 유스케이스는 각각 독립적
  • 단순한 유스케이스 나열 : 전체적인 시스템 요구사항 이해가 어려울 수 있음
  • 비기능적인 요구사항은 표현이 어려움
• 표준 그래픽 표기
  • 커뮤니케이션 개선, 해석의 리스크 감소

✔유스케이스 다이어그램

• 시스템의 기능을 나타내기 위해 사용자의 요구를 추출하고 분석하는데 사용
• 구성
  • 유스케이스 - 시스템 기능
  • 액터 - 시스템과 상호작용 하는 것(사용자이기도 하고 시스템이기도 함)

• 액터와 유스케이스를 정하는 것은 시스템의 범위를 정하는 것

✔유스케이스 기호

• 시스템의 범위
• 액터
  • 시스템의 외부에 있으면서 시스템과 상호작용을 하는 사람 또는 다른 시스템
• 유스케이스
  • 시스템이 액터에게 제공해야하는 기능의 집합
• 관계
  

✔액터와 유스케이스

• 액터
  • 시스템과 상호작용하는 외부 엔티티, 구별되는 이름과 설명이 필요
• 액터가 될 수 있는 것
  • 사용자가 맡은 일, 다른 시스템
• 액터를 찾기 위한 질문
  • 시스템의 지원을 받는가?
  • 어떤 사용자 그룹이 시스템의 주요기능을 사용하는가?
  • ,,, 보수와 관리 등의 부수적 기능을 사용하는가?
  • 외부 하드웨어나 소프트웨어 시스템과 동작하는가?

<📖연습📖>

인터넷 서점 시스템의 액터가 될만한것은?

1. 온라인 고객 2. 택배 직원 3. 창고직원 4. 신용카드 회사 5. 택배회사 6. 납품업자

• 유스케이스
  • 액터의 입장에서본 시스템의 동작(외부동작)
  • 액터가 볼 수 있는 결과를 내는 이벤트의 집합
  • 다른 유스케이스를 가동시킬 수 있음
• 유스케이스 찾기
  • 여러 개별 시나리오를 묶은 것 (오류, 예외케이스도 포함)

✔시나리오 구성

• 개발자와 사용자가 함께 작성 (도메인 분석도 같이 이뤄지면 더 좋음)
• 현재의 응용 도메인에 대해 기술한 여러문서를 이용
• 필요질문?
  • 어떤 작업을 수행하기를 액터가 원하는지?
  • 액터가 원하는 정보는 무엇인지?
  • 누가 데이터를 생성하는지, 데이터는 조작 삭제 될 수 있는 지, 언제 이런 작업이 일어나는지.
  • 액터가 시스템에 정보를 알리는데 필요한 것은? 얼마나 자주 또 언제 이런 작업이 일어나는지
  • 액터가 시스템으로부터 정보를 알아내는데 필요한 이벤트는?이런 사건의 빈도는?

✔유스케이스와 시나리오

<연습>

유스케이스 찾기

온라인 고객의 유스케이스 : 책 주문, 주문 취소

타이머의 유스케이스 : 주문 취소 시간

신용카드 회사 : 사용 승인, 사용 거부(오류나 예외케이스)

창고직원 : 포장 및 배송 주문, 상품 재주문

택배직원 : 주문 배달

🔽 유스케이스 명세

• 대상 시스템이 제공하여야 할 서비스를 시간이 경과되는 순서로 정렬하여 기술 한 것.
  • SW에 대한 요구정의를 사용자 관점으로 바꾸어 상호작용 사건의 시나리오로 나타내는 것.
• 시나리오가 시작될때 외부 시스템이나 사용자가 기대하는 거
• 시나리오에 일어나는 사건에 대한 기본 흐름
• 문제가 발생되는 비정상적인 사건에 대한 대안 흐름
• 동시에 병행으로 일어나는 다른 활동에 관한 정보
• 시나리오가 종료되었을 때 시스템의 상태에 대한 정보

EX)

🔽 유스케이스 관계 찾기

• 이벤트 흐름
  • 이벤트는 시스템이 필요한 동작으로 그 동작이 작동 되는 형태를 나타내는 것
• 관계를 이용하여 모형의 복잡도를 줄이고 이해도를 높임.
• 관계 종류
  • 포함 : 정상적인 이벤트와 예외적인 이벤트를 분리
  • 확장 : 유스케이스 사이의 중복을 제거

✔포함 관계

• 유스케이스 사이의 중복을 제거
• 어떤 유스케이스가 다른 유스케이스를 포함하는 관계
• 꼭 필요하지 않은 이벤트 묶음을 떼 놓을 때, 두개 이상의 유스케이스에 공통적인 요소를 덜어낼 때 사용
• 예금 → 고객인증 ← 현금인출 : 예금하려면 인증은 필수, 현금인출할때도 인증은 필수이므로 중복인거임 여기에 include를 주는 것.

✔확장 관계

• 유스케이스가 일정한 조건 아래 확장된 동작을 포함한다면 다른 유스케이스를 확장하는 관계에 있다.
• 서로 필요한관계!!! (~한다면 같은 조건부)
• 결제 ← 멤버쉽할인 : 결제과정에 멤버십이 있는 경우 할인이 적용

✔연관 관계 (기본적인 사항)

✔일반화 관계

✔전체적인 유스케이스 다이어그램

🔽 유스케이스 다이어그램 작성 순서

1. 액터식별 : 사용자 식별, 외부 시스템 식별
2. 유스케이스 식별 : 액터가 요구하는 서비스 식별, 액터가 요구하는 정보 식별, 액터가 시스템과 상호작용하는 행위 식별
3. 관계 정의 : 액터와 유스케이스간의 연관관계 , 포함, 확장, 일반화 정의

✔액터 식별

위에 내용 있음

✔유스케이스 식별

• 액터가 원하는 시스템 제공 기능은 무엇인가?
• 어떤 정보를 생성, 수정, 조회, 삭제를 하고 싶어하는가?
• 갑작스러운 외부 변화에 대해 어떤 정보를 필요로 하는가?
• 어떤 기능을 제공하면 일상작업이 효율적이고 편리해지는가?
• 모든 기능 요구사항을 만족할 수 있도록 유스케이스가 모두 식별 됐는가?

✔관계 식별

• 연관 관계(Association)
  • 액터와 유스케이스 간에 상호 작용이 존재하는가? 포함 관계(Include)
  • 이 유스케이스를 실행하기 위하여 반드시 실행되어야 하는 유스케이스가 존재하는가?
• 확장관계(Extend)
  • 이 유스케이스를 실행하기 위하여 기존 유스케이스를 참조하는가?
• 일반화 관계(generalization)
  • 액터 또는 유스케이스가 구체화 된 다른 여러 액터나 유스케이스를 가지고 있는가?

🔽요구 분석 명세서

• 기능과 비기능이 들어있는데 이 두개 중에서 기능 부분을 더 명확하게 하기 위해서 유스케이스를 작성하는 것이다.
• 시스템의 기능을 정확하고 완벽하며 일관성 있게 작성한 것
• 소프트웨어에 포함될 기능과 제약 조건들을 나열
• 기능에 대한 자세한 설명과 예외처리 기술
• 시스템 성능과 관련된 사항, 속도, 정확성, 사용 용이성 포함

✔명세서 작성

• 사용자와 개발자간의 이해를 돕기위함
• Gilbert가 제안한 요구 분석서 작성시 주의사항
  • 요구 분석서는 사용자와 개발자 모두가 쉽게 이해할 수 있도록 써야 한다
  • 요구 분석서에 기술된 조건은 개발자와 사용자가 모두 동의한 것이어야 한다.
  • 요구 분석서는 목표 시스템에 의하여 수행될 모든 기능을 정확히 기술하여야 한다.
  • 요구 분석서는 목표 시스템에 영향을 주는 모든 제약 조건을 기술한다.
  • 요구 분석서는 시스템의 인수를 위한 테스트 기준을 제공하여야 한다.
  • 요구 분석서는 원하는 시스템의 품질과 상대적인 중요도 및 품질을 재는 방법이 기술 되어야 한다.

✔명세서 검토

• 요구분석 명세서 평가기준
  • 무결성과 완벽성 : 오류 없이
  • 일관성 : 모순x
  • 명확성 : 자세히
  • 기능적 : “무엇을"
  • 검증 가능성 : 사용자 요구 만족, 시스템이 요구분석에 기술된 내용과 일치하는가
  • 추적 가능성 및 변경 용이성 : 체계적

🔽 시나리오(이벤트 흐름)

• 유스케이스 = 시스템 기능 ⇒ “동작”
• 이벤트 흐름 = 작동순서
  • 기본흐름
  • 대안 흐름 : 작동의 종료가 필요한 상황 흐름
  • 예외 흐름

예시