시스템 유스 케이스와 시나리오

시스템 개발에 도전할 때, 시스템 엔지니어링 관점에서 물리적 설계 솔루션으로 전환될 수 있는 능력 요구사항 세트로 임무목표, 운용, 업무수행이 있다.
대부분 조직과 개인은 임무 목표로부터 시스템 성능 규격서(SPS)로 요구사항을 문서화하기까지 쉽게 처리하려고 한다.
그러나 이는 다음 두 가지 사항을 이해하지 않고서는 수행할 수가 없다.

① 사용자는 무슨 문제영역에 대한 해결을 원하는가?
② 문제영역의 전체 또는 일부분을 나타내기 위하여 임무수행을 위한 솔루션 영역을 어떻게 제시하려 하는가?

시스템이 더욱 복잡화됨에 따라 획득자에 의해 쉽게 이해할 수 있는 솔루션 개발 방법론을 요구하게 된다.
한 가지 방법은 임무목표와 규격 요구사항 사이의 간격을 줄이기 위해 시스템 유스 케이스와 시나리오를 사용하는 것이다.

1. 얻고자 하는 내용
· 시스템 유스 케이스란 무엇인가?
· 유스 케이스의 속성은 무엇인가?
· 유스 케이스 분석이란 무엇이며 어떻게 이를 수행하는가?
· 유스 케이스는 시스템 능력 요구사항과 어떻게 연관되어 있는가?

2. 주요 용어 정의
· 행위자 : “대응하는 활동 유닛의 부분으로서 이와 직접적으로 연관된 외부 시스템 대상으로서의 역할(하나의 유스 케이스를 말함). 행위자 요소는 외적 대상에 의해 이루어지는 역할을 말한다. 하나의 물리적 대상은 여러 가지 역할을 수행해도 되며, 따라서 여러 행위자에 의해 모델링 할 수 있다.”(UML 기호지침서 6.1.2 절 p.75)
· 운용 시나리오 : 시스템 개체 상호관계, 가정, 조건, 활동, 이벤트를 기술하고 있는 가정된 시나리오로서 이는 이미 기술되거나 가장 나쁜 조건하에서 발생 가능한 확률을 지니고 있어야 한다.
· 순서도 : 상호관계를 나타내는 도표로서, 원하는 운용 결과에 영향을 주는 협력 내에서의 대상으로 교환된 메시지 세트이다.(UML 기호지침서, 7.2.1절, p.80)
· 유스 케이스 : 사용자가 원하는 성능을 충족하는 산출물을 달성하기 위해 시스템, 제품 및 서비스의 배치, 운용, 지원 또는 폐기하는 방법을 표현하는 케이스.
· 유스 케이스 도표 : “행위자와 유스 케이스 그리고 일반화된 유스 케이스들 중 상호간 시스템 영역, 참여에 연관된 유스 케이스 세트인 행위자 그래프”(UML 기호지침서, 6.1.2절, p 75)
· 유스 케이스 시나리오 : 원하는 산출물 결과를 달성하기 위하여 고유의 능력을 요구하는 운용환경에서 임무 시스템 유스 케이스로 수행되는 상태 세트를 말한다. 시나리오에는 사용자가 처해 있는 위협에 대하여 어떻게 시스템, 제품 및 서비스를 적용, 미적용, 사용, 미사용, 또는 폐기하는지를 고려해야 한다.

유스 케이스와 시나리오 분석 콘텍스트

유스 케이스와 시나리오 분석 콘텍스트를 나타내는 참조 구조와 그 중요성을 그림 1에 보여주고 있다. 이 그림의 개체 관계는 세 가지 도메인으로 구분된다. 운용 도메인, 분석 도메인, 엔지니어링 도메인이다. 이러한 구조에 따라 이들의 관계를 살펴보자.

