타스크: 유스 케이스 세부화
이 타스크에서는 특정 유스 케이스에 세부사항을 추가합니다.
원칙: 요구사항
목적

이 타스크의 목적은 다음과 같습니다.

  • 소프트웨어 개발을 시작할 수 있도록 하나 이상의 유스 케이스의 이벤트 플로우를 상세히 설명.
  • 액터 대표 또는 고객이 이해하고 만족할 수 있도록 유스 케이스를 세부화.
관계
단계
시나리오 검토 및 정제

현재 개발 주기에서 다루게 될 시나리오를 검토하고 정제하십시오. 이 시나리오는 타스크: 액터 및 유스 케이스 찾기에서 초기에 이미 식별되었을 수 있습니다. 열거된 이 시나리오를 시작점으로 사용하여 설명해야 할 플로우의 범위를 결정하십시오.

이벤트 플로우 세부화

타스크: 액터 및 유스 케이스 찾기 중에 유스 케이스의 이벤트 플로우를 이미 아웃라인했을 수 있습니다. 이 개요를 시작점으로 사용하여 점차 자세히 설명하십시오.

스토리보드는 유스 케이스 플로우를 이해하고 세부화하는 데 도움이 됩니다. 고려할 또 다른 입력은 사용자 인터페이스 프로토타입입니다(이미 개발된 경우).

프로젝트에 대해 결정된 표준에 따라 유스 케이스를 설명하십시오. 유스 케이스를 설명하기 전에 유스 케이스에 걸쳐 일관성이 있도록 다음 사항을 결정하십시오.

  • 유스 케이스는 어떻게 시작됩니까? 유스 케이스의 시작은 유스 케이스를 활성화하는 신호를 명확히 설명해야 합니다. 예를 들어, "...할 때 유스 케이스를 시작할 수 있습니다."라고 쓰십시오.
  • 유스 케이스는 어떻게 종료됩니까? 플로우 도중에 유스 케이스가 종료되는 상황을 명확히 설명해야 합니다. 예를 들어, "...할 때 유스 케이스가 종료됩니다."라고 쓰십시오.
  • 유스 케이스는 액터와 어떻게 상호작용합니까? 오해의 위험성을 최소화하려면 시스템 내에 상주할 내용과 시스템 밖에 상주할 내용을 정확히 제시하십시오. 일련의 단락으로(각 단락은 "액터가 ...할 때 시스템은 ...합니다."와 같은 형식으로 조치를 표현) 설명을 구조화하십시오. 유스 케이스가 액터와 신호를 송수신한다고 써서 상호작용을 강조할 수도 있습니다(예: "운영자로부터 '시작' 신호를 수신하면 유스 케이스가 시작됩니다.").
  • 유스 케이스는 액터와 어떻게 데이터를 교환합니까? 원하면 신호의 인수를 참조할 수 있지만 예를 들면 "사용자가 자신의 이름과 암호를 제공하여 시스템에 로그인할 때 유스 케이스가 시작됩니다."라고 쓰는 것이 더 좋습니다.
  • 유스 케이스는 어떻게 일부 동작을 반복합니까? 자연어로 이를 표현해야 합니다. 그러나 해당 자연어 용어를 표현하기 어려운 경우에는 예외적인 경우로 코드와 유사한 구조(예: "WHILE-END WHILE," "IF-THEN-ELSE," "LOOP-END LOOP")를 사용하는 것이 좋습니다. 그러나 일반적으로 코드와 유사한 구조는 읽고 유지보수하기 어려우므로 유스 케이스 설명에서는 이를 사용하지 않아야 합니다.
  • 유스 케이스의 이벤트 플로우에 선택적 상황이 있습니까? 액터가 여러 옵션과 함께 제공되는 경우가 있습니다. 동일한 방식으로 이를 써야 합니다. 예제:

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

    a) . . .

    b) . . .

    c) . . ." 기타

  • 고객과 사용자가 이해할 수 있도록 유스 케이스를 어떻게 설명해야 합니까? 방법론 특정 용어(예: 유스 케이스, 액터, 신호)를 사용하면 불필요하게 텍스트를 이해하기가 어려워질 수 있습니다. 텍스트를 보다 쉽게 이해할 수 있도록 조치를 열거하거나 일부 다른 전략을 채택할 수 있습니다. 어떤 전략을 사용하건 유스 케이스를 설명하는 전체 타스크 중에 명심할 수 있도록 일반 유스 케이스 모델링 가이드라인에 이를 지정해야 합니다.

