타스크: 액터 및 유스 케이스 찾기
이 타스크는 구현될 요구사항을 지원하기 위해 액터와 유스 케이스 가 식별되는 타스크입니다. 액터와 유스 케이스를 식별하면 시스템의 범위가 명시적으로 정의됩니다.
목적

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

  • 시스템의 범위, 즉 시스템이 처리할 내용과 시스템 외부에서 처리될 내용을 정의합니다.
  • 시스템과 상호작용하는 사람과 대상을 정의합니다.
  • 시스템 기능을 요약합니다.
관계
기본 설명

액터와 유스 케이스를 찾기 위해 사용할 수 있는 매우 성공적인 기법은 유스 케이스 워크샵을 여는 것입니다.

단계
액터 찾기

액터 찾기는 시스템 사용 정의의 첫 번째 단계 중 하나입니다. 시스템이 상호작용해야 하는 외부 현상의 각 유형이 하나의 액터로 표현됩니다. 액터를 찾으려면 다음 질문을 생각하십시오.

  • 어떤 사용자 그룹이 해당 타스크를 수행하기 위해 시스템의 도움을 필요로 합니까?
  • 어떤 사용자 그룹이 시스템의 가장 명백한 기본 기능을 실행하는 데 필요합니까?
  • 어떤 사용자 그룹이 시스템 유지보수 및 관리 같은 2차적인 기능을 수행하는 데 필요합니까?
  • 시스템이 외부 하드웨어 또는 소프트웨어 시스템과 상호작용합니까?

이러한 카테고리 중 하나에 맞는 모든 개인, 그룹 또는 현상이 액터의 후보입니다.

올바른(휴먼) 액터가 있는지 판별하기 위해 액터로서 수행할 수 있는 2 - 3명의 이름을 지정한 후 액터 세트가 해당 사용자의 요구에 충분한지 확인할 수 있습니다. 액터를 구성하는 내용에 대한 자세한 정보는 가이드라인: 액터를 참조하십시오.

처음에는 가장 적합한 액터를 찾기가 어려울 수 있으며, 모든 유스 케이스를 찾지 않았기 때문에 모든 액터를 즉시 찾을 가능성이 거의 없습니다. 유스 케이스에 대한 작업이 시스템의 환경 및 환경이 시스템과 상호작용하는 방법을 보다 깊이 이해할 수 있게 하는 유일한 작업입니다. 거기까지 진행했을 때, 처음에는 너무 많은 액터를 모델링하는 경향이 있으므로 원래 모델을 개정하기 원할 수 있습니다. 액터를 변경할 때 주의하십시오. 도입되는 변경사항이 유스 케이스에도 영향을 미칠 수 있습니다. 액터에 대한 모든 수정이 시스템의 인터페이스 및 동작에서 주요 변경사항을 구성함을 기억하십시오. 비즈니스 유스 케이스 모델과 비즈니스 분석 모델을 개발한 경우 이들을 기본 액터 식별을 위한 소스로 사용할 수 있습니다.

찾은 액터를 이름 지정 및 간략하게 설명

액터의 이름은 액터의 역할을 명확하게 표시해야 합니다. 차후 단계에서 한 액터의 이름을 다른 액터의 이름과 혼동할 위험성이 없도록 하십시오.

액터의 책임 영역 및 액터가 시스템을 필요로 하는 사항을 포함하는 간략한 설명을 작성하여 각 액터를 정의하십시오. 액터가 시스템 외부의 것을 표시하기 때문에 자세히 설명할 필요가 없습니다. 또한 가이드라인: 액터의 간략한 설명 섹션을 참조하십시오.

유스 케이스 찾기

액터의 최초 개요가 완료될 때 다음 단계는 시스템의 유스 케이스를 찾는 것입니다. 첫 번째 유스 케이스는 매우 초보적이며 안정될 때까지 몇 번 변경해야 합니다. 시스템의 비전 또는 요구사항이 부족한 경우 또는 시스템 분석이 모호한 경우 시스템의 기능은 명백하지 않습니다. 따라서 항상 올바른 유스 케이스를 찾았는지 스스로에게 물어야 합니다. 게다가 최종 버전에 도달하기 전에 유스 케이스를 추가, 제거, 결합 및 분할할 준비가 되어야 합니다. 유스 케이스를 자세하게 설명하고 나면 유스 케이스를 보다 잘 이해하게 됩니다.

유스 케이스를 찾는 최상의 방법은 각 액터가 시스템에서 요구하는 사항을 고려하는 것입니다. 시스템은 해당 사용자만을 위해 존재하며 따라서 사용자의 요구를 기반으로 해야 함을 기억하십시오. 시스템에 있는 기능 요구사항을 통해 액터의 많은 요구를 인식하게 됩니다. 각 액터에 대해(사람인지 여부와 상관없음) 다음을 스스로에게 질문하십시오.

  • 액터가 시스템이 수행하기 원하는 기본 타스크는 무엇입니까?
  • 액터가 시스템에 데이터를 작성, 저장, 변경, 제거 또는 읽습니까?
  • 액터는 갑작스런 외부 변경에 대한 정보를 시스템에 제공해야 합니까?
  • 액터는 시스템에서 발생한 특정 사항에 대해 알고 있어야 합니까?
  • 액터가 시스템 시작 또는 시스템 종료를 수행합니까?