· 각 임무는 최소 하나 또는 그 이상의 임무목표로 되어 있다.
· 각 임무목표는 임무 시스템과 지원 시스템으로 이행되는 임무운용 통합 세트로 수행된다.
· 각 임무 시스템과 지원 시스템 운용은 순서적이고 동시적인 활동의 계층구조적인 체인으로 분할된다.
· 각 활동은 하나 또는 그 이상의 성능 표준으로 수행되고 측정된다. 그리고 최소한 하나 또는 그 이상의 유스 케이스로 적용된다.
· 각 유스 케이스는 최소한 하나 또는 그 이상의 유스 케이스 시나리오로 구속된다.
· 각 유스 케이스 시나리오는 그 유스 케이스가 어떻게 적용, 사용, 미사용, 거절 등으로 나타나는지, 그리고 하나 또는 그 이상의 요구 운용능력으로 전환되는지를 나타낸다.
· 요구 운용능력은 시스템, 제품 또는 서비스가 각 유스 케이스를 이행하기 위해 무엇을 수행해야 하는지를 식별한다. 그리고 다양한 유스 케이스 시나리오를 수용하고, 최소한 하나 또는 그 이상의 성능 요구사항을 계량화해야 한다.

이와 같은 구조는 시스템 유스 케이스와 시나리오를 논의함에 있어서 논의의 기반을 제공해 준다.



유스 케이스란 무엇인가?

유스 케이스란 사용자가 어떻게 시스템을 배치하고 작동하며 지원하거나 폐기하는지에 대한 여러 가지 속성 세트를 나타낸 것이다.
유스 케이스를 개발하기 위한 체크 리스트로서의 속성을 살펴보면 다음과 같다.

· 고유 식별자
· 목표
· 산출물에 근거한 결과
· 가정 : 초기 상태, 최종 상태, 환경조건, 이전의 주위환경(옵션), 운용 제약사항, 외부 입력, 이벤트에 근거한 시계열, 발생주기 및 유틸리티 우선순위
· 프로세싱 능력
· 시나리오 및 결과 : 발생 주기, 유스 케이스 시나리오 행위자, 자극 및 반응, 결과, 보상/완화 활동

주어진 목록에 따라 각 항목과 특성에 따른 기여도를 간략하게 살펴보자.

1. 고유 식별자
각 유스 케이스는 자신의 유일한 정체성을 가지고 있어야 한다. 이는 다른 유스 케이스와 중복, 마찰, 또는 이중으로 나타나지 않아야 한다.

2. 목표
각 유스 케이스는 최소한 하나 또는 그 이상의 산출물에 근거한 성능 목표를 지녀야 한다.

3. 산출물에 근거한 결과
유스 케이스는 원하는 산출물에 근거한 목표를 달성하기 위하여 만지거나 만질 수 없는 하나 또는 그 이상의 시스템/개체 거동, 제품, 부산물, 서비스를 나타내어야 한다.

4. 가정
유스 케이스의 형성은 유스 케이스를 시작하는 기초를 형성하는 초기 조건을 나타내는 가정 사항을 시스템 엔지니어가 제시하도록 요구하고 있다.

· 초기 상태 : 유스 케이스의 초기 상태는 유스 케이스가 시작할 때, 시스템, 제품 또는 서비스에 대한 가정된 물리적 작동 상태를 말한다.
· 최종 상태 : 최종 상태란 원하는 결과가 달성되었을 때 원하는 시스템의 물리적 또는 작동상태를 나타낸다.
· 환경조건 : 나타난 현재의 환경조건이 시스템, 제품 또는 서비스 유스 케이스가 시현될 때 처하고 있는 운용환경 조건을 구속한다.
· 이전의 주위환경(옵션) : 어떠한 애플리케이션의 경우, 유스 케이스 시작단계로 나아가는 이벤트의 주위환경이나 순서를 식별할 필요가 있다. 이전의 주위환경은 이러한 가정을 문서화함에 기초를 제공해 준다.
· 운용 제약사항 : 어떠한 유스 케이스의 경우, 1)시스템, 제품 또는 서비스가 운용정책, 절차, 업무순서 2)지역, 연방, 주, 국제규범이나 법률 3)공공 견해 4)임무 이벤트 시계열 (MET)과 같은 운용 제약사항을 가지고 있다. 이처럼 운용 제약사항은 유스 케이스에 허용된 협력, 도덕, 양심, 또는 영적 활동을 구속하거나 제한토록 한다.
· 외부 입력사항 : 모든 시스템, 제품, 서비스는 주어진 산출물을 얻기 위하여 가치를 추가하기 위한 외부 입력사항을 사용한다.
· 자원 : 모든 시스템, 제품, 서비스는 주어진 임무를 달성하기 위하여 임무 자원을 필요로 한다. 임무 자원은 전형적으로 한정되어 있으며, 따라서 제약되어 있다. 자원의 속성은 시스템/개체 운용을 유지하기 위하여 무슨 형태의 자원이 요구되는지를 문서화 한다.
· 이벤트를 근거한 시계열 : 유스 케이스는 시스템이나 운용자로부터 기대 반응, 예정된 활동, 인적 운용자의 간섭을 동기화하기 위한 임무 이벤트 시계열 (MET)을 요구 한다.
· 발생주기 및 유틸리티 우선순위 : 모든 유스 케이스는 개발, 훈련, 적용 및 유지보수를 위한 비용과 일정을 필요로 한다. 비용과 일정을 포함한 예산의 실정은 실제 적용할 수 있는 수많은 유스 케이스를 제한한다. 따라서 유스 케이스를 우선순위로 조정해야 하며 사용자에게 보다 큰 유틸리티를 안전하게 최대화할 수 있도록 적용되어야 한다. 또한, 애플리케이션 극대화와 안전한 유틸리티를 주목해야 한다. 만일 유스 케이스를 우선순위로 매긴다면, 위기능력과 절차가 가장 늦게 일어나는 발생 주기를 살펴보아야 한다. 더구나 이는 매우 치명적인 요소이다. 만일 절충 평가기준과 같은 경우라면, 다중 요소 항목으로 유틸리티를 분석적으로 표현하기 위하여 요구토록 한다. 각 유스 케이스에 작게는 1로부터 높게는 5까지 가중치 요소를 유스 케이스에 적용하는 대신에 안전 관점에서 적합한 결과를 도출하기 위하여 작게는 1로부터 높게는 5까지 치명도 수준을 그 요소에 승해야 한다.

