목적
  • 유스 케이스에 대한 소프트웨어 개발을 시작할 수 있도록 하나 이상의 유스 케이스의 이벤트 플로우에 대해 자세히 설명합니다.
  • 액터 대표 또는 고객이 이해하고 만족할 수 있도록 유스 케이스 스펙에 대해 설명합니다.
역할:  요구사항 지정자 
빈도:  반복에 자세히 설명된 각 유스 케이스 및 유스 케이스 플로우의 경우, 반복당 한 번 
단계
자세한 정보: 
입력물:    결과물:   
툴 강좌:   

워크플로우 세부사항:   

시나리오 검토 및 정제 페이지 맨 위

개발 주기에서 다루게 될 시나리오의 검토 및 정제에서부터 시작하십시오. 이는 초기에 활동: 액터 및 유스 케이스 찾기에서 이미 식별되었을 수도 있습니다. 기술할 플로우의 범위를 결정할 때 이 열거된 시나리오를 시작 시점으로 사용하십시오.

스토리보드는 유스 케이스 플로우를 이해하고 설명하는 데 도움이 됩니다 이미 개발된 시나리오가 있을 경우, 고려할 다른 입력은 사용자 인터페이스 프로토타입입니다.

이벤트 플로우 설명 페이지 맨 위

이벤트의 유스 케이스 플로우는 이미 윤곽이 드러나 있고 단계별로 설명이 되어 있어야 합니다. 이는 활동: 액터 및 유스 케이스 찾기에서도 작성됩니다. 이 단계별 윤곽을 시작점으로 사용하고 점차적으로 세부사항을 작성하십시오.

프로젝트에 지정된 표준에 따라 유스 케이스를 기술하십시오. 유스 케이스에서 일관성을 유지할 수 있도록 유스 케이스를 기술하기 전에 다음과 같은 지점을 결정하십시오.

  • 유스 케이스를 시작하는 방법. 유스 케이스의 시작은 유스 케이스를 활성화하는 신호를 명확히 기술해야 합니다. 예를 들어, "예는 ...가 발생할 때 시작할 수 있습니다."라고 쓰십시오.
  • 유스 케이스를 종료하는 방법. 플로우 과정에서 어떤 일이 발생할 때 유스 케이스를 종료하는지 명확히 설명해야 합니다. 예를 들어. "...가 발생할 때 유스 케이스를 종료합니다."라고 쓰십시오.
  • 유스 케이스가 액터와 상호작용하는 방법. 위험을 오인하는 것을 최소화하기 위해 시스템 내부와 시스템 외부에 존재하는 위험에 대해 정확히 설명하십시오. 일련의 단락을 사용하여 설명을 구축하십시오. 이 경우 각 단락은 "액터가 ...을 수행하면 시스템은 ...을 수행합니다."와 같은 형식의 조치를 표현합니다. "조작원으로부터 '시작' 신호를 받으면 유스 케이스가 시작됩니다" 와 같이 유스 케이스가 액터에게 보내는 신호와 액터로부터 받는 신호를 설명하여 상호작용을 강조할 수도 있습니다.
  • 유스 케이스가 액터와 데이터를 교환하는 방법. 원할 경우, 신호 인수를 참조할 수 있으나 "사용자가 이름과 암호를 제공하고 시스템에 로그인할 때 유스 케이스를 시작합니다."와 같이 쓰는 것이 더 좋을 수 있습니다.
  • 유스 케이스가 어떤 행위를 반복하는 방법. 이를 자연 언어로 표현하도록 노력해야 합니다. 그러나 예외로 해당 자연 언어 용어가 표현하기에 어려운 경우 "WHILE-END WHILE," "IF-THEN-ELSE" 및 "LOOP-END LOOP"와 같이 코드 구문을 사용하는 것이 나을 수도 있습니다. 그러나 일반적으로 읽고 유지보수하기가 어렵기 때문에 유스 케이스 설명에 코드 구문을 사용하는 것은 피하는 것이 좋습니다.
  • 이벤트의 유스 케이스 플로우에 다른 선택적 상황은 없습니까? 종종 액터에게 여러 가지 선택사항이 제시될 수 있습니다. 이는 동일한 방법으로 작성되어야 합니다. 예를 들면, 다음과 같습니다.

    " 액터는 다음 중 하나를 한 번 이상 선택합니다.

    a) . . .

    b) . . .

    c) . . ." 등

  • 사용자 및 고객이 이해할 수 있게 하려면 유스 케이스를 어떻게 설명해야 합니까? 유스 케이스, 액터 및 신호와 같은 방법론 특정 용어를 사용하면 불필요하게 텍스트가 이해하기 어려워집니다. 텍스트를 읽기 쉽게 만들기 위해 조치를 열거하거나 몇몇 다른 전략을 채택할 수 있습니다. 일반 유스 케이스 모델링 가이드라인에 사용하는 모든 전략이 지정되어 있어야만 전체 유스 케이스 기술 활동 중에 이를 유념할 수 있습니다.

