반응형
✅ CH 8. 소프트웨어 요구사항 분석 (2)
🔷 8.1 유스케이스 기반 요구사항 분석
8.1.1 요구 분석 단계의 작업
- 요구사항 분석 접근 방식은 3가지로 구분됨:
- 구조적 분석:
- DFD(Data Flow Diagram)를 이용한 기능(프로세스) 중심 분석
- 객체지향 분석:
- UML의 유스케이스 다이어그램을 이용해 사용자 상호작용 중심 분석
- 정보공학 분석:
- ER(Entity-Relationship) 다이어그램을 통해 정보나 자료 중심으로 분석
- 구조적 분석:
8.1.2 유스케이스 기반 분석 프로세스
- 분석 흐름:
- 유스케이스 모델링
- 유스케이스 기술서 작성
- 기능/비기능 요구사항 분류
- 요구사항 명세서 작성
- UML(Unified Modeling Language) 사용하여 표준화된 모델링 진행
8.1.3 UML의 역사
연도 내용
| 1993년 이전 | Booch, OMT, OOSE 등 다양한 모델링 방법론 공존 |
| 1995년 | Booch + Rumbaugh + Jacobson 모델링 기법 통일 |
| 1997년 9월 | UML 1.1 발표, OMG에서 표준으로 채택 |
| 2004년 | UML 2.0 발표 |
| 현재 | UML 2.0 사용 중 |
8.1.4 시스템 구축 시 UML의 역할
- UML은 시스템 구축을 위한 청사진 역할을 함
- 시스템의 개념적/물리적 표현을 위해 필요한 언어
- UML의 4가지 역할:
- 가시화 언어: 시스템 구조/행위 시각화
- 명세화 언어: 요구사항 및 설계 세부사항 명세
- 구축 언어: 코드 구조와 대응되는 모델 구성
- 문서화 언어: 개발 과정 및 결과 기록
8.1.5 모델링 방법론 - 부치 (Booch)
- 4+1 View 모델:
- 시스템을 5가지 관점(View)으로 나누어 설계 및 모델링
- 논리 뷰
- 구현 뷰
- 프로세스 뷰
- 배포 뷰
- 유스케이스 뷰 (공통 기반)
- 시스템을 5가지 관점(View)으로 나누어 설계 및 모델링
8.1.6 모델링 방법론 - OMT / OOSE
📌 OMT (Object Modeling Technique) - 럼바우
- 3가지 모델을 통해 시스템 설명:
- 객체 모델: 클래스/객체 중심의 정적 구조
- 기능 모델: DFD 기반 데이터 흐름/변환
- 동적 모델: 상태 전이 및 제어 흐름
📌 OOSE (Object-Oriented Software Engineering) - 야콥슨
- 유스케이스 중심 방법론
- 사용자와의 상호작용을 통해 요구사항을 도출
- 도출된 유스케이스는 개발·테스트·검증 단계에 활용
🔷 8. 2. 유스케이스 다이어그램
8.2.1 유스케이스 개요
- 유스케이스란:
사용자의 요구를 표현한 기능 단위 (예: 수강관리, 성적관리 등) - 사용자 관점에서 시스템에 어떤 서비스가 존재하는지를 표현
- 활용 용도:
- 시스템 범위 정의
- 개발 과정 계획 수립
- 테스트 케이스 정의 기반
- 사용자 매뉴얼 구성
- 유스케이스는 다음 단계들을 서로 연결해주는 중심 요소:
- 요구정의 → 분석 → 설계 → 구현 → 테스트
8.2.2 유스케이스 다이어그램이란?
- 시스템의 서비스/기능을 사용자 관점에서 표현
- 고객과 개발자가 요구사항을 시각적으로 조율할 수 있도록 도움
8.2.3 유스케이스 다이어그램 구성요소
시스템 (System)
- 개발 대상 어플리케이션
- 표기법: 유스케이스를 감싸는 사각형, 상단에 시스템 이름 기입
예: 종합정보시스템
액터 (Actor)
- 시스템 외부에서 상호작용하는 사람 또는 외부 시스템
- 표기법: 사람 모양 + 역할명을 명시
예: 학생
유스케이스 (Usecase)
- 시스템이 액터에게 제공하는 기능
- 표기법: 타원으로 표현, 안에 "~한다" 형태의 기능명을 기술
예: 학생 정보를 입력한다
8.2.4 유스케이스 다이어그램 관계 종류
연관 관계 (Association)
- 액터와 유스케이스 간 직접적인 상호작용
- 표기법: 실선으로 연결
포함 관계 (Include)
- 하나의 유스케이스가 다른 유스케이스 실행을 반드시 포함하는 경우
- 표기법: 점선 + 화살표 방향 <<include>>
- 포함하는 → 포함되는 유스케이스 방향
예: 글을 등록한다 → 로그인 한다
- 포함하는 → 포함되는 유스케이스 방향
확장 관계 (Extend)
- 조건에 따라 선택적으로 수행되는 유스케이스
- 표기법: 점선 + 화살표 방향 <<extend>>
- 확장 기능 → 확장 대상 방향
예: 파일을 첨부한다 → 글을 등록한다
- 확장 기능 → 확장 대상 방향
일반화 관계 (Generalization)
- 공통 속성을 추출하여 추상화하는 관계
- 표기법: 삼각형 화살표 + 실선
- 구체적 → 추상적 유스케이스 방향
예:
글쓴이로 검색한다 ↑ 글을 검색한다 ↑ 날짜로 검색한다 - 구체적 → 추상적 유스케이스 방향
2.5 유스케이스 다이어그램 작성 순서
1. 시스템 및 액터 식별
2. 유스케이스 식별
3. 관계 정의
▪ 시스템 및 액터 식별
- 시스템의 이름 정의
- 사용자 역할 정의
- 외부 시스템 식별
▪ 유스케이스 식별
- 액터가 요구하는 서비스
- 액터의 시스템 상호작용 행위
▪ 관계 정의
- 액터 간 일반화
- 액터-유스케이스 간 연관
- 유스케이스 간 포함/확장 관계
8.2.6
액터 식별을 위한 질문
- 누가 정보를 생성/사용/삭제하는가?
- 누가 시스템을 유지관리하는가?
- 상호작용하는 외부 시스템/하드웨어는 누구인가?
유스케이스 식별을 위한 질문
- 액터가 원하는 기능은 무엇인가?
- 어떤 정보를 생성/조회/수정/삭제하고 싶은가?
- 어떤 기능이 업무를 효율적으로 만드는가?
- 모든 기능 요구사항이 포함되었는가?
관계 식별을 위한 질문
- 연관 관계: 상호작용이 존재하는가?
- 포함 관계: 반드시 수행되어야 할 유스케이스인가?
- 확장 관계: 조건부로 실행되는 유스케이스가 있는가?
- 일반화 관계: 여러 유사 액터/유스케이스가 존재하는가?
유스케이스 작성 시 유의사항
- 기능 중심으로 작성
- 사용자 관점에서 기술
- 목표 지향적으로 표현
- 시스템 흐름도와는 다름 (기능 중심)
- 간결하고 읽기 쉽게 구성
🔷 8.3. 유스케이스 다이어그램 예
8.3.1 사용자 요구사항: 게시판 시스템
- 사용자가 글을 등록, 수정, 삭제할 수 있는 게시판 개발
- 관리자 모드는 개발하지 않음
- 기능 요구사항:
- 글 등록 시 파일 첨부 가능
- 글을 조회하여 읽을 수 있음
- 등록된 글은 글쓴이/날짜로 검색 가능
- 모든 기능은 로그인 이후에만 사용 가능
8.3.2 유스케이스 다이어그램 작성 과정
① 시스템 식별
- 시스템명: 게시판
② 액터 식별
- 외부에서 상호작용하며 게시판을 사용하는 사용자
③ 유스케이스 식별
- 사용자는 다음 작업 가능:
- 글을 등록한다
- 글을 수정한다
- 글을 조회한다
- 글을 삭제한다
- 글을 검색한다
- 로그인 한다
- 파일을 첨부한다
- 글쓴이로 검색한다
- 날짜로 검색한다
④ 관계 정의
- 연관관계: 사용자 ↔ 글을 등록한다
- 일반화관계:
- 글을 검색한다 → 글쓴이로 검색한다
- 글을 검색한다 → 날짜로 검색한다
- 포함관계 (<<include>>):
- 글을 등록한다 ← 로그인 한다
- 글을 수정/삭제/조회한다 ← 로그인 한다
- 확장관계 (<<extend>>):
- 글을 등록한다 ← 파일을 첨부한다
8.3.3 완성된 게시판 유스케이스 다이어그램 구성요소
[시스템: 게시판]
|
|-- 사용자 (액터)
|
|-- <<include>> 로그인 한다
|-- 글을 등록한다
|-- <<extend>> 파일을 첨부한다
|-- 글을 수정한다 (<<include>> 로그인)
|-- 글을 삭제한다 (<<include>> 로그인)
|-- 글을 조회한다 (<<include>> 로그인)
|-- 글을 검색한다
|-- 글쓴이로 검색한다 (일반화)
|-- 날짜로 검색한다 (일반화)
8.3.4 유스케이스 기술서
정의
- 유스케이스 다이어그램의 기능별 흐름을 구체적인 문장으로 표현
- 각 유스케이스가 어떻게 수행되는지를 명세
구성 항목
- 유스케이스명
- 액터명
- 유스케이스 개요 및 설명
- 사전 조건 / 사후 조건
- 작업 흐름
- 정상 흐름: 기본 절차
- 대안 흐름: 선택지 발생 시 흐름
- 예외 흐름: 오류 상황 발생 시 흐름
예시 – 글을 등록한다
- 유스케이스명: 글을 등록한다
- 액터명: 사용자
- 개요: 사용자가 원하는 글을 게시판에 등록한다
- 사전 조건: 로그인 완료
- 작업 흐름:
- 사용자가 글쓰기 버튼을 클릭한다
- 시스템이 글쓰기 박스를 디스플레이한다
- 사용자가 내용을 입력한다
- 등록 버튼을 클릭한다
- 시스템은 글을 DB에 저장한다
- 사용자가 파일 첨부 버튼을 클릭한다
- 시스템이 첨부창을 연다
- 사용자가 파일을 첨부한다
- ✅ 정상 흐름
8.3.5 포함 / 확장 유스케이스 예시
포함 (Include) – 주문 취소
- 주문 취소 유스케이스는 반드시 주문 찾기를 포함
- 주문 상태에 따라:
- 상품 준비 중: 주문 상태를 ‘취소’로, 환불 처리
- 배송 중: 반품 정책 안내
확장 (Extend) – 멤버십 할인
- 책 주문 유스케이스에 조건부로 멤버십 할인이 확장됨
- 고객이 멤버십 회원일 경우 할인 기능 시작
- 할인 내용 표시 및 총액 할인 적용
- 계산 결과를 표시하고 종료
8.3.6 유스케이스 다이어그램 & 기술서의 관계
구분 설명
| 유스케이스 다이어그램 | 시스템의 기능 목록을 구조적으로 표현 |
| 유스케이스 기술서 | 각 기능이 어떻게 작동하는지 구체적으로 명세 |
둘은 함께 사용되어 요구사항 명세서의 품질을 높이고,
설계 및 테스트의 기준이 됨.
'학교 CS > 소프트웨어공학 (3-1학기)' 카테고리의 다른 글
| CH 10. 소프트웨어 테스팅 (1) (1) | 2025.06.17 |
|---|---|
| CH 9 소프트웨어 구조 설계 (2) | 2025.06.17 |
| CH 7 소프트웨어 요구사항 분석 (1) (5) | 2025.06.15 |
| CH6 소프트웨어 프로젝트 계획 (3) (0) | 2025.04.28 |
| CH5 소프트웨어 프로젝트 계획(2) (1) | 2025.04.28 |