상용조직의 경우, 이윤을 남기고 시장에서 제품과 서비스를 팔고, 오랜 기간 비즈니스 운용을 유지토록 한다. 조직적인 제품과 서비스는 사용자로 하여금 배치, 운용, 지원함에 있어서 안전해야 한다. 가설적으로 모든 자원을 안전에 초점을 두어야 하며, 사용자에게 안전관계로 애플리케이션 유틸리티가 없는 제품을 생산하는 경우도 발생할 수 있다.
우리의 논의가 제품이나 서비스 생산에 초점을 두고 있다 할지라도, 시스템은 장비(인력, 절차 데이터 등)보다 다른 요소를 지니고 있다는 사실을 유념토록 하라. 따라서 설계비용이 증가하는 경우가 발생할지라도 운용자 인증, 교육훈련 및 주기적인 보충교육, 경고 라벨 및 제품 적용과는 무관한 감독과 같은 안전성을 증가시키는 효과적인 대안을 고려해야 한다.

5. 프로세싱 능력
유스 케이스의 중심은 원하거나 요구하는 산출물을 생산하기 위하여 특정 상태를 처리하는 자극-반응에 초점을 맞추어야 한다. 이러한 도메인은 전환 또는 반응 기능으로 나타난다. 다음과 같은 예를 살펴보자.

<예제 1> 광전지나 태양전지는 햇빛을 전기 에너지로 전환한다.

여기에서의 콘텍스트는 하나의 시스템이나 입력과 출력을 가진 어느 추상적 레벨에서의 한 품목을 나타내는 단순한 박스이다. 솔루션 영역에 대한 단순화에 초점을 두라. 다중 레벨을 동시적으로 다루는 절차적 시도를 피하도록 하여라.

6. 시나리오와 결과
일반적으로 사람들은 모든 것이 잘 될 것이라는 사실을 낙관적으로 믿으려고 한다. 이는 대부분은 사실이지만, 우리가 운용면 또는 시스템, 제품 및 서비스 능력으로 계획하지 않았던 상태가 발생할 불확실성이 일어나게 된다. 한 번 유스 케이스로 식별되고 나면 사용자가 언제 이러한 유스 케이스를 수행하게 되는지에 대한 질문을 해 보아라.

· 만일 일어나지 않는다면 무엇이 잘 못될 수 있는가?
· 이러한 결함 결과는 무엇이며 우리는 이를 어떻게 완화할 것인가?

우리는 이러한 경우를 유스 케이스 시나리오 및 결과라고 한다. 다음 예제를 살펴보라.

