Essential Use Cases
- 신규 프로젝트를 위한 유스케이스 작성, 관리 지침
주의. 해당 글은 매우 길고 지루합니다. 굳이 안 보셔도 됩니다. 그냥... 각자 방법대로 잘 하시면 됩니다. 필자의 개인적인 스터디를 위해 정리한 글입니다!
그리고, 쉬는날 집에서 작성하는 글입니다. 몇몇 회사분들이 회사에서(업무시간에)글 쓰는 거 아니냐고 자꾸 눈치 주시는데, 회사에서는 한글자도 적지 않겠습니다.
(솔직히 회사 일 잘하겠다고 나름 시간내서 소중한 시간 쪼개서 작성하는 건데...ㅠㅠ )
Overview
필자는 지난주부터 약 일주일 동안 유스케이스 작성 지침에 대해서 스터디 중이다. 유스케이스 작성은 예전에 프로젝트 진행할 때 작성한 경험이 있지만 제대로 된 가이드를 기반으로 작성한 적은 없다. 누군가 만들어놓은 유스케이스 문서를 참고하는 수준이었다. 이번 기회에, 유스케이스 지침을 정리하고 프로젝트에 도입을 하고자 한다.
단, 매우 개인적인 의견이기 때문에 정답은 절대 아니라는 점을 먼저 얘기하고 싶다.
다양한 참고 자료를 바탕으로 정리하는데, 가장 많이 참고한 자료는 "Writing Effective Use Cases - Alistair Cockburn" 이다. 비록 매우 오래 전의 원서이지만, 내용이 매우 훌륭하며 내 생각과 많이 일치해서 많은 참고를 했다. 저작권에 문제가 되지 않는 수준으로 참고하여 작성하였는데 혹시라도 문제가 된다면 피드백을 부탁한다. 또한 국내에 해당 원서에 대한 번역 책이 두권 있는데, 약 15년 전에 출판한 번역서는 현재 절판된 상황이고, 2011년에 나온 번역서가 있으니 관심이 있다면 읽어보길 바란다. 원서가 어렵기 때문에 번역서도 꽤 어려운 편이다. 기회가 된다면 원서를 구매해서 읽어보길 바란다.
https://www.amazon.com/Writing-Effective-Cases-Alistair-Cockburn/dp/0201702258
0. 개인적인 경험
1. 유스케이스란
2. 유스케이스 기본 개념
3. 유스케이스 작성 지침, 주의사항
4. 산출물
5. 샘플 예시
6. 정리
0. 개인적인 경험
필자의 아주 지극히 개인적인 경험이다. 그동안 포털서비스를 개발/운영하면서 유스케이스를 작성할 일이 거의 없었다. 대부분의 프로젝트는 아래와 같이 진행했었다.
1. 기획자는 프로젝트의 요구사항을 아주 상세하게 정리한다. "상세기획안"으로 공유된다.
(상세기획안의 포맷은 기획자의 성향에 따라서 다양하다.)
2. 개발자는 "상세기획안"을 기반으로 설계/분석한다. 이 과정에서 인터페이스, 시스템 구성도 등 필요한 문서를 작성한다. 그리고, 이 과정에서 일정이 산정된다.
3. 개발자와 기획자는 최종 산정된 일정을 기반으로 상위 보고를 하고, 컨펌이 되면 개발단계를 진행한다.
(이 과정에서 일정으로 인해서 기능 스펙 아웃이 될 수도 있다.)
4. 개발자는 해당 일정에 맞게 개발을 열심히 수행하여, 개발을 1차 완료한다.
5. 기획자 및 QA 담당자는 배포 전 테스트 단계를 수행한다. 이때, "상세기획안" 과 "단위테스트 목록" 을 기반으로 테스트한다. 수정사항을 반영한다.
6. 테스트가 완료하면 서비스 배포 프로세스를 진행한다.
모든 프로젝트가 해당 프로세스를 따르지는 않는다. 개인적인 경험이다.
그렇다면 이번에 필자가 유스케이스 가이드를 작성하게 된 이유는?
1. 상세 기획안이 없다. 기획자도 없다. 문서도 없다.
2. 비즈니스 요구사항이 매우 복잡하다.
3. 도메인 전문가는 딱 한 명이다. 다른 팀원들은 도메인 이해도가 매우 떨어진다.
프로젝트의 개발 담당자는 요구사항을 도출해 내야 한다. 또한, 도출된 요구사항을 기반으로 일정을 산출해야 하고, 산출된 일정을 상위 보고한 이후에, 컨펌이 나면 개발을 수행한다. 만약 프로젝트 개발 담당자가 요구사항 도출이 어렵다면 어떻게 될까?
1. 일정 산정이 정확히 안될 것이다.
2. 개발자는 큰 그림(?)을 볼 수 없고, 뭘 개발해야 하는지에 대해서도 이해하기 어렵다.
3. 일정 산정이 제대로 안되면, 상위 보고 시 일정을 러프하게 보고할 것이다.
4. 프로젝트를 진행해보면, 생각했던 일정대로 진행이 안된다. 야근을 하거나, 일정을 다시 잡는다.
5. 스트레스를 받는다.
6. 동기부여가 떨어진다.
7. 개발하기가 싫어진다.
너무 지나친 나비효과인가? 글쎄 다른 프로젝트는 잘 모르겠지만, 필자는 많이 경험했다. 어쨌든 소프트웨어 개발은 어렵지만, 우리는 잘 만들어야 하는 책임이 있고, 소프트웨어의 품질은 프로젝트의 PM과 개발자의 몫이다. 기획자, 협업하는 다른 개발자, 회사 등 다른 이유로 남을 탓하지 말자. 수단과 방법을 다 동원하고, 올바른 커뮤니케이션을 통해서 소프트웨어를 잘 만들어야 하는 것은 개발자의 몫이 제일 크다.
필자가 유스케이스 가이드를 작성하는 이유는
소프트웨어를 올바르게, 가치 있고 즐겁게 만들기 위해서이다.
다시 한번 말하지만, 기획자의 요구사항이 명확하고 잘 정리된 "상세기획안"이 있다면, 굳이 유스케이스를 작성하지 않아도 된다.
필자가 유스케이스를 작성하는 이유는
상세 기획안이 없고, 기획자도 없고 문서도 없는 경우이며,
비즈니스 요구사항이 매우 복잡하고,
도메인 전문가는 딱 한 명인 상황
다른 팀원들은 도메인 이해도가 매우 떨어지는
전체적으로 개발 커뮤니케이션이 깔끔하지 못한 상황이고, 유스케이스 작성으로 올바르게 소프트웨어를 개발하기 위해서이다.
1. 유스케이스란
위키피디아에서 참고한 내용은 아래와 같다.
"In software and systems engineering, a use case is a list of actions or event steps typically defining the interactions between a role (known in the Unified Modeling Language as an actor) and a system to achieve a goal. The actor can be a human or other external system. In systems engineering use cases are used at a higher level than within software engineering often representing missions or stakeholder goals. The detailed requirements may then be captured in the Systems Modeling Language (SysML) or as contractual statements. "
https://en.wikipedia.org/wiki/Use_case
"소프트웨어 공학에서, 유스케이스는 일반적으로 역할(액터)&목표를 달성하기 위한 시스템 간의 상호 작용을 정의하는 작업 또는 이벤트 단계 목록이다. 액터는 사람일 수도 있고, 시스템일 수도 있다. 중간생략.."
유스케이스를 작성하는 방법은 다양한데, 대표적으로는 유스케이스 다이어그램으로 표현하는 방법이다. 하지만, 필자는 명확하게 다이어그램이 아닌, 글로 작성하는 유스케이스를 선호한다. 물론, 유스케이스 외에 시스템 구성도나, 설계 문서는 반드시 다이어그램으로 작성해야 서로 이해하기 좋다는 생각이다. 하지만, 유스케이스는 글로 작성하는 것이 훨씬 이해하기 쉽다고 생각한다. 내 생각을 뒷받침하는 의견이 바로 "Alistair Cockburn" 의 스타일이다.
https://en.wikipedia.org/wiki/Alistair_Cockburn
참고로 이 사람의 개인 블로그는 오류가 나고 있다. ㅠㅠ 오류 내용을 보니, ASP.NET 환경인 거 같기는 하다.
아무튼! 그래서 이 글에서는 다이어그램은 전혀 등장하지 않는다. 실망했다면, 이 글은 읽지 않는 것이 좋을 것이다.
2. 유스케이스 기본 개념
유스케이스 예시2.1 기본 용어 정리
위에 작성했듯이, 유스케이스는 액터가 목표를 달성하기 위해서 시스템 간의 상호 작용을 정의하는 문서이다. 액터는 목표를 가지며, 액터는 사람일 수도 있고 시스템일 수도 있다. 제일 먼저 등장하는 액터를 "초기 액터" 라고 표현한다. 목표를 가진 "초기 액터"는 다른 액터(사람일 수도 있고, 시스템일 수도 있는)와 복잡한 상호작용을 하며, 목표를 달성한다. 일차 액터가 목표를 달성하기 위해서는 시나리오가 존재하는데, 목표 달성을 위한 시나리오를 "성공 시나리오" 라고 부르자. 성공 시나리오에 모두 작성하기 어려운 내용은 "확장 시나리오"라고 하자. 근데, 목표를 달성하기 위한 초기 액터는 왜 목표를 달성하고자 할까? 어떤 이유인지 모르겠지만, 어떤 사건 있을 것이다. "트리거" 라고 하자. 또한, 이 목표를 달성하기 위해서 반드시 사전에 수행해야 하는 기본 조건을 "선조건" 이라고 부르자.
액터, 초기액터
목표
성공 또는 실패 시나리오
확장
트리거
선조건
유스케이스는 액터가 목표를 달성하기 위해서, 시스템 간의 상호 작용을 정의하는 문서이다.
2.2 목표 수준
목표는 세가지 수준으로 정한다.
필자는 "Writing Effective Use Cases - Alistair Cockburn"를 참고하여 세가지 수준으로 정하였다.
요약 수준 : 흰색, 사용자 목표가 수행되는 컨텍스트(범위)
사용자 목표 수준 : 푸른색, 작업을 완료하고자 하는 일차 액터가 가지고 있는 목표
하위 기능 수준 : 남색, 사용자 목표를 수행하는데 필요한 하위 기능
참고로 더 상세하게 나누면 5가지 수준으로 정할수 있다.
아주 높은 수준의 요약(순백색)
요약(흰색)
사용자 목표(푸른색)
하위기능(남색)
사소한 하위 기능(검은색)
3. 유스케이스 작성 지침
3.1 사용자 목표 수준
필자는 "아주 높은 수준의 요약" , "사소한 하위 기능" 은 유스케이스에 작성하지 않기로 정하였다. "Writing Effective Use Cases - Alistair Cockburn" 의 가이드와 필자의 의견에 따르면 유스케이스에 너무 상세한 하위기능을 작성하면 문서 관리하기 어렵고, 읽는 것도 어렵다. 중요한 점은, 가능하면 사용자 목표 수준(푸른색) 에 집중해야 한다는 점이다. 사용자 목표 수준의 유스케이스는 시스템 행위를 가장 간단하게 요약한 문서이며, 해당 문서를 기반으로 우선순위 결정, 일정 검토 등 중요한 작업의 바탕이 된다. 신규 프로젝트를 진행한다면 아마도 아래 정도로 작성할 것이다.
아주 높은 수준의 최상위 유스케이스(순백색) : 작성하지 않는다.
높은 수준의 요약 유스케이스(흰색) : 많으면 3~5개
사용자 수준의 유스케이스(푸른색) : 30~80개 (프로젝트 규모에 따라서 변경)
하위 기능 수준의 유스케이스(남색) : 10개 내외, 정말 필요한 중요 기능만 작성
아주 낮은 수준의 사소한 하위 기능(검은색) : 작성하지 않는다.
3.2 Top-Down
목표 수준을 기준으로 위에서 아래로 작성한다.
요약(높은 수준) --> 사용자 수준(푸른색) --> 하위 기능 수준(남색) 으로 작성한다.
만약 하위 기능부터 작성해나간다면, 전체적인 큰그림(?) 을 보기가 어려울 것이다. 가능하면 전체적인 큰 그림을 볼 수 있는 높은 수준의 문서를 먼저 작성한 이후에 사용자 수준에 집중해야 한다. 하위 기능 수준은 추후에 필요할 경우에만 작성하는게 좋을 것이다. 높은 수준의 요약 유스케이스는 사용자 수준과, 하위 기능 수준의 유스캐이스 위에 놓여있게 된다. 즉, 시스템의 모든 유스케이스로 접근하는 출발점이 요약 유스케이스가 되는 것이다.
3.3 사용자 수준 유스케이스의 제목
하나의 사용자 수준 유스케이스는, 하나의 목표를 가진다. 사용자 목표는 유스케이스 제목에 잘 표현해야 한다. 유스케이스 리스트가 곧 사용자 수준의 목표 리스트인 것이다. 유스케이스의 제목 리스트만 보면, 전체적인 사용자 목표를 쉽게 파악할 수 있어야 한다. 만약, 유스케이스의 제목 리스트를 보고 전체적인 행위 및 기능을 파악할 수 없다면 아래와 같은 주의사항을 체크해보자.
올바른 목표 수준을 가졌는지?
액터(주체)는 명확한지?
짧은 동사구로 작성하였는지?
문장을 신경써서 작성하였는지?
3.4 읽기 쉬운 한 문장으로 작성한다.
필자의 글처럼... 주저리주저리 작성한 문장은 읽기가 싫다. 문장을 짧게 유지해야 즐겁게 읽을 수 있다. 사실 제일 중요한 내용이지만 제일 어려운 일이다. 개발자는 글을 잘 못쓴다. 필자도 마찬가지이지만...
3.5 지나치게 많이 작성하는 것보다는, 차라리 지나치게 적게 작성하는 것이 좋다.
매우 낮은 수준으로 하위 기능을 상세하게 작성한 문서를 누가 유심히 보겠는가? 팀의 커뮤니케이션이 차단될 것이다. 지혜롭게 적당히 작성하는것이 현명하다.
4. 산출물
유스케이스 작성으로 여러 종류의 산출물이 생성된다. 필자가 생각하는 꼭 필요한 산출물을 정리하였다.
4.1 요약 수준 유스케이스
3~5개 정도의 요약 수준의 유스케이스를 작성한다.
4.2 액터-사용자 수준 목표 유스케이스 리스트
액터-사용자수준목표 리스트는 시스템에 대한 전체를 파악하기 유용하다. 물론, 각 목표에 대해서 상세한 내용을 파악하기는 어렵지만 한 눈에 전체 시스템을 파악할 수 있어서 유용하다.
예시)커피 자동 구매 시스템4.3 [가장 중요]사용자 수준 유스케이스
위에도 설명했지만, 사용자 수준의 목표 유스케이스가 가장 중요하다. 흰 화면은 요약 수준의 유스케이스이고, 푸른색은 사용자 목표 수준의 유스케이스이다.
예시) 유스케이스4.4 기타 문서
설계 범위 그림, 내부/외부 목록, 비전 기술서 등 다양한 산출물이 나올 수 있다.
5. 샘플 예시
샘플 예시는 쿨하게 생략한다. 회사에서 작성 중인 유스케이스를 올릴 수가 없어서 아쉽지만, 개인적으로 작성한 유스케이스는 크게 도움이 안될것 같아서 이 글에서는 생략하기로 한다. "Writing Effective Use Cases - Alistair Cockburn" 의 예시는 전부 실무에서 적용했던 유스케이스를 예시로 하고 있다. 원서를 찾아서 읽어보길 바란다.
6. 정리
해당 글은 "Writing Effective Use Cases - Alistair Cockburn" 의 일부 내용만 정리하였다. 더 상세한 내용이 궁금하다면 해당 원서를 꼭 읽어보길 바란다. 저작권으로 인해서 자세한 내용을 담을수는 없다. 어쨋든, 이 글은 이론 정리에 가깝다. 실제로 유스케이스를 활용하면서 시행착오가 많을 수 있다. 지금 진행하는 프로젝트가 성공적으로 마무리되면, 유스케이스 활용 사례 또는 시행착오에 대해서 한번더 글을 작성할 예정이다.
부디, 가치 있는 소프트웨어가 출시되기를 바라는 간절한 마음을 담아서 이번 글을 마무리 한다