시스템 내부에 해당하는 특정 문제점을 해결하는 방법이 아니라 유스 케이스 내에서 수행되는 작업을 기술하는 데 중점을 두십시오. 객체 모델에 대해 작업할 때 작업 방법에 대한 세부사항으로 설명을 보완하여 이 시점에 설명이 지나치게 자세해지지 않게 하십시오. 나중에도 변하지 않을 내용만 기술하십시오.

이벤트의 유스 케이스 플로우가 너무 광범위하거나 복잡할 경우 또는 다른 부분과 독립된 부분이 있는 경우, 유스 케이스를 여러 개의 유스 케이스로 나누십시오.

설명 텍스트를 작성할 때 용어집을 참조하십시오. 새로운 개념에서 새로운 용어가 생기기 때문에 용어집에 이를 포함시키십시오. 해당 프로젝트 구성원에게 알리지 않고 용어의 정의를 변경하지 마십시오.

이벤트 플로우 설명의 개념

이벤트 플로우 설명은 다음을 탐색합니다.

  • 유스 케이스를 시작하는 방법 및 시기
예:

"사용자가 '주문 관리' 기능을 활성화하면 유스 케이스를 시작할 수 있습니다. "

  • 유스 케이스가 액터와 상호작용하는 시기 및 이들이 교환하는 데이터
예:

"새 주문을 작성하기 위해 사용자는 '새로 작성' 기능을 활성화한 다음 주문과 관련된 필수 데이터(이름, 네트워크 요소(최소한 하나) 및 측정 기능의 유형)를 지정합니다. 주문: 설명과 관련된 선택적 데이터를 지정할 수도 있습니다(간단한 텍스트 설명). 그런 다음 사용자가 '확인' 기능을 활성화하면 시스템에 새 주문이 작성됩니다. "

참고: 액터 및 유스 케이스 간에 교환하는 데이터를 명시해야 합니다. 그렇지 않으면 고객 및 사용자가 유스 케이스 설명을 이해하지 못할 수도 있습니다.

  • 유스 케이스가 시스템에 저장된 데이터를 사용하거나 시스템에 데이터를 저장하는 방법 및 시기
예:

"사용자는 '수정' 기능을 활성화하여 기존의 주문을 수정하고 주문 번호(작은 정수)를 지정합니다. 그러면 시스템은 주문 이름, 해당 네트워크 요소 및 특정 기능 유형으로 주문 양식을 초기화합니다. 이 데이터는 보조 기억장치에서 검색됩니다. "

  • 유스 케이스를 종료하는 방법 및 시기
예:

"주문자가 '종료' 기능을 활성화하면 유스 케이스가 종료됩니다."