<예제 2> 우리가 CD나 DVD를 설계한다고 가정하자. 이론적으로 상위레벨 CD/DVD 유스 케이스는 CD/DVD를 플레이어에 삽입하는 사용자를 기술한다. 그리고 매직이 일어나게 된다. 사용자는 그 결과를 음악이나 무비로 얻게 된다. 이와 같이 사용자는 긍정적인 결과를 가져다주는 유스 케이스 시나리오를 얻게 된다. 이제 사용자가 CD/DVD를 거꾸로 삽입한다면 무슨 일이 발생할 수 있는가? 사용자는 부정적인 결과를 가져다주는 유스 케이스 시나리오를 갖게 된다. 이는 다음과 같은 질문을 가지게 된다. 우리가 CD/DVD를 설계할 때, 사용자는 이러한 경우에 어떻게 처방하도록 되어 있는가를 살펴보아야 한다. 만일 우리가 어떠한 조치를 기기 설계에 반영한다면, 설계비용이 증가하게 된다. 반대로 적은 비용의 솔루션은 항상 전면이 삽입될 수 있도록 CD/DVD 사용자 매뉴얼에 단순하게 제시하는 길이 있다.

· 발생확률 : 한번 유스 케이스 시나리오가 식별되고 나면, 각 경우에 대한 발생확률을 결정하게 된다. 유스 케이스 우선순위에 대해 앞서 논의한 대로 시나리오는 발생확률을 가지고 있다. 추가적인 설계 형태는 비용을 수반하게 됨으로 사용자 시나리오 선정 시 가장 중요한 요소로 안전을 고려해야 한다.
· 유스 케이스 시나리오 행위자 : 지금까지 우리의 논의 대상은 가장 많이 발생할 수 있는 유스 케이스나 시나리오가 무엇인지에 대하여 초점을 두었다. 주요한 질문은 유스 케이스와 시나리오 이행 시 상호관계를 누가 무엇으로 할 것인지에 대한 것이다. UML(Unified Modeling Language)은 ‘행위자’로 이러한 속성을 나타낸다.

이러한 행위자는 사람, 장소, 실제 또는 가상 목표나 이벤트일 수 있다. UML은 그림 2에 나타난 바와 같이 타원 속의 유스 케이스와 연결된 선으로 행위자를 나타낸다. 여기서 공통 모델링 언어(UML: Unified Modelling Language)를 사용한다.

사용자 1(행위자) : 유스 케이스 1에서 3까지 관계하는 시스템 행정요원/유지보수요원
사용자 2(행위자) : 유스 케이스 1과 3(능력)
사용자 3(행위자) : 유스 케이스 3(능력)



앞서 예제에서의 행위자는 사용자, CD/DVD, CD/DVD 플레이어이다.
· 자극과 반응 : 유스 케이스란 시스템 운용자, 외부 시스템, 또는 시스템에 의해 수행되는 활동 세트로 초기에 나타난다. 다음과 같은 자극-반응 활동을 생각해 보자.
­- 사용자 또는 외부 시스템은 주어진 특정 시간 내에 시스템의 거동으로 나타나는 하나 또는 그 이상의 활동으로 시작된다.
- ­시스템은 의사결정이나 입력 데이터를 만들어 이행될 활동을 사용자에게 알려준다.
- ­사용자는 시스템에 따라 수행되는 활동을 방해하거나 간섭한다.
이러한 예제들은 사용자나 시스템이 다른 행위자에게 활동을 자극하는 예를 보여주고 있다. 그림 3은 UML 순서도로 나타낸 활동순서를 보여주고 있다.



· 시나리오 결과 : 각 유스 케이스와 시나리오는 결과를 나타내는 산출물을 가져다준다. 다음 예제를 살펴보자.

<예제 3> 만일 시나리오 X가 일어나고 운용자나 시스템이 특정 방법으로 나타난다면, 불안정과 동요가 시스템에 부정적인 결과를 초래하게 된다. 따라서 각 유스 케이스와 시나리오는 적절한 사용/미사용, 적용/미적용 및 거절 등의 잠재적인 결과를 가져오게 된다.

· 보상과 활동 완화 : 주어진 유스 케이스와 유스 케이스 시나리오로 식별된 결과 세트에서 우리는 무슨 보상/완화활동이 부정적인 산출물 결과에 대한 영향을 제거하거나 최소화하기 위하여 시스템, 제품 또는 서비스로 나타나야 하는지를 식별할 필요가 있다. 다음 예제를 살펴보자.

