일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- OSI 7계층
- DSP
- stride
- Waterfall
- Security
- information hiding
- 유니티
- 유스케이스
- FIFO
- polymorphism
- Trap
- unity
- 컴퓨터 네트워크
- link layer
- MLFQ
- SDLC
- 게임개발
- frequency-domain spectrum analysis
- AINCAA
- 메카님
- 게임 개발
- OWASP
- Unity #Indie Game
- DP
- 운영체제
- protection
- SJF
- MAC
- 배경 그림
- STCF
- Today
- Total
다양한 기록
유스케이스 모델 상세화 본문
유스케이스 다이어그램에 기술된 각 유스케이스를 구체적으로 기술
Usecase => Usecase 명세서
유스케이스 명세서
유스케이스에 대한, 보다 구체적인 명세
- 유스케이스 이름 : 유스케이스에 대한 가장 간결한 명세로서 유스케이스를 통하여 제공되는 시스템의 기능을 명확한 동사 구 형태로 표현
- 개요 : 모든 이해 관계자는 가장 먼저 유스케이스 명세서의 개요 항목을 통해서 유스케이스 이해
- 관련 액터 항목 : 해당 유스케이스가 동작할 때 필요한 주변 액터 이해 가능, 주액터와 보조액터를 구분하여 기록
- 우선 순위 : 기능의 중요도와 개발 난이도를 바탕으로 결정, 개발 순서, 자원 투입 증과 같이 프로젝트 관리 측면에서 사용
- 선행 조건 : 유스케이스의 시작 시 만족되어야 할 조건으로서 만족되지 않으면 유스케이스는 시작되지 않음
- 후행 조건 : 유스케이스의 종료 시 만족해야 하는 조건으로 유스케이스의 정상 동작 여부에 대한 최소한의 판단 기준으로 사용 가능
- 시나리오 : 유스케이스의 관련 액터와 시스템 간의 상호작용에 대한 구체적인 정의 포함, 하나의 유스케이스에는 기본 시나리오와 대안 시나리오로 구분하여 기술
- 비기능적 요구사항: 성능, 신뢰도, 보안 등 이 유스케이스와 관련된 비기능적 요구사항 기술
시나리오
- 유스케이스의 기능적 행위를 시스템과 관련 액터와의 상호작용으로서 기술
- 기본 시나리오와 대안 시나리오로 분류
.. 대안 시나리오는 기본 시나리오로부터 분기
.. 대안 시나리오는 선택 시나리오와 예외 시나리오로 부류
선택 시나리오: 오류/예외가 아닌 정상적인 시스템의 동작 시 발생하는 다른 상황
예외 시나리오: 입력과 시스템 처리 과정에서 발생할 수 있는 오류/예외 상황
시나리오 명세는 대안 시나리오를 포함해야 함
유스케이스와 관련된 모든 액터와의 모든 상호작용을 기술
시스템과의 상호작용을 명시적으로 표현해야 함
시나리오는 명확하고 이해가 용이한 문장 스타일로 기술 .. 개발자의 기술적 용어 사용 X
- 각 스텝의 주어는 시스템 또는 액터를, 능동태의 문장으로 기술
- 한 스텝에는 시스템 또는 하나의 액터에 의한 기능/행위를 기술
- 각 스텝은 시스템과 액터와의 입/출력이 명확하게 기술되어야 함
- 액터와 시스템 간의 입/출력 시스템 기능의 목적 기술
CRUD 유스케이스의 CRUD는 주요 대안 시나리오로 기술
여러 시나리오 간의 관계를 UML 시퀀스 다이어그램으로 기술
명확한 표현과 이해를 위해 IF, WHILE, FOR 등을 활용
기본 시나리오
---------------------------------------
1. ATM 사용자는 카드 입력 장치에 카드를 삽입한다.
....
5. DO
6. 시스템은 암호 입력 화면을 출력한다
7. ATM 사용자는 암호를 입력한다.
8. 시스템은 입력된 암호의 정확성을 점검한다.
9. WHILE (암호가 부정확함)
10. 시스템은 출금 금액 입력 화면을 출력한다.
....
대안 시나리오
-----------------------------
2-A: 카드 판독 실패 시
(2)에서 카드 판독이 안될 때
1. 시스템은 카드 판독 실패 화면을 출력한다.
2. 시스템은 카드를 배출시킨다.
....
IF(~~) THEN
...
END IF
선행 조건
액터와 시스템 상태에 대한 제약으로 표현
유스케이스의 선행 조건은 사용자 인터페이스에 반영
후행 조건
입력과 시스템 상태의 변화에 대한 조건으로 기술
대안 시나리오 별로 기술 가능
선행/후행 조건
도메인 모델과 OCL을 이용해서 명확하게 기술
* OCL(Object Constraint Language) .. 제약 사항을 기술하는 정형적 언어
비기능적 요구사항
- 검증이 가능하도록 명확하고 구체적으로 기술
우선 순위
시나리오 별로 부여 가능
유스케이스 명세서
- 개별 유스케이스 또는 유스케이스 패키지 별로 작성됨
- 패키지 별로 문서를 작성하는 장점: 유스케이스 이해하기 쉬움
검토 기준
개요
- 유스케이스가 나타내는 전체적인 기능이 명확히 기술되어야 한다
- 유스케이스와 상호 작용을 하는 액터를 기술한다
- 유스케이스의 일부 기능만을 뜻해서는 안된다
- 주요 대안 시나리오가 언급되어야 한다
- 관련 액터가 언급되어야 한다
- 시스템 내부의 기능과 액터와의 상호작용을 상세하게 기술해서는 안된다
관련 액터
- 관련 액터는 유스케이스 다이어그램과 일관되어야 한다
우선 순위
- 우선 순위는 해당 기능의 중요도와 개발의 난이도를 고려햐여 결정
선행 조건
- 유스케이스가 정상적으로 수행되기 위하여 가정하고 있는 상황을 표현해야 한다
- 선행 조건은 유스케이스의 수행 시작을 위하여 항상 만족이 되어야 하는 조건이다
- 선행 조건은 액터와 시스템 상태에 대한 제약으로 표현된다
- 유스케이스의 선행 조건은 사용자 인터페이스에 반영된다
후행 조건
- 유스케이스의 수행 결과를 후행 조건을 통하여 파악할 수 있어야 한다
- 후행 조건은 유스케이스의 수행 완료 후에 만족이 되어야 하는 조건이다
- 후행 조건은 입력과 시스템 상태의 변화에 대한 조건으로 기술된다
시나리오
- 유스케이스와 관련된 모든 액터와의 상호작용을 기술해야 한다
- 시나리오는 명확하고 이해가 용이한 문장 스타일로 기술해야 한다
- 개발자의 기술적인 용어를 사용하지 않고 도메인의 용어를 사용한다
- 각 스텝은 주어를 시스템 또는 액터로 사용하여 능동태의 문장으로 기술한다
- 한 스텝에는 시스템 또는 하나의 액터에 의한 기능/행위를 기술한다
- 시스템과 액터와의 입/출력이 명확하게 기술되어야 한다
- 각 스텝은 액터와 시스템 간의 입/출력 및 시스템의 기능의 궁긍적인 목적을 기술한다
- 액터가 인식할 수 없는 시스템 내부의 동작과 액터와의 입/출력 방법을 상세하게 기술하지 않는다
- 기본 시나리오와 주요 대안 시나리오 모두 기술해야 한다
비기능적 요구사항
- 검증이 가능하도록 명확하고 구체적으로 기술해야 한다
'소프트웨어공학' 카테고리의 다른 글
유스케이스의 조직화 (0) | 2024.10.26 |
---|---|
유스케이스 모델 구조화 (0) | 2024.10.25 |
유스케이스 모델의 작성 (1) | 2024.10.23 |
요구사항 정의 개요, 산출물 (0) | 2024.10.23 |
유스케이스, 클래스 등등 다이어그램 기초 (0) | 2024.10.20 |