Lecture 07: 요구분석 - 2

경희대학교 김정욱 교수님의 소프트웨어 공학 수업을 기반으로 정리한 글입니다.

(2) 요구사항 분석

유스케이스 (Use Case) 다이어그램

가장 중요한 분석 기법 툴로, 시스템 개발자와 고객 사이에 요구를 한눈에 이해하는 수단이 된다. (요구분석 명세서 작성의 기반)

또한, 예외적인 케이스 (ex) 확장)를 개발자에게 주지시키며, 대략적인 계획을 위해 기능의 수준을 파악하는 데 용이하다.

 

구성

• 시스템
• 액터
• 유스케이스 (Use case)
• 관계

※ 액터는 사람 뿐만 아니라 외부 시스템이 될 수도 있다. ex) 시스템 - 외부 시스템: 은행 - 보

▶ Use case diagram

 

※ Use case diagram에는 비기능적 요소는 들어있지 않고, 나중에 명세서 작성시 추가적으로 작성한다.

 

특징

• 시스템의 사용자에게 서비스를 제공하기 위한 상호작용의 단위
• 사용자 또는 외부 시스템이 시스템과 상호작용하는 다이얼로그(대화)를 모델링
• 이를 바탕으로 설계를 수행하는 데 유용
• 소프트웨어 개발자와 이해 당사자 (사용자) 간의 계약

주의사항

• 비기능적 요구를 찾아내는 데 효과적인 방법이 아님 (기능별 코드짤 때는 효과적임)
• 시스템의 흐름도가 아님
• '어떻게'가 아니라 '무엇을' 시스템이 하는가를 담은 것임

유스케이스 용어

1. 시스템 (System)

만들고자 하는 프로그램 범위를 의미한다. (만들고 싶은 소프트웨어)

시스템은 유스케이스를 둘러싼 사각형 틀을 말한다. (안쪽 상단에 명칭 작성)

▶ 시스템 (System)

2. 액터 (Actor)

시스템을 사용하는 사람을 의미하는데, 추가로 관련있는 외부 시스템도 의미한다. (시스템 외부에 위치)

ex) 성적 관리 use case - 성적과 관련 있는 기능을 사용하는 사람 (교수, 학생, 조교, 학사 담당 직원)

▶  액터의 표기

 

1) 주요 액터 (Primary Actor)

행동을 하는 사람을 의미한다. (대부분의 액터가 여기에 해당)

ex) 성적 관리 시스템의 주요 액터  - 성적과 관련 있는 기능을 사용하는 사람 (교수, 학생, 조교, 학사 담당 직원)

 

2) 시스템 액터 (System Actor)

해당 프로그램 개발 범위에는 속하지 않지만 서로 연동되는 또 다른 외부 시스템을 의미한다.

ex) 은행(시스템) - 보안(시스템 액터)

 

ex) 인터넷 서점 시스템 - 주요 액터: 온라인 고객, 택배 직원 / 시스템 액터: 신용카드 회사

3. 유스 케이스, 사용 사례 (Use Case)

사용자가 시스템을 통해 사용하고 싶은 기능, 즉 시스템이 액터에게 제공해야 하는 기능을 의미한다.

다시 말해 시스템의 요구사항을 의미한다. (프로그램 안에 있는 각각의 기능)

▶  유스케이스 표기

 

주의사항

• 기능적 요소만 포함 (비기능적 요소는 포함되지 않음)
• 유스케이스로 도출되지 않은 것은 시스템의 개발 범위에 포함할 수 없기에 유스케이스 도출 시 시스템 내 필요한 기능을 모두 도출해야 함

4. 관계 

액터 및 유스케이스들 간의 의미 있는 관계이다. (액터 - 유스케이스, 유스케이스 - 유스케이스)

 

관계의 종류

• 연관 관계 (Association):  액터 - 유스케이스
• 포함 관계 (Include): 유스케이스 - 유스케이스
• 확장 관계 (Extend) : 유스케이스 - 유스케이스
• 일반화 관계 (Generalization) : 액터 - 액터, 유스케이스 - 유스케이스

▶ 관계 (Relationship)

 

※ 연관관계 부분에서 화살표는 무시해주면 된다. (단순 실선으로 바꿔서 생각)

▶  관계 표기

 

1) 연관 관계 (Association) (실선)

