가이드라인: 유스 케이스 워크샵
이 가이드라인은 유스 케이스 워크샵을 준비하고 실행하는 방법을 설명합니다.
관계
기본 설명

워크샵 조직

유스 케이스 워크샵은 조직된 브레인스토밍 회의입니다. 다음과 같이 광범위한 정보를 제공해야 합니다.

  • 고객 요구사항
  • 시스템 디자인
  • 유닛 디자인
  • Rational Unified Process
  • 테스트

따라서 이 그룹에는 다양한 배경, 지식 및 경험을 가진 사람들이 포함됩니다. 그룹은 소규모(열 명 미만)로 유지하십시오. 일반 설정은 그룹의 반은 개발 팀에서, 나머지 반은 사용자 대표단에서 컴파일합니다. 그 중간에는 진행자(facilitator)가 있습니다. 진행자는 중재자 즉, 모든 발안과 요청에 대해 촉매 역할을 합니다.

도구

필요한 도구는 다음과 같습니다.

  • 두 개의 대형 화이트보드(하나로도 충분하지만 두 개면 더 좋음)
  • 이젤 차트
  • 테이프
  • 두 가지 색상의 접착식 메모지
  • 화이트보드 펜(다양한 색상)
  • 연필
  • 되도록이면 "작전실" 안에서 사용하고 나서 2-3주 동안 방해받지 않은 채로 둘 수 있는 용지를 붙여 둘 벽.

액터 정의

시스템을 사용할 사람 또는 대상을 식별해 보십시오. 처음에는 시스템을 사용할 실제 사람부터 시작하십시오. 보통 구체 대 추상에 초점을 맞추면 좋습니다. 사용자가 식별되면 시스템과 상호작용하는 동안 사용자가 맡은 역할을 식별해 보십시오. 이는 보통 액터의 이름으로 적합합니다.

액터를 식별할 때 반드시 각 액터에 대한 간단한 설명을 작성하십시오. 시스템에 대하여 액터가 맡은 역할과 액터의 책임을 몇 가지 캡처해 두면 나중에 액터가 시스템에서 필요로 하는 내용을 판별할 때 도움이 됩니다.

액터를 정의할 때 디자인 중인 시스템과 상호작용하는 상대 시스템에 대해 잊어서는 안됩니다. 액터라는 개념은 '개인'을 나타내는 것 같지만 시스템도 포함됩니다. 먼저 '휴먼' 액터를 찾는 데 초점을 맞추십시오. 보통 우선 잘 아는 대상에 초점을 맞춘 다음 점점 더 어려한 대상을 고려하는 것이 좋습니다.

유스 케이스 모델의 구조나 액터 간에 관계에 대해서는 신경쓰지 마십시오. 단순히 시스템을 사용할 사람이나 대상을 캡처하십시오. 식별에 초점을 맞추고 많은 액터를 찾을 준비를 하십시오. 지금 목록을 필터링하려고 하지 마십시오. 유스 케이스의 식별(아래 참조)로 이를 처리할 수 있습니다.

관리 시스템

이 시스템을 사용할 조직의 역할을 무엇인지 질문하십시오. 제안되는 각 역할에 대해 막대인간을 그리고 막대인간 아래에 이름을 적으십시오. 그런 다음, 화이트보드에 이미 그린 구름 모양 또는 아이콘의 양 쪽에 하나씩 두 열의 액터 목록을 작성하십시오. 때로는 액터 대신에 역할이나 사용자라는 단어를 사용하면 도움이 될 수 있습니다.

질문:

  • 이 시스템 사용자는 누구입니까?
  • 이 시스템이 정보를 전송할 기타 시스템은 무엇입니까?
  • 정보를 수신할 기타 시스템은 무엇입니까?
  • 누가 시스템을 시작합니까?
  • 누가 사용자 정보를 유지보수합니까?

함께 표시된 텍스트에서 설명되는 다이어그램

인스턴스 또는 클래스?

"Tom이 액터가 아닌 이유는 무엇인가요? 이 작업은 항상 Tom이 수행하는데요."와 같은 질문을 받을 수 있습니다. 이 경우, 추가 질문을 통해 Tom의 역할에 무엇인지에 대한 정보를 얻어야 합니다. 액터의 이름은 역할을 반영해야 합니다.

  • Tom의 역할은 무엇입니까?
  • 그 밖에 또 누가 해당 역할을 수행할 수 있습니까?
  • Tom이 해당 역할을 수행하는 이유는 무엇입니까?

