이 활동의 목적은 전체 조직을 자세히 설명하는 것이 아니라 팀이 조직의 파트 우선순위를 결정할 수 있을 정도만 설명하여 프로젝트의 나머지 사항에 초점을 맞추도록 하는 것입니다. 비즈니스 모델링을
수행하는 이유에 따라 노력의 폭과 깊이가 달라져야 합니다(개념:
비즈니스 모델링 범위 참조). 예를 들어, 비즈니스 프로세스 리엔지니어링(BPR)의 경우에는 도메인 모델링의 경우에 비해 보다 광범위하고 자세한 비즈니스 모델이 필요합니다.
[JAC94](164 - 167페이지)는 "이 모델을 생성하는 것이 중요하다는 것을 인식하면서도 여기에 너무 많은 시간을 소모하지 않는 것이 중요하다는
점을 강조하려고 합니다"라고 지적합니다. "물론 보다 세부적이어야 할 상황이 있지만 추가적인 모델링의 부정적인 결과와 비교하여 이를 숙고해야 합니다"라는 점도 밝히고 있습니다. 이는 실제로 결국 필요
이상의 모델링이 되기 쉽기 때문입니다.
이 활동은 대개 비즈니스 유스 케이스 설명을 시작하기 전에 몇 가지 기초 작업을 수행하는 것으로 시작됩니다. 일반적으로 조직 구조를 설명하거나 필요하면 정제합니다(비즈니스 아키텍처 문서의 조직 및 지리 보기 참조). 비즈니스의 많은 부분을 모델링할 경우 비즈니스 시스템을 정의할 수 있습니다. 이와 관계 없이 첫 번째 스케치는 비즈니스 아키텍처 문서의 도메인 보기에 있는 비즈니스
엔티티로 구성됩니다. 이를 통해 논의를 위한 컨텍스트를 제공하여 비즈니스 모델링 워크샵 동안 커뮤니케이션이 순조롭게 진행됩니다. 또한 한 팀은 비즈니스
작업자에서 출발할 수 있습니다(조직 내에서 차지하는 직책으로 시작). 비즈니스 작업자는 역할을 나타내므로 직책과 혼동해서는 안되지만 직책은 비즈니스 작업자를 식별하는 유용한 시작점을 제공합니다.
다음에는 비즈니스 상태 평가 중에 이미 식별된 내용을 사용하여 비즈니스
목적을 정의합니다. 비즈니스 목적을 설명하는 도중이나 설명한 후에 비즈니스 유스 케이스 모델은 비즈니스
액터와 비즈니스 유스 케이스(및 비즈니스
이벤트)를 사용하여 구체화됩니다. 비즈니스 유스 케이스는 지원하는 비즈니스 목적까지 추적해야 합니다. 이 추적 중에 새로운 또는 기존의 비즈니스 목적을 식별하거나 정제할 수 있습니다. 비즈니스 유스 케이스의
동작을 지배하는 요구사항(예: 성능 요구사항)이 드러나는 경우에는 보충 비즈니스 스펙에 이를 문서화해야 합니다.
비즈니스 모델링 목표를 기반으로 비즈니스 유스 케이스의 우선순위가 결정되며, 비즈니스 아키텍처 문서의 비즈니스 프로세스 보기는 구조적으로 중요한 비즈니스 유스 케이스로 갱신됩니다. 그러면 우선순위가
가장 높은 비즈니스 유스 케이스에 대해 비즈니스 유스 케이스가 생성됩니다. 이미 식별된 비즈니스
작업자, 비즈니스 엔티티 및 비즈니스
이벤트를 정제하긴 하지만 시작점으로 사용할 수 있습니다. 이런 현재 비즈니스 유스 케이스 실현(realization)을 설명하는 동안 비즈니스 규칙이 드러나며, 비즈니스 규칙에 이를 캡처해야 합니다(비즈니스 분석 모델에 직접 또는 문서로).
이런 활동 수행 중에 발견된 모든 용어, 개념 및 정의를 비즈니스 용어집에 캡처해야 합니다. 이 활동이 종료될 때 우선순위가 가장 높은 비즈니스 유스 케이스를 통해 얻은 경험을
기반으로 필요하면 목표 및 기대를 재고하고 조정해야 합니다. 필요한 경우, 비즈니스
비전을 정제해야 합니다. 이 활동을 수행하는 동안 비즈니스 상태 평가 중에 내린 가정이나 결정이 잘못되었다는 사실이 명백해질 수 있습니다. 이런 경우, 실제 상황을 반영할 수 있도록 대상 조직 평가를 조정해야 할 수도 있습니다.
|