특별하거나 예외적인 이벤트 플로우도 기술해야 합니다. 예외 플로우는 유스 케이스의 정상 또는 기본 작동을 따르지 않는 유스 케이스의 서브플로우입니다. 유스 케이스의 작동에 대해 완벽히 설명하려면 이 플로우가 반드시 필요합니다. 첫 번째 예에 제공된 플로우가 예외 플로우의 일반적인 예입니다. 유스 케이스가 예상치 않은 데이터를 받으면(액터가 특정 컨텍스트에서 예상한 액터가 아님) 종료됩니다. 잘못된 액터가 있어서 미리 종료하는 것은 이벤트의 일반 플로우에는 있지 않습니다.

유스 케이스를 기술할 때 고려할 기타 "할 것과 하지 말아야 할 것"에는 다음이 포함됩니다.

  • 단지 유스 케이스의 기능 또는 목적이 아니라 이벤트 플로우를 기술하십시오.
  • 동시에 작동하는 다른 유스 케이스에서 진행되는 플로우가 아니라 유스 케이스에 속한 플로우에 대해서만 기술하십시오.
  • 질문에 있는 유스 케이스와 통신하지 않는 액터는 언급하지 마십시오.
  • 모든 액터와 유스 케이스의 상호작용을 기술할 때 너무 자세한 내용을 제공하지 마십시오.
  • 유스 케이스에 대해 기술된 서브플로우의 주문이 수정되지 않은 경우 수정된 것처럼 기술하지 마십시오.
  • 공통 용어집의 용어를 사용하고 텍스트를 작성할 때 다음을 고려하십시오.
  • 간단한 어휘를 사용하십시오. 간단한 작업을 수행할 때 복잡한 용어를 사용하지 마십시오.
  • 짧고 명료하게 문장을 쓰십시오.
  • very, more, rather 및 like와 같은 부사를 사용하지 마십시오.
  • 올바른 구두점을 사용하십시오.
  • 복문을 사용하지 마십시오.

자세한 정보는 가이드라인: 유스 케이스, 컨텐츠에 대한 토론 및 이벤트 플로우 양식을 참조하십시오.

이벤트 플로우 구축 페이지 맨 위

이벤트의 유스 케이스 플로우를 여러 개의 플로우로 나눌 수 있습니다. 유스 케이스가 활성화된 경우, 다음이 참이면 서브플로우를 여러 가지 방법으로 결합할 수 있습니다.

  • 제공된 액터로부터의 입력 또는 일반 속성이나 객체의 값에 따라 여러 가지 가능한 경로 중 하나로부터 유스 케이스를 진행할 수 있습니다. 예를 들어, 액터는 여러 옵션으로부터 다음에 수행할 작업을 결정할 수 있으며 값이 특정 값보다 작거나 클 경우 이벤트 플로우가 달라질 수 있습니다.
예:

현금 자동 지급기 시스템에서의 예금 인출 유스 케이스에 대한 설명의 일부는 "고객이 계좌에서 인출하고자 하는 금액을 잔액과 비교합니다. 인출 금액이 잔고보다 많으면 고객에게 알리고 유스 케이스를 종료합니다. 그렇지 않으면 계좌에서 금액을 인출합니다."일 수 있습니다.

  • 유스 케이스는 선택적 순서로 일부 서브플로우를 수행할 수 있습니다.
  • 유스 케이스는 동시에 여러 서브플로우를 수행할 수 있습니다.

이러한 모든 선택적 또는 대체 플로우를 기술해야 합니다. 각 서브플로우를 이벤트 플로우 섹션에 대한 별도의 부록으로 기술하는 것이 바람직하며 다음과 같은 케이스에는 필수입니다.

  • 제공된 이벤트 플로우 중 대량의 세그먼트를 차지하는 서브플로우.
  • 이벤트의 예외 플로우. 이는 이벤트에 대한 유스 케이스의 기본 플로우를 좀더 명확히 표현하는 데 도움이 됩니다.
  • 이벤트의 동일한 플로우에서 여러 간격으로 실행될 수 있는 모든 서브플로우.

