소개
- 유스케이스 분석이란 무엇일까?
- 유즈케이스 분석, 어떻게 해야 할까?
- 유즈케이스 분석, 왜 해야 할까?
- 유스케이스 다이어그램의 활용
- 유스케이스와 객체지향
유즈케이스 분석, 왜 해야 할까?
애자일 방법론과 유즈케이스 분석
- 애자일 방법론과 유즈케이스 분석의 연관성은 유연한 요구사항 관리와 고객 중심 개발이라는 공통 목표를 갖는다는 점에서 공통 분모가 존재합니다. 두 가지 모두 사용자에게 가치를 제공하는 데 초점을 맞추고, 지속적인 피드백을 통해 요구사항을 반영하고 발전시키는 과정에서 강력한 시너지를 냅니다.
- 고객 중심 개발
- 유즈케이스 분석은 고객이나 사용자 관점에서 시스템이 제공해야 하는 기능을 명확하게 정의하도록 도와줍니다. 이를 통해, 개발 팀이 실질적으로 고객이 원하는 것을 제공하는 데 집중할 수 있습니다. 애자일의 핵심 원칙은 고객과의 긴밀한 협력을 통해 변화하는 요구사항에 신속하게 대응하는 것이기 때문입니다.
- 요구사항의 명확화
- 유즈케이스는 사용자와 시스템 간의 상호작용을 구체적으로 설명함으로써 요구사항을 명확하게 정의합니다. 이는 개발 팀이 무엇을 구현해야 하는지를 정확하게 파악하게 돕고, 모호함을 줄이며 개발 과정의 불확실성을 최소화합니다.
- 개발 우선순위 설정
- 사용자에게 가장 중요한 기능부터 개발할 수 있게 도와줍니다. 애자일 방법론에서는 작은 단위로 기능을 개발하고 반복적으로 배포하는 방식이므로, 유즈케이스는 어떤 기능이 우선순위가 높은지 판단하는 데 중요한 자료가 될 수 있습니다.
- 커뮤니케이션 도구
- 개발 팀뿐만 아니라, 비개발 직군 팀원과 소통하는데 활용할 수 있는 효과적인 도구가 될 수 있습니다. 간단하고 직관적으로 시스템 기능을 설명할 수 있어, 기술적인 용어를 모르는 사람들과도 요구사항을 논의하고 합의할 수 있습니다.
- 테스트 기반 제공
- 유즈케이스는 테스트 시나리오의 기본 틀을 제공합니다. 유즈케이스에서 정의한 사용자의 목표와 시나리오를 기반으로 테스트 케이스를 작성할 수 있어, 시스템이 실제로 고객의 요구사항을 충족하는지 확인하는 데 도움이 됩니다.
- 고객 중심 개발
- 만약, 유즈케이스 분석 없이 개발한다면?
- 유즈케이스 분석 없이 애자일 방법론을 적용하면 요구사항이 명확하지 않고, 팀 간의 소통이 원활하지 않으며, 고객이 원하는 기능을 제대로 구현하기 어려워질 수 있습니다. 또한 우선순위 설정과 테스트 기준이 불분명해지면서 프로젝트의 효율성과 품질 관리, 일정 관리에 문제를 일으킬 수 있습니다. 유즈케이스는 애자일에서 요구사항 관리와 커뮤니케이션의 핵심 도구로 작용하므로, 이를 생략할 경우 다양한 리스크가 발생할 가능성이 큽니다.
유즈케이스 분석, 어떻게 해야 할까?
유즈케이스의 주요 구성요소
- 범위 (Scope)
- 유즈케이스가 어떤 시스템을 대상으로 하는지를 정의한다.
- 수준 (Level)
- 유즈케이스의 수준은 상세화의 정도를 나타낸다. 이는 유즈케이스가 얼마나 구체적이고 세밀한 단계를 설명하는지에 따라 나눌 수 있다. 일반적으로 세 가지 수준으로 구분된다. 요약 수준, 사용자 목표 수준, 하위 기능 수준. 뒤로 갈수록 구체화 된다.
- 액터
- 정의
- 시스템과 상호작용하는 사용자나 외부 시스템을 의미합니다. 반드시 사람일 필요는 없고 시스템이나 하드웨어가 될 수도 있습니다. 예를 들어, 월부에서는 "고객", "관리자", "결제 시스템" 등이 액터가 될 수 있습니다.
- 분류
- 주요 액터 : 목적을 수행하기 위해 시스템의 서비스를 호출하는 주된 액터. ex) 관리자, 사용자
- 지원 액터 : 시스템을 지원하는 연관 서비스 ex) IamPort, Kollus
- 숨겨진 액터 : 유즈케이스 분석에서 명시적으로 드러나지 않지만, 시스템과 상호작용하거나 영향을 미치는 중요한 이해관계자 또는 시스템을 말함. ex) KISA (보안 감사 기관)
- 정의
- 시스템
- 유즈케이스에서 액터와 상호작용하는 주체인 시스템을 가리킵니다. 이는 사용자가 상호작용하고자 하는 대상입니다.
- 유즈케이스
- 액터가 특정 목표를 달성하기 위해 시스템과 상호작용하는 과정을 설명하는 시나리오입니다. 각 유즈케이스는 구체적인 기능이나 프로세스를 나타내며, 그 목표를 달성하기 위한 단계를 기술합니다.
- 시나리오
- 유즈케이스의 구체적인 흐름을 말합니다. 사용자가 시스템과 상호작용하는 과정을 단계별로 나열한 것입니다. 주로 정상 시나리오(사용자가 정상적으로 목표를 달성하는 경우)와 예외 시나리오(문제가 발생했을 때 대처 방안)를 포함합니다.
유스케이스의 정의 구조
샘플 예시
- 이름 : 유즈케이스 명을 나타내며, 보통 동사로 시작한다.
- 주요 액터
- 목표 : 액터가 시스템을 사용하여 이루려는 목적.
- 사전 조건 : 유즈케이스가 실행되기 위한 초기 상태나 조건.
- 사후 조건 : 유즈케이스 내의 주요 성공 시나리오나 다른 대안 경로의 성공적인 완료 후에 참이어야 하는 조건.
- 기본 흐름
- 액터와 시스템 간의 상호작용 과정에서 발생하는 일반적인 시나리오.
- 관련자의 관심 사항을 충족시키는 일반적인 성공 경로.
- 예외 흐름 : 예상치 못한 오류나 상황이 발생했을 때의 처리 과정.
- 예를 들어, 주요 성공 시나리오의 Step 3에서, 입력이 잘못되었거나, 시스템에 미리 등록이 안 된 경우 유효하지 않은 물건 ID가 발생될 수 있다.
- 3a: 첫 번째 유효하지 않는 물건 ID 발생 조건 + 대응 활동
- 3b: 두 번째 유효하지 않는 물건 ID 발생 조건 + 대응 활동
- 예를 들어, 주요 성공 시나리오의 Step 3에서, 입력이 잘못되었거나, 시스템에 미리 등록이 안 된 경우 유효하지 않은 물건 ID가 발생될 수 있다.
- 특수 요구 사항 : 주로 비기능적 요구 사항(non-functional requirements)을 기술함.
- 현재 유스케이스에서, 성능, 신뢰성, 사용성과 같은 품질에 관련된 요구사항을 기술함.
- ex) 카드 인증의 90%는 1초 이내에 응답되어야 한다.
- 현재 유스케이스에서, 성능, 신뢰성, 사용성과 같은 품질에 관련된 요구사항을 기술함.
참고자료
- 애자일 소프트웨어 개발 (저자: 로버트 C. 마틴)
- Use Case 2.0 (저자: Ivar Jacobson)
- Agile Manifesto
반응형
'CS' 카테고리의 다른 글
[Architecture] (2) 시스템 요구사항의 종류 (0) | 2023.06.08 |
---|---|
[Architecture] (1) 소프트웨어 아키텍처를 알아야 하는 이유 (0) | 2023.06.08 |
[CS] 프로그램, 프로세스, 쓰레드 (0) | 2022.06.18 |
[Network] 프로토콜 스택이란 무엇인가? (3) | 2020.11.17 |
댓글