프로젝트 구상 ② : 유스케이스 다이어그램, 요구사항 명세서
목차
- 시작하며
- 요구사항 명세서
- 유스케이스 다이어그램
- 내가 작성한 유스케이스 다이어그램, 요구사항 명세서
- 마치며
시작하며
이번 포스팅은 저번 포스팅이후로 꽤나 시간이 지난 시간이라고 생각한다.
원래는 처음부터 일정표를 작성하고 해당 일정에 맞춰서 '어떻게든 해보자' 라는 마음가짐으로 프로젝트를 진행하려고 했었는데, 구글에 '토이프로젝트 가이드라인' 이라고 검색하고 내용을 보니까 요구사항 명세서(정의서)라는 것을 작성해야 향후 프로젝트 진행에 현실성과 진행 방향을 잡아줄 수 있다는 글을 보았다.
생각해보니, 이전 회사는 항상 대기업의 고객사에서 수주가 발생하면 해당 프로젝트에 대한 일정을 사원인 나보고 대충 아무렇게나 해서 송부하라고 강요했던 기억이 난다. (선임분들께 물어봐도 대충 그냥 작업 당 하루이틀씩 잡아서 만들라고 했음..)
당연히 잘 모르는 사람(신입이..)이 일정을 작성하니 제대로 계획될리가 없다. 그러다보니 자연스레 애자일스러운 진행이 반복되었다.
심지어 고객의 요구사항은 윗선에서 담당자에게 안알려주고 담당자인 나는 모르는 부분이 생겨 물어보면 그 부분에 대한 것만 들을 수 있는 시스템이라 이번에 포스팅할 요구사항 명세서(정의서)에 대해 잘 모를 수 밖에 없는 느낌이었다.
서론이 길었는데 이것저것 알아보면서 내가 습득한 요구사항 명세서, 유스케이스 다이어그램이란 무엇인가에 대해 포스팅 하려고 한다.
요구사항 명세서(정의서)
나는 개인적으로 요구사항 명세서가 영업적으로 굉장히 중요한 문서라고 생각한다.
그 이유는 다음과 같다.
- 최초에 요구사항별 협의를 잘 해놓아야 추후 프로젝트 완료시기에 억울한 독박을 피할 수 있다.
- 고객이 원하는 기능을 한번에 볼 수 있는 문서가 있어야 프로그램 개발 중에도 방향성을 잃지않고 고객이 진정으로 원하는 서비스를 개발할 수 있다.
- 개발자도 결국엔 누군가 필요로 하는 프로그램을 의뢰받아서(혹은 호기심일수도 있지만) 만들지, 필요하지도 않는 프로그램을 만들지는 않기 때문이다.
유스케이스 다이어그램
유스케이스 다이어그램은 시스템과 사용자의 상호작용을 표현한 다이어그램으로 사용자의 관점에서 시스템의 서비스 혹은 기능 및 그와 관련한 외부 요소를 보여주고 사용자가 시스템 내부에 있는 기능 중에 어떤 기능을 사용 할 수 있는지 나타내며 유스케이스 다이어그램을 사용함으로써 고객과 개발자가 요구사항에 대한 의견을 조율 할 수 있다.
나는 유스케이스 다이어그램을 바탕으로 요구사항 명세서를 작성하려고 했고,
작성된 두 서류를 바탕으로 IA를 만들어보려고 생각하고 있다.
내가 작성한 유스케이스 다이어그램
솔직히 웹 서핑을 하면서 다양한 블로그, 웹 사이트와 유튜브를 찾아봤는데 명확하게 감이 오진 않았지만, 유저와 유저가 사용할 수 있는 기능들에 대해 생각하면서 생각하면서 작성해 보았다. 작성은 draw.io 를 활용했다.
솔직히 유스케이스 다이어그램을 처음 작성해서 올바르게 작성한지는 모르겠지만, 원래 유스케이스 다이어그램을 사용하는 이유가 요구사항을 요약하고 시스템의 흐름을 나타내는 용도이기 때문에 이에 합리적으로 작성하려고 노력했다.
내가 작성한 요구사항 명세서
작성된 유스케이스 다이어그램을 바탕으로 내가 고객이라고 생각하고 필요한 기능들을 나열해 보았다.
마치며
토이프로젝트나 혹은 나중에 맡게될 프로젝트에 대해 분석적인 시야를 얻기 위하여 요구사항 명세서와 유스케이스 다이어그램을 만들어 봤는데, 잘 된건지는 모르겠다. 하지만 이를 통해 다음에는 IA에 대해 포스팅 하려고 한다.
(혹시 이상한 점이나 부족한 점이 있으면 댓글 부탁 드립니다......ㅠㅠ)
감사합니다!!