<예제 4> 우리가 자동차를 설계한다고 하자. 자동차는 다른 차, 벽, 또는 나무와 충돌할 가능성이 있기 때문에 외부 시스템에 대한 자동차 바디의 일반적인 인터페이스 솔루션은 불충분하다. 유스 케이스와 유스 케이스 시나리오 분석은 승객은 생명을 잃거나 충돌로 인한 부상을 가져온다는 사실을 반영해야 한다. 따라서 범퍼의 특정 인터페이스는 보상/완화 활동으로서의 자동차 구조에 추가되어야 한다. 그러나 충돌시험은 범퍼가 불충분하다고 나타남으로써 다음 설계활동의 사례로 보다 특정의 솔루션을 요구하게 된다.

설계활동 1 : 자동차 범퍼에 완충장치를 추가
설계활동 2 : 시트벨트 사용 요구 및 설치
설계활동 3 : 에어백 시스템 장착
설계활동 4 : ABS Anti-lock 브레이크 시스템 장착
설계활동 5 : 적절한 자동차 운용절차를 제시
설계활동 6 : 운전자로 하여금 방어운전교육 증대

유스 케이스 분석

각 유스 케이스와 이와 유사한 시나리오는 행위자 중에 일련의 연관된 상호작용을 나타낸다. 한 번 시나리오와 행위자가 식별되고 나면, 시스템 분석가는 대상 시스템 운용환경 내에서 시스템이나 대상 및 외부 시스템 속성 간에 유사한 상호작용을 이해할 필요가 있다.
UML 도구는 시스템 상호간 자극, 반응, 거동 반응을 이해하는 데 매우 유용하다. 순서도는 주요 도구로 활용된다. 순서도는 그림 4에 나타난 바와 같이 행위자와 연결선으로 구성된다.



행위자(Actors)는 시스템, 제품 및 하부 시스템과 같은 주어진 추상적 레벨에서의 속성과 추상적인 운용환경 내에서 외부 시스템으로 구성된다.
예를 들면, 하부 시스템 유스 케이스는 가용하다면 다른 하부 시스템과 물리적 환경조건과 같은 시스템 운용자와 외부 시스템을 보여준다.
연결선(Lifeline)은 시간성에 따른 절차를 나타내는 수직선으로 나타난다. 바는 속성활동이나 외부 입력, 자극, 또는 반응과 거동 반응 절차를 나타내기 위하여 연결선을 따라 그려진다.
Swim Lanes은 순서적 작동, 업무, 제품, 부산품 또는 서비스 상호관계 및 각 행위자 사이에 교류를 나타내기 위하여 행위자 연결선 간 영역으로 구성된다.
어떻게 이를 나타내는지 보기 위해 다음 예제를 생각해 보자.

<예제 5> 한 사용자(행위자)가 셈을 하여 그 결과를 보기 위해 계산기(행위자)를 사용한다고 가정하자. 그림 4는 아주 단순한 상호관계를 나타내고 있다. 그림 4는 구조적으로 유사하게 나타나며, 그림 3의 세부 레벨까지 확장된다. 이러한 예제를 단순하게 다루기 위해 계산기가 하부 시스템 1과 2 두 개로 구성되어 있다고 한다.

사용자와 하부 시스템의 각 요소는 초기 상태와 최종 상태를 가지고 있으며, 특정 의사결정 판단이 주어질 때까지 순환하는 조건부 루프가 작동을 중지할 때까지 이루어진다. 우리는 각각의 하부 시스템 활동이 입력 대기상태를 포함하고 있다.
입력이 시작되면 과정이 수행되고 다음 활동으로 넘어가기 위한 통제가 시작된다. 여기 잠재된 유스 케이스 시나리오를 기술해 보자.