액터와 유스케이스 사이의 관계를 표현할 때 사용한다.

• 액터: 정보를 통보받거나 요구
• 유스케이스: 정보를 제공

즉, 액터가 유스케이스를 사용하는 것을 표현한다.

▶ 연관 관계

 

2) 포함 관계 (Include)

두 유스케이스 간의 의존성을 나타낸다.

즉, 하나의 유스케이스를 수행할 때, 포함된 유스케이스가 반드시 수행되어야 한다.

 

ex) 게시글 작성/게시글 투표를 할 때 로그인이 반드시 수행

 

여러 유스케이스 (ex) 게시글 작성, 게시글 투표)에 나타난 공통적인 이벤트 흐름을 하나로 묶음으로써 중복을 방지한다.

▶ 포함 관계

 

3) 확장 관계 (Extend)

포함 관계처럼 여러 유스케이스에 걸쳐 중복적으로 사용되지 않고 특정 조건에서 한 유스케이스로만 확장되는 것을 의미한다.

 

포함 관계 vs 확장 관계

• 포함 관계: 여러 유스케이스에서 공통적으로 발견되는 시스템의 기능을 표현
• 확장 관계: 한 유스케이스에서 추가되거나 확장된 기능을 표현

이때, 확장하는 유스케이스 (ex) 동영상 업로드)는 상위 유스케이스 (ex) 게시글 작성)로부터 어떠한 특정 조건에 의해 수행되는 것을 의미한다.

▶ 확장 관계

 

4) 일반화 관계 (Generalization)

액터와 액터 간의 관계, 유스케이스와 유스케이스 사이의 정의이다. (상속, 액터와 유스케이스 간의 관계는 아님)

특정 유스케이스들이 한 유스케이스의 특수화된 유스케이스라는 의미이다.

 

확장 관계 vs 일반화 관계

• 확장 관계: 특정 조건이 충족될 때에만 확장되는 기능
• 일반화 관계: 하위 유스케이스는 상위 유스케이스에서 정의된 특징과 행동을 상속받아 공유 

즉, 확장 관계에서 하위 유스케이스는 상위 유스케이스와 엄연히 다른 기능을 의미하지만,

일반화 관계에서는 하위 유스케이스가 상위 유스케이스의 모든 기능을 담고 있다.

 

때문에, 하위 유스케이스는 항상 상위 유스케이스의 확장이라고도 할 수 있다.

▶ 일반화 관계

 

▶ 관계 예시

 

※ '잔액 부족 알림'과 '잔액 확인'은 아무런 관계가 없다는 점을 주의해야 한다. (직접 연결된 거 외엔 관계 없다고 표현)

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

Step 1: 구성요소 정의

• 유스케이스 다이어그램을 이루는 시스템, 액터, 유스케이스 정의

Step 2: 관계 정의

• 액터와 액터 사이의 관계 정의 (일반화 관계)
• 액터와 유스케이스 사이의 관계 정의 (연관 관계)
• 유스케이스와 유스케이스 사이의 관계 정의 (포함관계, 확장 관계)

Step 3: 유스케이스 구조화

• 두 개 이상의 유스케이스 간 공통된 서비스를 추출해 일반화 (일반화 관계)

액터를 찾기 위한 질문

• 누가 정보를 제공하고, 사용하고, 삭제하는가?
• 누가 또는 어떤 조직에서 개발될 시스템을 사용할 것인가?
• 누가 요구사항에 대해 관심을 가지고, 시스템이 만든 결과에 관심이 있는가?
• 개발될 시스템과 상호작용하는 하드웨어나 소프트웨어 시스템은 무엇인가? (외부 시스템)

유스케이스를 찾기 위한 질문

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

유스케이스 다이어그램 작성 예시 - 1

Step 1: 구성요소 정의

▶ 구성요소 정의

 

Step 2: 관계 정의

▶ 관계 정의

 

Step 3: 유스케이스 구조화

▶ 유스케이스 구조화

 

그리는 순서: 시스템 -> 액터 -> 액터간의 관계 -> 유스케이스, 관계

 

이때 관리자 액터를 만들면, '회원 관리'와 연결해 주면 된다. ('회원 조회', '회원 삭제'와 개별적으로 연결하는 것 아님)

 

※ 메인 액터는 왼쪽에, 외부 시스템은 왼쪽에 표시하는 게 일반적이다.