이러한 질문에 대한 대답이 후보 유스 케이스를 식별하는 이벤트 플로우를 표시합니다. 모두가 개별 유스 케이스를 구성하지는 않습니다. 일부는 동일한 유스 케이스의 변형으로 모델링될 수 있습니다. 어느 것이 변형이고 어느 것이 별도의 고유한 유스 케이스인지 말하는 것이 항상 쉽지는 않습니다. 그러나 이벤트 플로우를 자세하게 설명할 때 더 명확해집니다.

요구사항 외에, 조직의 엔터프라이즈 모델(비즈니스 모델이라고도 부름)이 유스 케이스 판별을 위한 유용한 입력 소스입니다. 엔터프라이즈 모델은 정보 시스템이 기존 오퍼레이션에 통합될 수 있는 방법을 설명하며 따라서 시스템의 주변 환경을 이해할 수 있게 합니다. 또한 엔터프라이즈 모델이 엔터프라이즈의 "비즈니스 오브젝트"를 포함하기 때문에 엔터프라이즈 모델에서 정의되어야 하는 개념을 찾습니다. 비즈니스 모델링 워크플로우를 따른 경우 입력으로 사용할 비즈니스 유스 케이스 모델과 비즈니스 분석 모델이 있습니다.

한 시스템이 여러 개의 가능한 유스 케이스 모델을 가질 수 있습니다. "최적" 모델을 찾는 가장 좋은 방법은 2 - 3개의 모델을 개발하고 선호하는 모델을 선택한 후 더욱 개발하는 것입니다. 여러 개의 대안 모델을 개발하는 것도 시스템을 보다 잘 이해하는 데 도움이 됩니다.

첫 번째 유스 케이스 모델을 요약했을 때 유스 케이스 모델이 모든 기능적 요구사항을 다루는지 확인해야 합니다. 요구사항을 철저하게 조사하여 모든 유스 케이스가 모든 요구사항을 충족시키도록 하십시오.

유스 케이스의 개념 및 유스 케이스를 찾는 방법에 대한 자세한 정보는 가이드라인: 유스 케이스 모델가이드라인: 유스 케이스를 참조하십시오.

찾은 유스 케이스를 이름 지정 및 간략하게 설명

각 유스 케이스는 액터와의 상호작용에 의해 달성되는 사항을 표시하는 이름이 있어야 합니다. 이름은 이해할 수 있는 몇몇 단어일 수 있습니다. 두 개의 유스 케이스가 같은 이름을 가질 수 없습니다. 가이드라인: 유스 케이스의 이름 섹션도 참조하십시오.

간략한 설명을 작성하여 각 유스 케이스를 정의하십시오. 설명을 작성할 때 용어집을 참조하고 필요한 경우 새 개념을 정의하십시오. 또한 가이드라인: 유스 케이스의 간략한 설명 섹션을 참조하십시오.

이벤트 플로우 아웃라인

이 시점에서 유스 케이스 이벤트 플로우의 초안도 작성해야 합니다. 각 유스 케이스의 이벤트 플로우를 성능의 짧은 순간으로 설명하되, 자세히 하지는 마십시오. 나중에 유스 케이스를 정의하는 사람(본인인 경우에도)이 이 단계별 설명을 필요로 합니다. 기본 이벤트 플로우를 요약하여 시작하고, 해당 내용이 합의되면 대체 플로우를 추가하십시오.

예제:

재활용품 수집기 시스템에서 항목 재활용 유스 케이스의 이벤트 플로우의 초기 단계별 설명은 다음과 같습니다.

  • 고객이 "시작" 단추를 누릅니다.
  • 고객이 폐품을 넣습니다.
  • 시스템이 삽입된 폐품의 유형을 확인합니다.
  • 시스템이 수령한 항목 유형의 일일 총계를 증가시킵니다.
  • 고객이 "영수증" 단추를 누릅니다.
  • 시스템이 영수증을 인쇄합니다.
추가 요구사항 수집

일부 시스템 요구사항은 특정 유스 케이스에 할당할 수 없습니다. 이들을 보충 스펙에서 수집하십시오(중간 산출물: 보충 스펙 참조).

액터와 유스 케이스의 상호작용 방법 설명

액터가 유스 케이스와 관련되는 방법을 보이는 것이 중요하기 때문에 유스 케이스를 찾을 때 그와 상호작용할 액터를 설정해야 합니다. 이를 수행하려면 액터와 유스 케이스 사이의 신호 전송과 동일한 방향으로 탐색할 수 있는 커뮤니케이션 연관 관계를 정의해야 합니다.