· 하부 시스템 1은 키보드를 통해 사용자 입력을 기다리는 활동 20을 수행한다.
· 활동 10 시스템 운용자가 데이터를 출력 10으로 들어갈 때, 활동 20은 운용자 키보드 삽입을 수용하고 그 정보를 출력 20으로 기기의 볼 수 있는 코드로 전환한다.
· 하부 시스템 2는 다음 사항을 수행한다. 1)데이터 입력을 기다리는 활동 30, 2)요구하는 셈을 수행하기 위한 활동 31과 셈 결과를 출력 31로 제시 한다.
· 하부 시스템 활동 21 중간에서 다음 활동을 수행한다. 1)출력 31 결과를 대기, 2)그 결과를 운용자 정보로 전환, 3)그 결과를 출력 21로 전시한다.
· 데이터를 입력한다. 예를 들면, 활동 10에 따라, 시스템 운용자는 활동 11을 다음과 같이 수행한다. 1)출력 21 결과를 대기, 2)그 결과를 기록, 3)그 결과를 출력 11로 제시 한다.

이러한 사이클은 최종 상태인 계산기 작동을 끌 때까지 계속된다.

1. 얼마나 많은 유스 케이스가 있는가?
사람들이 자주 질문하는 내용은 얼마나 많은 유스 케이스가 대상 시스템에 요구되느냐는 것이다. 이에 대한 구체적인 답은 없다. 그러나 10에서 30까지의 유스 케이스가 평균적이다.
몇 매우 복잡한 시스템의 경우에 5에서 6까지 유스 케이스가 있지만, 다른 경우에는 10에서 20까지 있다. 이 모든 것은 포함된 사람이나 조직에 달려있다. 어떤 사람은 단순하게 그 수를 적게 하려 하고 또 어떤 사람은 세부적인 목록을 원하는 경우도 있다.
하나의 시스템이 5에서 8까지 주요 일차적 유스 케이스를 지니고 있다고 생각하라. 그 나머지는 일차적인 유스 케이스를 지원하는 2차 또는 종속적인 유스 케이스이다.

유스 케이스와 요구사항 규격과의 관계

유스 케이스 적용은 시스템 설계에 매우 유용하지만 왜 이를 여기서 언급하는지를 유의해야 한다. 여기에는 세 가지 이유가 있다.

유스 케이스는 사용자와 함께 그들의 필요성을 이해하고 그들이 시스템을 보다 기술적으로 나타내기 위하여 배치, 운용, 지원할 방법을 전환하기 위해 획득부서의 시스템 엔지니어에게 매우 유용한 도구이다.
유스 케이스는 사용자가 쉽게 이해할 수 있는 특정 시스템 형태와 연관된 능력을 특화시킨다. 이는 사용자에게 의미가 있든 없든 관심 있는 추상적인 시스템 요구사항 언어를 작성하기 위한 요구를 피하고 있다.
한 번 유스 케이스와 시나리오가 식별되고 우선순위가 주어지고 나면, 그들은 시스템, 제품, 또는 서비스 획득을 위해 적합한 요구규격으로 전환하기 위한 기초를 제공해 준다.
획득자 규격으로부터 도출될 수 있는 유스 케이스는 시스템 개발자가 시스템 운용개념과 설계 솔루션을 형성하기 위한 메커니즘을 제공한다.

고려사항

시스템 엔지니어링 관점에서 유스 케이스 분석은 그 어떠한 시스템 개발 노력에 있어서 중요한 도구이다. 그러나 엔지니어는 가끔 이러한 활동을 사용자와 제품에 영양가 없는 문서행위에 불과하다고 생각하고 있으며, 이러한 노력과 시간은 오히려 보다 정교한 설계에 치중하는 것보다 못하다고 생각한다. 그러나 실상은 사용자가 임무를 수행하기 위하여 현재 기술 세트로 그들을 쉽고 수용 가능하게 적용하지 않으면, 대부분의 정교한 설계란 불필요하다는 것이다. 바로 이것이 시스템 수락과 납품 이전에 발생되는 시스템 운용자 교육훈련이 적기에 이루어져야 한다는 이유다.
분쟁을 가져다주는 사람들은 시스템 통합과 시험기간 중에 대상 시스템이 불합격되고 난 다음에 내가 사용자가 무엇을 원하는지를 어떻게 아느냐고 대드는 경우와 똑같다. 나는 사람이지 신이 아니다. 그들이 원했던 것을 그들은 몰랐고 의사를 결정한 바가 없다는 것이다. 이러한 경우 유스 케이스를 문서화하는 것이 바람직하다.
오늘날 엔지니어링 노력을 잃어 버리지 않도록 전문적인 훈련이 필요하다. 만일 당신이 이를 의심한다면, 당신은 얼마나 많은 시스템에 실패했으며, 시스템 개발자 조직 내에서 사용자와 협의를 방해했는지를 생각해 보라. 이러한 경험이 있다면, 이러한 절차가 왜 필요하며 시스템, 제품, 서비스 사용자의 성공적인 수락이 중요한지를 쉽게 이해할 수 있다.