시스템 내부의 특정 문제점 해결 방법이 아닌 유스 케이스에서 수행되는 내용을 설명하는 데 집중하십시오. 해당 세부사항은 라이프사이클의 나중에 고려되므로 지금은 너무 자세히 설명하지 마십시오. 나중에 안정적일 것으로 생각되는 것만 설명하십시오.

유스 케이스의 이벤트 플로우가 너무 포괄적이거나 복잡해지면, 또는 서로 별개의 파트를 갖는 것 같으면 두 개 이상의 유스 케이스로 분할하십시오.

설명 텍스트를 쓸 때 중간 산출물: 용어집을 참조하십시오. 새로운 용어는 새로운 개념에서 발전되므로 이를 용어집에 포함하십시오. 해당 프로젝트 구성원에게 알리지 않고 용어 정의를 변경하지 마십시오. 자세한 정보는 타스크: 공통 용어 캡처를 참조하십시오.

이벤트 플로우 설명의 컨텐츠

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

  • 유스 케이스 시작 방법 및 시기
예제:

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

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

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

참고: 액터와 유스 케이스 간에 교환되는 데이터에 관해 명시적이어야 합니다. 그렇지 않으면 고객과 사용자가 유스 케이스 설명을 이해할 수 없습니다.

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

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

  • 유스 케이스 종료 방법 및 시기.
예제:

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

비정상적이거나 예외적인 이벤트 플로우도 설명해야 합니다. 예외적인 플로우는 유스 케이스의 정상적 또는 기본 동작을 따르지 않는 유스 케이스의 서브플로우입니다. 그렇지만 유스 케이스의 동작을 완벽히 설명하려면 이 플로우가 필요할 수 있습니다. 예외적 플로우의 일반적인 예는 첫 번째 예제에 제공된 예입니다. 유스 케이스가 예상치 못한 일부 데이터(액터가 해당 특정 컨텍스트에서 예상한 액터가 아닌 경우)를 수신할 경우에는 종료됩니다. 액터가 잘못되었거나 조기에 종료되는 것은 일반적인 이벤트 플로우가 아닙니다.

유스 케이스를 설명할 때 기타 고려"해야할 것"과 "하지 말아야 할 것"은 다음과 같습니다.

  • 유스 케이스의 기능성이나 목적 뿐만 아니라 이벤트 플로우도 설명하십시오.
  • 병렬로 작업하는 다른 유스 케이스에서 일어나는 플로우는 제외하고 해당 유스 케이스에 속한 플로우만 설명하십시오.
  • 문제의 유스 케이스와 커뮤니케이션하지 않는 액터는 언급하지 마십시오.
  • 액터와 유스 케이스의 상호작용을 설명할 때 너무 세부화하지는 마십시오.
  • 유스 케이스에 대해 설명된 서브플로우의 순서를 정하지 않아도 되는 경우, 순서를 정해야 하는 것처럼 설명하지 마십시오.
  • 공통 용어집의 용어를 사용하고, 텍스트를 쓸 때 다음을 고려하십시오.
  • 간단한 용어를 사용하십시오. 단순한 용어를 사용해도 되는데 복잡한 용어를 사용하지 마십시오.
  • 짧고 간결한 문장을 쓰십시오.
  • 아주, 더, 오히려, 거의와 같은 부사는 사용하지 마십시오.
  • 구두점을 올바로 사용하십시오.
  • 복합 문장을 사용하지 마십시오.

자세한 정보는 이벤트 플로우의 컨텐츠 및 스타일에 관해 설명한 가이드라인: 유스 케이스를 참조하십시오.

이벤트 플로우 구조화

유스 케이스의 이벤트 플로우는 여러 개의 서브플로우로 나뉠 수 있습니다. 유스 케이스가 활성화될 때 다음 경우에 해당되면 서브플로우를 여러가지 방법으로 결합할 수 있습니다.

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

