일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- MAC
- Waterfall
- frequency-domain spectrum analysis
- 게임 개발
- MLFQ
- information hiding
- 유스케이스
- 메카님
- DSP
- Security
- 배경 그림
- DP
- OSI 7계층
- AINCAA
- 컴퓨터 네트워크
- protection
- link layer
- SDLC
- FIFO
- 운영체제
- OWASP
- SJF
- 게임개발
- Unity #Indie Game
- Trap
- polymorphism
- STCF
- 유니티
- stride
- unity
- Today
- Total
다양한 기록
유스케이스 모델의 작성 본문
유스케이스 모델의 작성
- 목표: 사용자의 요구사항을 누락 없이 도출
- 액터와 유스케이스 간의 연관 관계를 다이어그램으로 표현
- 유스케이스 모델은 시스템의 요구사항을 빠짐없이 기술
- 핵심 기능은 반드시 유스케이스로 도출
유스케이스 모델
- 액터
- 유스케이스
액터
- 시스템과 상호작용하는 시스템 외부의 존재 .. 시스템에 입력을 주는 존재와 시스템에게서 결과를 받는 존재
- 개발 대상이 되는 시스템에 따라 달라짐
- 일반적으로 사용자, 외부 시스템, 장치의 세가지로 분류
유스케이스
- 개발 대상이 되는 시스템이 제공하는 개별적 기능
- 유스케이스로 표현된 기능은 시스템 사용자가 이용
- 유스케이스의 기능과 이를 이용하는 액터와의 관계 표현
- 기능적 요구사항은 요구사항은 유스케이스로 구성
액터
- 시스템 외부의 존재
- 장치 유형의 액터 표현 여부는 표준 플랫폼 지원에 따라 다름
- 시스템과 상호 작용
- 시스템 관점에서 바라본 사용자의 역할
외부 시스템이 아닌, 개발 범위에 포함되면 액터로 표현 안함
시스템에서 표준으로 지원되는 장치는 액터로 표현 가능.. (키보드, 마우스 등..)
임베디드 시스템을 구성하는 장치들은 액터로 표현 .. 일반적인 지원이 없는 장치임
상호작용은 유스케이스 다이어그램 상 연관관계로 표시
비슷한 방식으로 시스템과 상호작용하는 사용자/장치/시스템 그룹
액터가 두가지 이상의 목적을 가지고 상호작용을 한다면 액터 분해해야 함
유스케이스
- 유스케이스는 사용자가 인지할 수 있는 하나의 기능 단위
- 구체적이고 다양한 세부 상황을 포함
- 반드시 한 개 이상의 액터와 상호 작용
- 모든 활성화 액터에게 동일한 기능 제공
- 최소 기능 단위 표현
유스케이스는 구체적이어야 함
- 현실에서 발생하는 구체적인 기능
- 유스케이스를 활성화시키는 액터에 의해 실제로 수행되는 기능
- 성격 상 유사한 유스케이스는 패키지를 이용하는 것이 적절
유스케이스는 다양한 세부사항 포함
- 다양한 상황을 함축하는 것이 일반적
- 정상적인 상황/시나리오 뿐만 아니라 다양한 예외상황 포함
유스케이스는 반드시 한 개 이상의 액터와 활성화 상호작용
- 유스케이스는 시스템이 제공하는 기능이므로 이 기능을 이용하는 액터가 반드시 존재
- 유스케이스의 기능을 이용하는 액터는 연관 관계로 표현
- 각 유스케이스는 자신 방향의 연관 관계를 가지는 액터가 반드시 한 개 이상 존재해야 함
모든 유스케이스는 모든 활성화 액터에게 동일한 기능을 제공
- 하나의 유스케이스에 액터가 둘 이상 존재 시 동일한 기능 제공
- 유스케이스의 세부 기능이 액터에 따라 선택적으로 제공될 필요가 있는 경우 기능을 바탕으로 유스케이스 분할
유스케이스는 트랜잭션 성격을 가져야 함
- 트랜잭션은 하나의 단위로 처리되어야 하는 최소 작업 단위
- 유스케이스도 사용자 관점에서 수행되는 최소 기능 단위
- 대출 신청/상환은 유스케이스로 부적절
- 유스케이스의 세부 기능이 부분적으로 수행될 때 여러 개의 유스케이스로 분리하는 것이 바람직
액터와 유스케이스 간의 관계
연관 관계는 반드시 시스템이 제공하는 기능
- 시스템은 입출력을 위한 코드를 한 줄이라도 제공
- 상호작용을 위한 코드가 필요 없는 경우 연관 관계를 표시해선 안됨
- 상호작용을 위한 코드는 유형에 따라 달라질 수 있음
유형
1) 활성화
2) 수행 결과 통보
3) 외부 서비스 요청
연관 관계의 방향은 제어 흐름을 표현
- 제어 흐름이기 때문에 성적 조회 유스케이스에서 학생 액터로 방향 표시하면 안됨 .. 학생->성정조회하기
- 수강 신청 유스케이스와 교과목 관리 시스템도 양방향을 사용해선 안됨
액터를 이용해서 타 조직에서 개발 중인 서브 시스템 및 기존 라이브러리 표현 가능
데이터에 대한 CRUD는 하나의 유스케이스로 표현
유스케이스 간의 선/후행 관계는 액티비티 다이어그램을 통해 표현
- 유스케이스 간의 관계는 일반화 관계와 의존 관계만 존재
산출물
요구사항 명세서 ..
- 유스케이스 다이어그램
- 액터 개요
- 유스케이스 개요
- 유스케이스 명세서
- 시스템 품질 요구 사항
- 개발 제약 사항
..
요구사항 명세서 부분 | 내용 |
유스케이스 다이어그램 | 도출된 액터, 유스케이스, 연관 관계를 표현하는 유스케이스 다이어그램 |
액터 개요 | 각 액터에 대한 간략한 설명 |
유스케이스 개요 | 각 유스케이스에 대한 간략한 설명 |
검토 기준
액터
- 액터는 시스템과 상호작용을 하는 시스템 외부의 존재
- 액터는 시스템과 상호작용을 해야 한다
- 액터는 시스템 관점에서 바라본 사용자의 역할을 뜻해야 한다
- 시스템의 사용자와 외부 연동되는 시스템을 정확하게 파악할 수 있어야 한다
- 액터의 이름만으로 해당 액터의 역할을 명확하게 이해할 수 있어야 한다
유스케이스
- 유스케이스는 개발 대상이 되는 시스템이 제공하는 개별적인 기능을 뜻한다
- 유스케이스로 표현된 기능은 시스템의 사용자가 이용한다
- 유스케이스의 기능과 이를 이용하는 액터의 연관관계를 명시적으로 표현한다
- 시스템의 전체 기능적 요구사항은 표현된 유스케이스로 구성된다
- 유스케이스는 사용자가 인지할 수 있는 하나의 기능 단위이다
- 유스케이스는 구체적이어야 한다
- 하나의 독립적인 기능을 구성하는 다양한 세부 상황은 하나의 유스케이스로 표현되어야 한다
- 반드시 한 개 이상의 활성화 상호작용을 하는 액터가 있어야 한다
- 유스케이스는 트랜잭션 성격을 가져야 한다
- 유스케이스 이름으로부터 해당 유스케이스가 나타내는 시스템의 기능을 명확하게 이해할 수 있어야 한다
연관 관계
- 액터와 유스케이스 간의 연관 관계는 둘 간의 상호작용을 뜻한다
- 연관관계는 반드시 시스템이 제공하는 기능이어야 한다
- 연관관계의 방향은 제어 흐름을 뜻해야 한다
액터 개요
- 유스케이스 다이어그램의 각 액터에 대한 설명이 있어야 한다
- 설명은 시스템 관점에서 바라본 액터의 역할을 명확하고 구체적으로 기술해야 한다
유스케이스 개요
- 유스케이스 다이어그램의 각 유스케이스에 대한 설명이 있어야 한다
- 유스케이스를 통하여 제공되는 시스템의 기능을 명확하고 구체적으로 설명해야 한다
'소프트웨어공학' 카테고리의 다른 글
유스케이스 모델 구조화 (0) | 2024.10.25 |
---|---|
유스케이스 모델 상세화 (0) | 2024.10.24 |
요구사항 정의 개요, 산출물 (0) | 2024.10.23 |
유스케이스, 클래스 등등 다이어그램 기초 (0) | 2024.10.20 |
UML 개요 (0) | 2024.10.20 |