신호 전송은 대개 양방향으로 진행합니다. 이 경우에 해당하면 커뮤니케이션 연관 관계가 양방향으로 탐색 가능하게 해야 합니다. 각 액터-유스 케이스 쌍에 대해 많아야 하나의 커뮤니케이션 연관 관계를 정의하십시오.

또한 정의하는 각 커뮤니케이션 연관 관계를 간략하게 설명해야 합니다.

커뮤니케이션 연관 관계에 대한 자세한 정보는 중간 산출물 가이드라인: 커뮤니케이션 연관 관계를 참조하십시오.

유스 케이스 및 액터 패키징

액터 또는 유스 케이스의 수가 너무 커지면 이들을 유스 케이스 패키지로 구분하여 유스 케이스 모델의 유지보수를 단순하게 하십시오. 그러면 유스 케이스 모델을 다루기가 더 쉬워지고, 개발자가 유스 케이스 또는 액터의 패키지에 대한 책임을 갖게 하여 유스 케이스 모델에서 책임의 지정이 단순하게 됩니다.

유스 케이스를 함께 패키징하는 또 다른 방법은 유스 케이스가 다음에 해당하는 경우입니다.

  • 동일한 액터와 상호작용합니다.
  • 서로 포함 또는 확장 관계를 갖습니다.
  • 모두가 선택적이고, 시스템에 의해 함께 제공되거나 전혀 제공되지 않습니다.

다른 방법도 있습니다. 그러나 모델을 직관적으로 이해할 수 있도록 유지하기 위해서는 패키징을 수행할 때 명확한 전략을 사용해야 합니다.

유스 케이스 패키지에 대한 자세한 정보는 중간 산출물 가이드라인: 유스 케이스 패키지를 참조하십시오.

유스 케이스 모델을 다이어그램으로 제시

관련된 유스 케이스뿐 아니라 유스 케이스와 액터 사이의 관계를 유스 케이스 모델의 다이어그램으로 표현할 수 있습니다. 이들 다이어그램은 다음을 포함할 수 있습니다.

  • 같은 유스 케이스 패키지에 속하는 액터.
  • 액터와 액터가 상호작용하는 모든 유스 케이스.
  • 같은 정보를 처리하는 유스 케이스.
  • 같은 액터 그룹에 의해 사용되는 유스 케이스.
  • 흔히 하나의 시퀀스로 실행되는 유스 케이스.
  • 같은 유스 케이스 패키지에 속하는 유스 케이스.
  • 가장 중요한 유스 케이스. 이 유형의 다이어그램은 모델의 요약으로 기능할 수 있고 유스 케이스 보기에 포함되어 있을 가능성이 있습니다.
  • 함께 개발된 유스 케이스(동일 증분 범위 내).

각 다이어그램은 유스 케이스 모델의 적합한 패키지가 소유해야 합니다.

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

유스 케이스 모델 조사 개발

이 단계에서는 유스 케이스 모델의 조사 설명을 개발합니다. 조사에 반드시 다음 사항을 포함시켜야 합니다.

  • 사용자가 유스 케이스를 채택하는 전형적인 시퀀스.
  • 유스 케이스 모델에 의해 처리되지 않는 기능.

유스 케이스 모델의 조사 설명에 대한 자세한 정보는 가이드라인: 유스 케이스 모델의 조사 설명 섹션을 참조하십시오.

결과 평가

이 단계에서 유스 케이스 모델을 확인하여 작업이 제대로 진행 중인지 확인하되, 모델을 자세히 검토하지는 마십시오. 또한 유스 케이스 모델에 대해 작업하는 중의 확인 작업도 고려해야 합니다. 찾아야 하는 사항에 대한 특정 권장사항에 대해서는 체크리스트: 유스 케이스 모델을 참조하십시오.

개발 팀에 속하지 않는 사람(예: 사용자와 고객)이 이 단계에서 유스 케이스 모델을 승인해야 합니다. 따라서 이 타스크를 완료하기 전에 유스 케이스 모델 검토 작업에 사용자와 고객을 참여시켜야 합니다. 이전 단계에서 작성된 유스 케이스 모델의 조사와 해당 유스 케이스 다이어그램을 논의에서 안내서로 사용할 수 있습니다.

이해 관련자들은 다음을 결정해야 합니다.

  • 필요한 모든 유스 케이스가 식별되었는지 여부
  • 필요하지 않은 모든 유스 케이스가 식별되었는지 여부
  • 각 유스 케이스의 동작이 올바른 순서로 수행되는지 여부
  • 각 유스 케이스의 이벤트 플로우가 이 단계에서 가능한 만큼 완벽한지 여부
  • 유스 케이스 모델의 조사 설명을 이해할 수 있는지 여부
특성
다중 발생
이벤트로 구동됨
진행 중임
선택사항
계획됨
반복 가능함
핵심 고려사항
단계: 유스 케이스 모델 조사 개발을 실행할 때 조사 생성을 고려할 수 있습니다. 자세한 정보는 보고서: 유스 케이스 모델 조사 및 도구 사용 도움말: Rational SoDA를 사용하여 유스 케이스 모델 조사 작성을 참조하십시오.
자세한 정보