서브플로우가 전체 이벤트 플로우 중 사소한 부분에만 관련된 경우, 텍스트의 본문에 이를 기술하는 것이 더 좋습니다.

예:

"유스 케이스는 액터인 주문자 또는 성능 관리자를 관리하는 사람 중 하나에 의해 '주문 관리' 기능이 호출되면 활성화됩니다. 신호가 이 두 액터 중 하나로부터 수신되지 않으면 유스 케이스는 작업을 종료하고 사용자에게 적절한 메시지를 표시합니다. 그러나 액터가 인식되면 유스 케이스는 ...에 따라 진행합니다. "

활동 다이어그램을 사용하여 이벤트 플로우의 구조를 표시할 수 있습니다. 가이드라인: 유스 케이스 모델 내의 활동 다이어그램을 참조하십시오.

자세한 정보는 가이드라인: 유스 케이스, 이벤트 플로우의 구조를 참조하십시오.

액터 및 기타 유스 케이스와의 관계 표시페이지 맨 위

유스 케이스 및 액터와 기타 유스 케이스에 대한 관계를 표시하는 유스 케이스 다이어그램을 작성하시시오. 이 유형의 다이어그램은 유스 케이스의 로컬 다이어그램으로 작동하며 여기에 관련되어 있어야 합니다. 유스 케이스에 설명이 필요한 유스 케이스 관계가 없거나 관련된 액터 사이에 유난히 복잡한 관계가 있으면, 이 유형의 로컬 유스 케이스 다이어그램은 가치가 거의 없습니다.

자세한 정보는 가이드라인: 유스 케이스 다이어그램을 참조하십시오.

모든 특수 요구사항 기술 페이지 맨 위

유스 케이스에 관련될 수 있으나 유스 케이스의 이벤트 플로우에서 고려하지 않아도 되는 모든 요구사항은 유스 케이스의 특수 요구사항에 기술해야 합니다. 이러한 요구사항은 작동하지 않을 가능성이 있습니다.

자세한 정보는 가이드라인: 유스 케이스, 특수 요구사항을 참조하십시오.

통신 프로토콜 정의 페이지 맨 위

다른 시스템 또는 외부 하드웨어에 있는 모든 액터에 대해 사용할 통신 프로토콜을 정의하십시오. 일부 기존 프로토콜(특히 인식된 프로토콜 또는 표준으로 간주되는 프로토콜)을 사용할 경우, 유스 케이스의 설명에서는 단순히 프로토콜 이름을 지정합니다. 프로토콜이 새 프로토콜이면 객체 모델 개발 중에 완전히 설명해야 하는 프로토콜 정의가 있는 위치를 지정해야 합니다.

전제 조건 기술 페이지 맨 위

유스 케이스에 대한 전졔 조건에서는 유스 케이스를 시작하기 위해서는 시스템이 어떤 상태에 있어야 하는지에 대해 설명합니다.

예:

ATM 시스템이 현금을 지급할 수 있으려면 다음과 같은 전제 조건을 만족해야 합니다.

  • ATM 네트워크에 액세스할 수 있어야 합니다.
  • ATM이 트랜잭션 승인 준비 상태에 있어야 합니다.
  • ATM에 최소한 지급할 수 있는 만큼의 현금이 준비되어 있어야 합니다.
  • ATM에 최소한 하나의 트랜잭션에 대한 영수증을 인쇄할 수 있는 용지가 남아 있어야 합니다.

이는 현급 지급 유스 케이스에 대해 올바른 전제 조건입니다.

시스템 상태를 기술할 때 주의를 기울이십시오. 이 유스 케이스 이전에 발생했을 수 있는 다른 우발적인 활동에 대해 자세히 기술하지 마십시오.

