"유스 케이스"의 두 판 사이의 차이

잔글 (로봇: 유즈케이스, 유즈케이스 다이어그램, 시나리오(으)로 이중 넘겨주기 고침)
태그: 되돌려진 기여
(사용자 2명의 중간 판 37개는 보이지 않습니다)
1번째 줄: 1번째 줄:
#넘겨주기 [[유즈케이스, 유즈케이스 다이어그램, 시나리오]]
==개요==
;use case
;유스 케이스, 사용 사례
* "ㅇㅇ하기"
* [[액터]]가 사용하는 기능
* 시스템이 제공하는 기능
* 시스템에 대한 [[기능 요구사항]]
* 시스템이 무엇을 하는지를 기술한 것
* 외부 액터가 시스템을 어떻게 사용하는지를 적은 글
* 시스템이 외부 요청(예: 사용자 입력)을 수신하고 이에 응답하는 잠재적 시나리오
* 시스템 사이에서 교환되는 메시지의 중요도에 의해 클래스나 시스템에 제공되는 고유 기능 단위
* 일반적으로 [[액터]]와 목표를 달성하기 위한 시스템 간의 상호작용을 정의하는 작업 또는 이벤트 단계의 목록이다.
* 행위자는 인간 또는 기타 외부 시스템일 수 있다.
* 줄글 또는 표로 작성한다.
* [[목표]]를 중심으로 도출한다.
* 1개의 유스케이스는 1개의 목표를 담고 있어야 한다.
:여러 개의 목표를 가지고 있다면 분할하자.
* 1개의 유스케이스는 여러 개의 요구사항을 포함할 수 있다.
* 개발 범위 외의 UI나 하드웨어와는 독립적으로 작성하는 것이 좋다.
* 메뉴 항목이나 기능과는 다르다.
* UI를 도출할 때 도움이 된다.
* [[비기능 요구사항]]을 표현하기 어렵다. → [[유스케이스 시나리오]]로는 가능
* 형식 수준: 간략(brief), 일반(casual), 상세(fully dressed)
 
{| class='wikitable'
| 간략 || 한 문단 정도로 메인 성공 시나리오를 적는다.
|-
| 일반 || 메인 성공 시나리오 외에 대안 시나리오도 적는다.
|-
| 상세 || 양식에 맞게 세부사항(이해관계자, 사전 조건 등)을 적는다.
|}
 
* [[유스케이스 다이어그램]]에서 [[타원]]으로 표현된다.
 
[[File:Edit_an_article.svg|440px]]
 
==같이 보기==
{{z컬럼3|
* [[액터]](actor)
* [[요구공학]]
* [[사후조건]]
* [[기능 요건]]
* [[테스트케이스]]
* [[요구사항 분석]]
* [[통합 모델링 언어]](UML)
* [[시스템 모델링 언어]](SysML)
* [[유스케이스 관계]]
* [[유스케이스 문서]]
* [[유스케이스 다이어그램]]
* [[컴포넌트 기반 소프트웨어 공학]](CBD)
* [[유스케이스, 유스케이스 다이어그램, 시나리오]]
}}
 
==참고==
* {{영어위키백과|Use case}}
* {{위키백과}}
* {{위키낱말사전}}
* {{다음사전}}
* {{다음백과}}
* {{네이버사전}}
* {{네이버백과}}
* https://home.cs.colorado.edu/~kena/classes/6448/s01/examples/edmonb3.pdf
 
[[분류: 유스케이스]]
[[분류: 1986년]]
[[분류: 소프트웨어 요구사항]]
[[분류: 프로젝트 관리]]
[[분류: UML]]
[[분류: SysML]]
[[분류: 애자일]]

2022년 6월 26일 (일) 15:15 판

1 개요

use case
유스 케이스, 사용 사례
  • "ㅇㅇ하기"
  • 액터가 사용하는 기능
  • 시스템이 제공하는 기능
  • 시스템에 대한 기능 요구사항
  • 시스템이 무엇을 하는지를 기술한 것
  • 외부 액터가 시스템을 어떻게 사용하는지를 적은 글
  • 시스템이 외부 요청(예: 사용자 입력)을 수신하고 이에 응답하는 잠재적 시나리오
  • 시스템 사이에서 교환되는 메시지의 중요도에 의해 클래스나 시스템에 제공되는 고유 기능 단위
  • 일반적으로 액터와 목표를 달성하기 위한 시스템 간의 상호작용을 정의하는 작업 또는 이벤트 단계의 목록이다.
  • 행위자는 인간 또는 기타 외부 시스템일 수 있다.
  • 줄글 또는 표로 작성한다.
  • 목표를 중심으로 도출한다.
  • 1개의 유스케이스는 1개의 목표를 담고 있어야 한다.
여러 개의 목표를 가지고 있다면 분할하자.
  • 1개의 유스케이스는 여러 개의 요구사항을 포함할 수 있다.
  • 개발 범위 외의 UI나 하드웨어와는 독립적으로 작성하는 것이 좋다.
  • 메뉴 항목이나 기능과는 다르다.
  • UI를 도출할 때 도움이 된다.
  • 비기능 요구사항을 표현하기 어렵다. → 유스케이스 시나리오로는 가능
  • 형식 수준: 간략(brief), 일반(casual), 상세(fully dressed)
간략 한 문단 정도로 메인 성공 시나리오를 적는다.
일반 메인 성공 시나리오 외에 대안 시나리오도 적는다.
상세 양식에 맞게 세부사항(이해관계자, 사전 조건 등)을 적는다.

Edit an article.svg

2 같이 보기

3 참고