많은 액터는 조직의 일반적 지위를 통해 직접 식별될 수 있습니다. 조직에서 하나의 지위는 시스템에서 두 개 이상의 역할에 해당할 수 있습니다. 예를 들어, Tom은 새 제품을 위한 공간을 만드는 창고 정리 책임자이자 일반 창고 작업자일 수 있습니다. 이 두 가지 책임은 시스템에서 서로 다른 두 액터가 될 수 있습니다.

극단적으로 일반화하기를 원하는 사람들도 있습니다. 사용자만이 유일하게 필요한 액터라고 제안할 수도 있습니다. 맞는 말이지만 흔한 이론이며 시스템 정보 이해에 도움이 되지 않습니다. 이 제안에 대해서는 논의하지 마십시오. 보드에 사용자 액터를 적은 다음, 다음 액터로 진행하십시오.

관련 기술과 지식

  • 모든 사람에게 빠진 내용이 있는지 물어보십시오.
  • 자진하여 잘못된 제안을 제공하십시오. 이를 통해 팀에서 여러분의 잘못을 정정하고 시스템의 정확한 역할을 설명할 수 있습니다.
  • 항상 모든 제안을 허용하십시오. 나중에 언제든지 중복 및 불필요한 내용을 제거할 수 있습니다. 누군가의 제안을 비판하는 것은 회의에 찬물을 끼얹는 것입니다.

액터를 정의하는 데는 보통 1 - 4시간이 걸립니다. 화이트보드에 많은 액터 목록이 작성되지만 유스 케이스를 추가할 공간을 남겨둬야 합니다. 액터 세트가 완료된 듯 하면 이제 유스 케이스를 시작해야 합니다.

함께 표시된 텍스트에서 설명되는 다이어그램

유스 케이스 정의

화이트보드에서 구름 모양이나 아이콘을 지우고 유스 케이스를 식별하기 시작하십시오. 구체적 유스 케이스에 초점을 맞추고 포함확장 관계에 대해서는 논의하지 마십시오. 타원을 그리고 모든 제안에 대해 이름을 쓰십시오. 액터 쪽으로 화살표를 그리십시오.

응용프로그램에 아는 정보가 없다는 사실을 강점으로 사용하십시오. 워크샵의 참가자가 여러분에게 시스템이 수행해야 하는 작업을 알려줘야 합니다. 시스템에 대해 많은 질문을 하십시오. 참가자가 설명을 제공하면 유스 케이스를 알게 됩니다.

유스 케이스의 개념을 바로 이해할 수 있는 사람들도 있고 그렇지 않은 사람들도 있습니다. 개념을 좀 더 알기 쉬운 관점으로 표현하려면, 시스템 보기를 그릴 사람이 필요합니다. 시스템 보기는 시스템의 추상입니다. 예를 들면, 데이터베이스 및 다수의 클라이언트를 포함하는 서버이거나 특수 타스크가 표시된 다수의 회로 기판일 수 있습니다. 이 보기는 보통 그리기 쉽습니다. 일반적으로 참가자 중 한 명이 화이트보드 펜을 가지고 시스템 작동 방법을 표시합니다. 시스템 보기는 한 시스템 경계에서 다른 시스템 경계까지 유스 케이스를 확장할 때 도움이 되며, 내재적으로 많은 다른 시스템 상태를 가리킵니다. 이 상태에 대해 질문하면 더 많은 유스 케이스를 알게 됩니다. 다른 커뮤니케이션이 없을 경우 어떤 일이 발생하는지 확인하십시오. 이를 통해 유스 케이스의 대체 플로우를 식별할 수 있습니다.

기술 시스템에 대해 작업 중인 경우, 대개 모든 사람이 시스템 보기를 잘 알고 있으므로 액터를 찾기 위한 최선의 방법이 됩니다. 이 경우, 액터 요청을 시작하기 전에 시스템 보기를 그리도록 할 수 있습니다.

관리 시스템에 대해 작업 중인 경우, 모든 사람이 시스템 보기를 잘 알지는 못할 수 있습니다. 이 경우에는 수동 루틴을 설명하는 그래프가 더 효과적일 수 있습니다. 그래프는 하나의 비즈니스 엔티티가 한 사람에서 다른 사람으로 이동되는 방식과 해당 비즈니스 엔티티로 수행해야 하는 작업에 대해 설명할 수 있습니다. 주문 및 전달 프로세스를 시각화하기 위해 그래프는 고객 사무실, 당사 사무실, 창고 및 고객 창고의 개략적 보기를 표시할 수 있습니다.