현금 자동 인출기(ATM) 시스템에서 현금 인출 유스 케이스에 대한 설명의 일부는 "클라이언트가 계좌에서 인출하려는 금액을 계좌 잔고와 비교합니다. 인출하려는 금액이 잔고를 초과할 경우, 클라이언트에게 이를 알리고 유스 케이스가 종료됩니다. 그렇지 않으면 계좌에서 돈이 인출됩니다."와 같을 수 있습니다.

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

이런 선택적 또는 대체 플로우를 모두 설명해야 합니다. 각 서브플로우를 별도의 보충으로 설명하는 것이 좋으며, 다음 경우에는 필수로 해야 합니다.

  • 주어진 이벤트 플로우의 대형 세그먼트를 차지하는 서브플로우
  • 예외적인 이벤트 플로우. 이렇게 하면 유스 케이스의 기본 이벤트 플로우를 보다 명확하게 이해할 수 있습니다.
  • 동일한 이벤트 플로우에서 여러 간격으로 실행할 수 있는 서브플로우.

서브플로우가 전체 이벤트 플로우의 작은 파트만 포함하는 경우, 텍스트 본문에서 이를 설명하는 것이 더 좋습니다.

예제:

"이 유스 케이스는 액터인 주문자 또는 성능 관리자가 '주문 관리' 기능을 호출할 때 활성화됩니다. 이 액터 중 하나에서 신호가 수신되면 유스 케이스는 오퍼레이션을 종료하고 사용자에게 해당 메시지를 표시합니다. 그러나 액터를 인식하는 경우 유스 케이스는 .....에 의해 진행합니다."

타스크 다이어그램으로 이벤트 플로우의 구조를 설명할 수 있습니다. 가이드라인: 유스 케이스 모델의 활동 다이어그램을 참조하십시오.  

자세한 정보는 가이드라인: 유스 케이스에서 구조에 관한 섹션을 참조하십시오.

액터 및 기타 유스 케이스와의 관계 설명

유스 케이스 및 유스 케이스와 액터 및 기타 유스 케이스와의 관계를 표시하는 유스 케이스 다이어그램을 작성하십시오. 이 유형의 다이어그램은 유스 케이스의 로컬 다이어그램의 기능을 하며, 해당 유스 케이스와 관련되어야 합니다. 이런 종류의 로컬 유스 케이스 다이어그램은 유스 케이스에 설명해야 하는 유스 케이스 관계가 있거나 관련된 액터 간에 보기 드문 복잡도가 있는 경우를 제외하고 일반적으로 가치가 없습니다.

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

특별 요구사항 설명

유스 케이스와 관련될 수는 있지만 유스 케이스의 이벤트 플로우에서는 고려되지 않는 요구사항을 유스 케이스의 특별 요구사항에서 설명해야 합니다. 이러한 요구사항은 비기능적일 수 있습니다.

자세한 정보는 가이드라인: 유스 케이스에서 특별 요구사항에 관한 섹션을 참조하십시오.

통신 프로토콜 정의

다른 시스템 또는 외부 하드웨어인 임의의 액터에 사용될 통신 프로토콜을 정의하십시오. 기존의 일부 프로토콜(특히 인정된 프로토콜이나 표준으로 간주되는 프로토콜)을 사용할 경우, 유스 케이스에 대한 설명에서는 프로토콜 이름만 언급해야 합니다. 새로운 프로토콜인 경우, 프로토콜 정의(오브젝트 모델 개발 중에 충분히 설명되어야 함)를 찾을 수 있는 위치를 가리켜야 합니다.

전제 조건 설명

유스 케이스에 대한 전제 조건은 유스 케이스를 시작할 수 있도록 시스템이 갖추어야 하는 상태를 설명합니다.

예제:

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

  • ATM 네트워크에 액세스할 수 있어야 합니다.
  • ATM이 즉시 트랜잭션을 허용할 수 있는 상태에 있어야 합니다.
  • ATM에 지급할 수 있는 최소 얼마간의 현금이 있어야 합니다.
  • ATM에 최소 하나의 트랜잭션에 대한 영수증을 인쇄할 수 있는 용지가 있어야 합니다.