유스케이스 다이어그램 작성 예시 - 2

요구사항 예시

▶ 요구사항

 

Step 1: 구성요소 정의

▶ 구성요소 정의

 

Step 2: 관계 정의

▶ 관계 정의

 

Step 3: 유스케이스 구조화

▶ 유스케이스 구조화

 

이때, 모든 기능은 로근인 후 사용할 수 있다고 하였으므로,

'글을 검색한다'도 '로그인 한다'와 include 관계 표시를 추가로 해주어야 한다.

 

예시 1과 마찬가지로 '글쓴이로 검색한다', '날짜로 검색한다'를 '로그인 한다'와 개별 연결하면 안 된다.

⭐ 유스케이스 다이어그램 작성 예시 - 3

요구사항 예시

▶ 요구사항

 

※ 상품 관리 - 상속 -> 등록, 수정, 삭제

 

Step 1: 구성요소 정의

▶ 구성요소 정의 - 시스템

▶ 구성요소 정의 - 액터

▶ 구성요소 정의 - 유스케이스

 

Step 2, 3: 관계 정의, 유스케이스 구조화

▶ 관계 정의, 유스케이스 구조화

유스케이스 다이어그램 점검사항

점검사항

• 유스케이스 간에는 연관관계(Association)를 정의할 수 없음 (연관: 고객이 기능을 사용한다는 의미)
• 연관관계가 잘못된 것이 없는지 확인 ex) 고객 - 도서 검색 - 결제 시스템 (X) / 고객 - 도서 주문 - 결제 시스템 (O)
• 잘못된 유스케이스가 추출된 것은 없는지 확인 (시스템을 이용하는 사람의 입장에서 추출되어야 함)

▶ DB/웹서버관리는 시스템 자체의 기능으로 존재할 필요가 없이 단순 관리자에게 필요한 기능 (해당 액터, 유스케이스 제거)

 

물론, 시스템 자체가 DB/웹서버관리 기능을 사용자(관리자)에게 제공하고자 한다면 포함해야 한다.

이때는 관리자도 시스템을 사용하는 사용자이다.

(3) 요구사항의 문서화

요구분석 명세서 (SRS, Software Requirements Specification)

분석한 요구사항을 모두 빠짐없이 작성한 문서이다.

Use case diagram뿐만 아니라, 비기능적 요소도 담겨야 한다.

 

주의사항

• 사용자가 쉽게 읽고 이해할 수 있도록 작성 (사용자에게 확인 받음)
• 개발자가 설계와 코딩에 효과적으로 사용할 수 있도록 작성
• 테스트 기준으로 사용할 수 있도록 정량적으로 작성 (품질과 제약사항 등 비기능적 요구사항을 정량적으로 명확히 작성)

▶ 요구분석 명세서의 기본 항목

 

※ 제약 사항, 성능 요구 사항 등은 비기능적 요소이다.

(4) 요구사항 검증

요구사항 검증

• 요구분석 명세서가 정확학고 안전하게 서술되었는지 검토하는 활동
• 사용자의 요구사항이 완전하게 서술되었는지 검증
• 요구분석 명세서가 설계 단계에서 사용하기에 적합한지 확인

▶ 요구사항 검증

 

1. 완전성

• 사용자의 모든 요구 사항이 누락되지 않고 완전하게 반영되고 있는가?

2. 일관성

• 요구 사항이 서로 간에 모순되거나 충돌되는 점은 없는가?
• 산출물 또는 요구 사항의 내용이 일관성을 유지하고 있는가?

3. 명확성

• 서술된 명세서의 내용이 애매모호하지 않고 모든 참여자가 명확히 이해할 수 있는가?

4. 기능성

• 서술된 명세서가 '어떻게(How)'보다 '무엇을'에 관점을 두고 서술했는가?

5. 검증 가능성

• 서술된 명세서의 내용이 사용자의 요구를 만족하는가?
• 개발된 소프트웨어가 사용자가 요구하는 내용과 일치하는지를 검증할 수 있는가?

6. 추적 가능성

• 사용자 요구분석 명세서와 설계 사양서를 추적할 수 있는가? (요구분석 명세서와 설계 사양서  1:1 매칭 비교)

7. 변경 용이성

• 요구분석 명세서의 내용을 변경하고자 할 때 쉽게 찾아 변경할 수 있도록 작성되었는가?