기본 원칙

앞서 논의된 사항들은 시스템 유스 케이스와 시나리오를 제시하는 기본 원칙을 설정하는 기초를 제공해 준다.

원칙 1 : 모든 유스 케이스는 긍정적 산출물과 부정적 산출물을 가진 최소한 하나 또는 둘 이상의 시나리오를 가지고 있다. 당신의 임무는 시스템 엔지니어로서 위험을 완화시키고 긍정적인 산출물을 최대화함에 있다.

원칙 2 : 모든 유스 케이스, 시나리오, 요구사항은 사용자에게 가치, 적용하기 위한 비용, 수용 가능한 운용 위험 레벨을 지니고 있다.

원칙 3 : 모든 시스템 임무는 하나 또는 그 이상의 능력 기반 유스 케이스로 구성되어 있다.

요약

시스템 유스 케이스와 시나리오에 대한 우리의 논의는 사용자의 요구사항과 시스템 설계 사이에 터무니없는 착오를 없애기 위해 유스 케이스를 사용하는 데 그 목적이 있다. 우리는 유스 케이스와 시나리오는 사용자, 획득자, 시스템 개발자에게 유력한 도구를 제공하고 있음을 보았다. 그들은 상호 커뮤니케이션을 증진시키고 장차 원하는 시스템이 어떻게 납품되고, 운용되며, 지원되는지를 이해하기 위해 사용될 수 있다.

· 유스 케이스는 적용 시 주요 사용자 요구사항을 식별하고 우선순위를 부여하기 위한 수단을 제공한다.
· 유스 케이스는 기술, 비용, 일정의 제약사항을 계획하기 위하여 개발에 대한 가장 유사한 발생확률에 근거한 우선순위를 결정해야 한다.
· 유스 케이스 시나리오는 사용자가 시스템, 제품 또는 서비스 사용법뿐만 아니라, 잘못 사용 시 어떠한 위험한 결과를 초래할 것인지 그리고 이를 어떻게 보상하거나 완화하는 설계 활동을 요구하는지를 이해하는 근거가 된다.
· 유스 케이스 시나리오는 유스 케이스의 기술, 비용 및 일정 제약사항 내에서 우선순위를 부여해야 한다.
· 유스 케이스 속성은 각 유스 케이스를 일정하게 그리고 일관되게 나타내는 표준 구조를 제공한다.
· UML 상관도표는 행위자 상호관계와 거동에 대한 반응을 이해하기 위한 유용한 도구로 사용된다.
· 각 유스 케이스와 속성은 문서화되고 의사결정을 위한 관리적 통제기준에 따라 다루어져야 한다.

1. 유의사항
통합 모델링 언어(UML : Unified Modeling Language)는 객체 관리 그룹 (OMG: Object Management Group)의 등록된 상표이다.

2. 일반적 예제
개요에서 제시된 이 글의 내용에서 무엇을 이해했는지를 설명해 보라.
앞 장에서 사용했던 시스템이나 새로운 시스템을 선택하여 이 글의 토픽에서 도출된 지식을 적용해 보라. 다음과 같은 내용을 포함해 보라.

· 시스템 행위자
· 시스템 유스 케이스
· 시스템 유스 케이스 선도
· 유스 케이스 순서도

3. 조직 중심 예제
시스템 능력과 요구사항을 도출하기 위하여 유스 케이스와 시나리오를 적용하고 있는 조직 내의 프로젝트를 검토해 보라.

· 이들은 계약자 또는 프로그램 의사결정기구에 의해 요구된 것인가?
· 프로그램에 관한 경험은 무엇인가?
· 팀은 유스 케이스와 시나리오를 분석하는 데 적합한 사람들인가?
· 유스 케이스 분석을 위해 어떠한 도구를 사용하고 있 는가?
· 유스 케이스와 시나리오는 어떻게 문서화되어 있는가?
· 유스 케이스와 시나리오가 요구규격에 어떻게 프로그램으로 연결되어 있는가?

민성기 시스템체계공학원장(ise@seinstitute.co.kr)