이는 모두 현금 지급 유스 케이스의 올바른 전제 조건입니다.

시스템 상태를 주의깊게 설명하십시오. 이 유스 케이스 이전에 발생했을 수 있는 기타 중요하지 않은 타스크의 세부사항은 설명하지 않도록 하십시오.

전제 조건은 유스 케이스의 시퀀스를 작성하는 데 사용되지 않습니다. 의미 있는 이벤트 플로우를 갖기 위해 먼저 하나의 유스 케이스를 수행한 후 다른 유스 케이스를 수행해야 하는 경우는 없습니다. 이를 수행해야 할 필요를 느낄 경우, 유스 케이스 모델을 너무 많이 분해했을 가능성이 있습니다. 종속 유스 케이스를 단일 유스 케이스로 순차적으로 결합하여 이 문제점을 정정하십시오. 이로 인해 유스 케이스가 너무 복잡해지면 앞서 유스 케이스의 이벤트 플로우 구조화 단계 또는 타스크: 유스 케이스 모델 구조화에서 설명한 바와 같이 유스 케이스를 구조화하기 위한 기법을 고려하십시오.

자세한 정보는 가이드라인: 유스 케이스의 전제 조건 섹션을 참조하십시오.

사후 조건 설명

유스 케이스에 대한 사후 조건은 유스 케이스 종료 시 가능한 시스템 상태를 나열합니다. 시스템은 유스 케이스 실행 종료 시 해당 상태 중 하나를 유지해야 합니다. 사후 조건은 유스 케이스에 어떤 일이 일어났는지에 관계없이 유스 케이스 종료 시 시스템이 수행하는 조치를 설명하는 데도 사용됩니다.

예제:

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

마찬가지로, 현금 인출과 같은 유스 케이스 종료 시 ATM이 항상 고객의 트랜잭션을 종료하는 경우 취해진 이벤트 과정에 관계없이 해당 사실을 유스 케이스의 사후 조건으로 기록해야 합니다.

사후 조건은 복잡도를 줄이고 유스 케이스의 이벤트 플로우를 읽기 쉽게 해줍니다.

어떤 상황에서도 유스 케이스의 시퀀스를 작성하는 데 사후 조건을 사용해서는 안됩니다. 의미 있는 이벤트 플로우를 갖기 위해 먼저 하나의 유스 케이스를 수행한 후 다른 유스 케이스를 수행해야 하는 경우는 없습니다. 이를 수행해야 할 필요를 느낄 경우, 종속 유스 케이스를 단일 유스 케이스로 순차적으로 결합해야 합니다. 이로 인해 유스 케이스가 너무 복잡해지면 앞서 유스 케이스의 이벤트 플로우 구조화 또는 타스크: 유스 케이스 모델 구조화에서 설명한 바와 같이 유스 케이스를 구조화하기 위한 기법을 고려하십시오.

자세한 정보는 가이드라인: 유스 케이스의 사후 조건 섹션을 참조하십시오.

확장점 설명

다른 유스 케이스로 유스 케이스를 확장할 경우(가이드라인: 확장 관계 참조), 확장점이 무엇인지 설명해야 합니다(가이드라인: 유스 케이스의 확장점 섹션 참조).

결과 평가

이해 당사자(stakeholder)와 함께 유스 케이스를 검토하고 논의하여 이해 당사자가 유스 케이스를 명확이 이해하고 설명에 합의하도록 하십시오.

유스 케이스 설명은 유스 케이스가 처음부터 끝까지 수행, 구현 또는 허용하는 모든 사항을 설명해야만 완전하게 됩니다. 마치기 전에, 유스 케이스가 "우수한" 유스 케이스로 간주되는 특성을 보이는지 확인하십시오. 자세한 정보는 체크리스트:유스 케이스를 참조하십시오.

핵심 고려사항
유스 케이스를 세부화할 때(특히 유스 케이스 검토를 지원하기 위해) 유스 케이스 명세를 생성할 수 있습니다. 자세한 정보는 보고서, 템플리트 및 예제와 중간 산출물: 유스 케이스에 관련된 보고서 생성에 관한 도구 사용 도움말을 참조하십시오.
자세한 정보