전제 조건은 연속된 유스 케이스를 작성하는 데 사용되지 않습니다. 이벤트 플로우에 의미를 부여하기 위해 하나의 유스 케이스를 먼저 수행한 다음 다른 유스 케이스를 수행해야 하는 케이스가 있어서는 안 됩니다. 이를 수행해야 할 필요성을 느낀다면 유스 케이스 모델을 너무 많이 분해했을 가능성이 있습니다. 순차적으로 의존하는 유스 케이스를 하나의 유스 케이스로 결합하여 이 문제점을 정정하십시오. 이렇게 함으로써 결과 유스 케이스가 너무 복잡해지면, 위의 유스 케이스에 대한 이벤트 플로우 구축 또는 활동: 유스 케이스 모델 구축에 제시된 대로 유스 케이스 구축에 필요한 기법을 고려해 보십시오.

자세한 정보는 가이드라인: 유스 케이스, 전제 조건 및 사후 조건을 참조하십시오.

사후 조건 기술 페이지 맨 위로

유스 케이스에 대한 사후 조건에는 유스 케이스 종료시 시스템이 놓일 가능성이 있는 상태가 나열됩니다. 시스템은 유스 케이스 실행 종료시 이러한 상태 중 하나에 놓여 있어야 합니다. 이는 유스 케이스에서 어떤 상황이 발생했는지에 관계없이 유스 케이스 종료시 시스템이 수행하던 조치를 설명하는 데 사용됩니다.

:

ATM이 유스 케이스 종료시 항상 '환영' 메시지를 표시할 경우, 이는 유스 케이스의 사후 조건에 문서화되어 있을 수 있습니다.

마찬가지로 현금 인출과 같은 유스 케이스를 종료할 때 ATM이 항상 고객의 트랜잭션을 종료하면, 발생한 이벤트 과정에 관계 없이 유스 케이스의 사후 조건으로서 그 사실을 기록해야 합니다.

사후 조건은 복잡도를 줄이고 유스 케이스에 대한 이벤트 플로우의 이해도를 향상시키는 데 사용됩니다.

어떠한 조건에서도 사후 조건을 연속된 유스 케이스를 작성하는 데 사용해서는 안됩니다. 이벤트 플로우에 의미를 부여하기 위해 하나의 유스 케이스를 먼저 수행한 후 다른 유스 케이스를 수행하는 하는 케이스가 있어서는 안 됩니다. 이를 수행해야 할 필요성을 느낀다면, 후속 종속 유스 케이스를 단일 유스 케이스에 결합시켜야 합니다. 이렇게 함으로써 결합된 유스 케이스가 너무 복잡해지면, 위의 유스 케이스에 대한 이벤트 플로우 구축 또는 활동: 유스 케이스 모델 구축에 제시된 대로 유스 케이스 구축에 필요한 기법을 고려해 보십시오.

자세한 정보는 가이드라인: 유스 케이스, 전제 조건 및 사후 조건을 참조하십시오.

확장 지점 기술 페이지 맨 위

다른 유스 케이스에 의해 유스 케이스가 확장될 경우(가이드라인: 확장 관계 참조) 확장 지점이 무엇인지에 대해 기술해야 합니다(가이드라인: 유스 케이스, 확장 지점 참조).

결과 평가 페이지 맨 위

스테이크홀더가 유스 케이스에 대해 명확히 이해하고 해당 설명에 동의할 수 있도록 스테이크홀더와 함께 유스 케이스를 검토하고 논의하십시오.

유스 케이스 설명은 유스 케이스가 수행하고 구현하는 모든 것을 설명하거나 시작부터 끝까지 모든 것을 허용할 경우에만 완료됩니다. 완료하기 전에 유스 케이스가 "우수한" 유스 케이스로 규정한 특성을 제시하는지 확인하십시오. 활동: 요구사항 검토의 유스 케이스 및 유스 케이스 보고서에 대한 체크포인트를 참조하십시오.



Rational Unified Process   2003.06.15