모든 사람에게 유스 케이스 모델 및 시스템 보기/비즈니스 엔티티 보기가 잘 보이도록 하십시오. 두 개의 화이트보드를 사용하면 좋습니다.

유스 케이스에 대해 긴 이름을 허용하십시오. 최근에 식별된 유스 케이스는 한 문장 정도의 길이에 해당하는 이름을 가질 수 있습니다. 이 이름은 유스 케이스에 대한 간략한 설명에서 시작하는 것이 바람직하며, 나중에 이름을 줄일 수 있습니다.

언제나 많은 유스 케이스에 공통 부분이 포함됩니다. 모든 사람에게 현재로서는 이 상태가 허용 가능하다는 이해를 구하십시오. 유스 케이스의 컨텐츠에 대한 정보가 충분하지 않으므로 아직 구조화할 필요가 없습니다. 유스 케이스 관계에 대한 논의는 이벤트 플로우의 아웃라인이 제공된 후로 미루십시오.

보드의 유스 케이스가 전체 시스템의 기능성을 포함한다고 그룹에서 동의하면 점심 식사 시간을 가지십시오.

점심 식사 후 오전 세션에서 얻은 결과를 검토하십시오.

  • 액터를 살펴 보십시오. 이 시스템에서 해당 액터의 타스크는 무엇입니가? 유스 케이스 모델링 기법에 익숙하지 않은 사람들에게는 타스크라는 단어가 유스 케이스보다 더 나을 수 있습니다.
  • 제안된 각 유스 케이스를 살펴 보십시오. 유스 케이스가 사용자에게 제공하는 가치를 이해하고 있습니까? 유스 케이스가 좋은 결과를 가져오는 경우, 사용자는 보다 더 적극적으로 해당 유스 케이스를 수행하려고 할 것입니다.
  • 제안된 각 유스 케이스를 살펴 보십시오. 유스 케이스가 완료되었습니까? 아니면 더 큰 무엇의 작은 부분에 불과합니까?

질문:

  • 모든 액터는 최소 하나의 유스 케이스를 가지고 있어야 합니다. 그렇지 않은 경우, 이는 액터가 중복(또 다른 액터가 같은 역할을 함)되거나 시스템의 직접 사용자가 아니기 때문일 수 있습니다. 이 경우 액터 보존 시 장점이 많지 않으면 액터를 제거할 수 있습니다.

각 유스 케이스에 대해 간략한 설명 작성

유스 케이스에 대한 작업을 하나씩 수행하면서 각 유스 케이스에 대해 하나의 이젤 차트를 작성하십시오. 타원을 그리고 차트의 맨 위에 유스 케이스의 이름을 적으십시오. 연필을 잡고 그룹에게 유스 케이스의 간략한 설명을 쓰기 위한 도움을 요청하십시오. 간략한 설명은 약 1 - 3개의 문장이어야 합니다. 때로는 액터를 유스 케이스에 연결하여 그리는 것이 좋을 수도 있습니다. 다음 단계를 위해 용지의 절반 정도를 비워 두십시오.

함께 표시된 텍스트에서 설명되는 다이어그램

이 작업을 통해 전에는 모두 확실하다고 여겼던 내용이 실제로는 전혀 그렇지 않음을 알게 됩니다. 비전에서  주요 사용자 요구 및 기능으로 식별된 요구사항을 참조하고 이 유스 케이스에 대한 요구사항이 있는지 찾아보십시오.

새 유스 케이스가 나타나기도 하고 유스 케이스가 사라지기도 합니다. 유스 케이스 용지를 벽에 붙이십시오. 기능 영역마다 하나의 열을 사용하여 이를 조직하십시오. (여기에는 화이트보드를 사용하지 마십시오. 화이트보드는 시스템 보기, 액터 및 유스 케이스에 필요합니다.) 질문을 바로 해결할 수 없는 경우, 접착식 메모지에 질문을 기록하여 적절한 유스 케이스에 붙이십시오. 질문에는 한 가지 색을 사용하십시오.

모든 유스 케이스가 이젤 차트 및 간략한 설명을 포함하면 다음 단계로 진행하십시오. 이 모든 유스 케이스가 실제로 필요한지 논의하는 데 어느 정도 시간을 투자하는 것이 좋습니다.

