앨리스터 코오번의 유스케이스
책 소개
작년부터 프로젝트 관리부분 문서 작성 부분의 일이 꾸준히 늘고 있는데 잘 알지도 못하는 유스케이스를 다른 문서들을 보면서 어떻게 따라하면서도 스스로 납득이 가지 않는 문서를 보며 이걸로 고객 또는 팀과 공유하며 업무 프로세스를 이해하기는 힘들다는 걸 느꼇다.
비슷한 책을 구매하긶 했지만 대부분 UML에 대한 설명은 매우 길어도 그 UML안에 유스케이스의 경우 정말 조금 다루기 때문에 정확하게 유스케이스를 어떻게 그려야하는지 항상 난감했다.
그래서 이번 8월달에 공부하고 싶은내용은 유스케이스 작성법이다. 이 책은 오로지 유스케이스 작성에 대한 내용만을 담았기 때문에 그동안 여러번 유스케이스를 작성하면서도 단순히 순서도 개념으로만 작성하는게 아닌 제대로 된 문서 작성법을 배우게 되지 않을까 기대감을 가지고 있다.
유스케이스?
유스케이스는 이해관계자와 시스템 간의 행위와 관련된 계약 내용을 담고 있다. 유스케이스는 일차 액터라 불리는 이해관계자의 요청에 응답을 하는 시스템을 서술하는데, 요청과 응답 행위는 다양한 조건 아래서 이루어진다. 일차 액터는 어떤 목표를 달성하기 위해 시스템과 상호작용을 시작한다. 시스템은 응답하되, 모든 이해관계자의 입장을 고려한다. 서로 다른 일련의 행위, 또는 시나리오는 특정 요청이나 그 요청을 둘러싼 조건에 따라 전개할 수 있다. 유스케이스는 서로 다른 여러 시나리오의 묶음이다.
이런 유스케이스를 작성하는 이유는 해당 프로젝트에 관련된 모든 이해관계자들간의 의사교환 수단이라는 것이다. 실무자부터 개발자, 관리자들까지 모든 사람들은 이 문서로 해당 시스템이 어떻게 구축할 지 이해할 수 있고 중간에 개발자든 담당자가든 변화가 있더라도 해당 문서를 통해 개발 범위에 대해 이해할 수 있다.
1장 소개
1.1 유스케이스는 어떻게 생겼나?
유스케이스는 플로차트나 시퀀스 차트, 페트리 네트, 프로그래밍 언어 등으로 작성할 수 있지만, 근본적으로 문장 형태다. 보통의 경우 개발자가 아닌 사람들도 같이 보고 의소소통 수단으로 사용하는 문서이기 때문에 단순한 문장으로 쓰는것이 가장 좋은 방법이다.
유스케이스는 사용하는 팀에 따라 요구사항을 정의하는 목적으로, 최종 설계를 위한 문서로 사용하기도 한다. 이렇게 유스케이스는 프로젝트의 규모나 단위에 다라 다르게 작성될 수 있다.
소프트웨어 개발에 필요한 요구사항을 유스케이스로 기록할 때, 목표 시스템은 바로 컴퓨터 프로그램이다. 즉 나는 개발할 웹 사이트이다. 이해관계자는 사이트를 이용하는 사용자, 관리하는 기관, 연계되는 시스템 등이다.일차액터는 사이트에 접속하는 사용자나 연계되는 시스템이다.
유스케이스를 작성할 때 유스케이스 전체에 적용되는 세 가지 개념을 완전히 이해해야 한다. 이 세가지 개념은 범위(무엇이 진짜 목표 시스템인가, 일차 액터(누구의 목표인가), 수준(그 목표 수준이 얼마나 높은가)이다.
책에는 실제 유스케이스의 예들이 들어있으니 궁금하면 책을 읽어보는게 좋다.
1.2 상황에 따라 사용하는 유스케이스가 다르다.
유스케이스는 다양한 케이스가 존재한다.
- 비지니스 프로세스 서술
- 목표 시스템 요구사항에 대한 논의
- 시스템의 기능 요구사항 서술
- 시스템 설계
- 소규모 단위 그룹이나 대규모 분산 그룹에서 작성하는 간결한 양식
유스케이스는 이렇게 다양한 상황을 모두 커버할 수 있는 문서라는 장점도 있지만 그만큼 어떤 유스케이스를 작성할지에 대한 고민을 작성자에게 안겨준다.
1.3 요구사항과 유스케이스
요구사항 식별을 목적으로 유스케이스를 작성한다면 두가지가 중요하다.
- 유스케이스는 그 자체가 요구사항이다. 이것을 행위 요구사항 형태로 변환할 필요는 없다. 제대로 작성하였다면 시스템의 행위를 정확하고 상세하게 표현한다.
- 유스케이스는 요구사항의 전부가 될 수 없다. 외부 인터페이스, 데이터 포맷, 비지니스 규칙, 복잡한 공식들을 다루지 않는다. 유스케이스는 요구사항의 한 부분이지 전체가 아니라는걸 기억해야한다.
유스케이스가 전체가 아닌 한 부분임에도 프로젝트의 핵심인 이유는 유스케이스 밖의 요구사항들은 유스케이스로 연결되기 때문이다.
1.4 유스케이스가 가치를 발하는 시점
유스케이스가 가장 가치를 발하는 첫 번째 순간은 시스템이 지원할 사용자 목표에 유스케이스 이름을 붙이고 목록을 작성할 때다. 이 목록은 시스템이 해야 할일과 시스템의 범위, 목적을 나타낸다. 이 목록을 통해 이해관계자 간의 의사교환을 할 수있다. 주요 내용은 어떤 기능을 먼저 구현하고 어떻게 팀을 구성할지에 대한 협상을 한다. 이 목록은 복잡성, 비용, 시간, 상태에 대한 측정을 부가하기 위한 프레임워크이다.
두 번째는 작성자가 성공 시나리오에서 잘못될 수 있는 모든 경우에 대해 브레인스토밍 하며, 그 결과를 나열하고, 시스템 응답을 문서로 작성할 때이다. 이를 통해 고객이나 개발자가 생각도 못했던 것들을 발견할 수 있다. 더 이상 실패조건이 나올 수 없을때까지 계속 찾다보면 새로운 이해관계자, 시스템, 목표, 비지니스 규칙을 발견할 수 있다.
1.5 에너지 관리
유스케이스 작성에 필요한 에너지를, 요구되는 에너지의 양과 각 단계 후 가지는 휴식의 가치에 따라 네 단계 정밀도로 구분해 보았다.
- 시스템에 지원할 액터와 목표를 나열한다. 팀과 릴리스별로 목표를 할당하고 우선순위를 정한다.
- 유스케이스에 대해 주요 성공 시나리오를 스케치한다. 시스템이 이해관계자의 이해관계를 정확히 반영하고 있는지를 확인한다.
- 성곤 시나리오를 완서앟고 발생 가능한 모든 실패 상황에 대해서 브레인스토밍을 한다. 시스템의 실패 처리방법에 대한 초안 수준의 전체 목록을 작업 전에 작성한다.
- 시스템의 각 실패 상황에서 대처하는 방법을 작성한다.
1.6 사용 이야기
사용 이야기는 유스케이스를 진행하는 상황의 한 예로 시스템을 사용하는 어떤 액터의 특정한 예다. 사용 이야기는 유스케이스도 아니고 산출물도 아니지만 매우 유용하다. 새로운 프로젝트를 시작할 때 개발자나 고객은 정확하게 어떤 시스템이 필요한지 정확하게 알지 못할 수 있다. 이럴 때 특정 액터를 만들어 해당 시스템을 어떤 방식으로 사용할지 이야기를 만들어 본다. 이야기는 간결하면서도 상세함과 동기, 감성적인 내용 역시 중요하다.
2장 행위에 대한 계약, 유스케이스
목표 시스템은 하나의 메커닞므으로서 다양한 이해관계자 간의 계약을 이행한다. 유스케이스는 그 계약에서 행위 부분을 서술한다. 두 액터의 상호작용을 서술하거나 이해관계자의 이해관계를 보호하기 위해 시스템이 내부에서 해야하는 일을 서술한다.
2.1 목표를 가진 액터 간의 상호작용
시스템에는 목표가 있다. 예를들어 전화로 서비스 요청을 받는 직원이 있다면 서비스 요청을 등록하고 시작할 목표가 있다. 자신의 책임을 수행하기 위해 시스템은 하위목표를 세운다. 내부에서 수행할 하위목표도 있지만 외부 지원 액터의 도움이 필요할 수 있다.
서비스 약속을 이행하는 것이 가장 중요한 목표이고 이 목표는 하위목표 달성을 통해 이루어진다. 하위목표 또한 하위-하위... 쭉 이어질 수 있다.
또 목표는 실패할 수 있는데 극단적으로 전화를 받는 중 컴퓨터가 다운된다면 시스템을 사용할 수 없다. 이럴 경우를 대비해서 예비 목표를 세워야 한다.
하위목표를 세우다 보면 이렇게 실패 할 수 있는 목표들을 볼 수 있다. 이런 실패들을 만났을때 예외처리를 하는것은 중요하기 때문에 유스케이스를 작성은 큰 장점이 있다.