지금까지 작성한 모델은 Rational Rose 또는 Rational RequisitePro에 문서화할 수 있고 유스 케이스 모델 조사 보고서로 생성할 수 있습니다.

각 유스 케이스에 대한 이벤트 플로우의 단계별 설명

유스 케이스 작성은 우선 텍스트를 구조화하는 것부터 시작됩니다. 이해 당사자로부터 미리 정보를 얻지 않고 혼자 앉아서 텍스트 구조화를 시도하는 것은 무의미합니다.

유스 케이스에 대한 작업을 하나씩 수행하십시오. 다양한 조치를 순서대로 기록하십시오. 코드 구조, 루프, for-while 문에서 상태가 어떻게 보일 것인지 등은 신경쓰지 마십시오. 단지 기본 이벤트 플로우에 대해서만 작업하고 대안에 대해서는 신경쓰지 마십시오. 1, 2, 3, 4단계를 하나하나 열거하십시오. 그룹의 필요한 세부사항 레벨 이해를 돕기 위해 기본 플로우에 5 - 10단계가 필요할 수도 있습니다.

기본 이벤트 플로우의 해당 단계에 합의한 다음, 이를 둘러보고 대체 단계를 식별하십시오. 대체 플로우 A1, A2, A3, A4를 열거하십시오.

함께 표시된 텍스트에서 설명되는 다이어그램

이 논의 중에 많은 문제가 제기될 수 있으며 그 중 다수가 분석 및 디자인 시까지 해결되지 않을 수 있습니다. 모든 문제를 진행을 위해 필요한 가정사항과 함께 기록해야 합니다. 문제 중 일부는 요구사항 지정자가 이벤트 플로우를 세부화할 수 있도록 빨리 해결해야 하고, 일부는 분석 및 디자인을 시작하기 전에 해결해야 합니다.

이제 각 이젤 차트에 포함된 내용은 요구사항 지정자가 유스 케이스의 이벤트 플로우를 세부화하기에 충분합니다.

보충 스펙 캡처

이 세션 중에 유스 케이스에서 쉽게 캡처할 수 없는 시스템 관련 요구사항이 몇 가지 있습니다. 일반적으로 이 구문은 시스템의 일반 기능성, 사용성, 신뢰성, 성능 및 지원 가능성과 관계가 있습니다. 별도의 이젤 차트에 이 구문을 적어 보관하십시오. 이 차트는 보충 스펙에 대한 기초를 제공합니다.

유스 케이스에 대한 요구사항 추적

핵심 이해 당사자(stakeholder) 요청비전 문서의 각 기능을 둘러보고 유스 케이스 모델이 적절한 방법으로 이를 포함하는지 확인하십시오. 어떤 사용자 요구 및 요구사항이 어떤 유스 케이스에 대해  추적되는지 논의하십시오.

함께 표시된 텍스트에서 설명되는 다이어그램

비전 문서를 받아 첫 번째  기능을 읽으십시오. 하나(또는 필요한 경우 둘 이상)의 접착식 메모지에 ID를 적으십시오(요구사항과 문제를 쉽게 구별하기 위해 두 번째 색상 사용). 이 요구사항을 이행하는 유스 케이스에 이 메모지를 붙이십시오. 나중에 RequisitePro 저장소에 이  추적성을 입력할 수 있습니다.

언제나 어떤 유스 케이스에도 연결할 수 없는 요구사항이 많이 있습니다.

  • 이는 디자인을 연기해야 하는 특정 요구사항일 수 있습니다. 이 요구사항을 하나의 용지에 적으십시오(디자인 요구사항).
  • 어떤 유스 케이스에도 연결될 수 없는 일반 요구사항이 있을 수 있습니다. 이 요구사항을 보충 스펙 목록에 적으십시오.
  • 미처 생각을 못해서 새 유스 케이스를 작성하거나 기존 유스 케이스를 변경해야 하는 요구사항이 있을 수 있습니다.

잠깐 시간을 내서 구조를 검토하십시오. 요구사항이 없는 유스 케이스가 있습니까? 이유는 무엇입니까? 이 유스 케이스는 필요하지 않습니까? 또는 요구사항 스펙을 작성한 사람이 이 기능성을 미처 생각하지 못했습니까? (이런 경우가 일반적입니다.) 이 상황을 해결해야 합니다. 고객이 이 기능의 필요성을 알고 있습니까? 고객이 해당 기능을 구매할 용의가 있습니까?