🚀 돌아온 3주차 회고!
1. 문제점
이번 주차에서 가장 기억에 남은 작업은 '요구사항 분석 자료'를 만들 때이다.
처음에는 어떤 자료를 만들어야 할지 몰랐다. 곰곰히 생각해보니 '유즈케이스를 정의하라'는 이야기를 들었던게 떠올랐다.
유즈케이스에 대해 찾아보고 다음과 같은 정의를 내렸다.
유즈케이스 = 요구사항을 어떤식으로 정의하고 해결할건데?"그럼 요구사항에 대한 유즈케이스를 작성하면 되겠네?"
유즈케이스를 어떻게 정의할 것인지 생각해보았다. 어찌되었든 자료는 만들어야 하기 때문에 유즈케이스 다이어그램을 작성해보았다.
그런데 좀 이상하다.
요구사항 자료에 있던 내용을 그대로 다이어그램으로 만들어 놓은 느낌이었다.
예를 들어 '많은 사람들이 동시간대에 좌석을 예약할 수 있어요. 단, 결제가 이루어져야 예약이 완료됩니다.'라는 요구사항이 있을 때 다음과 같이 정의할 수 있다.
좌석 예약 API
- 예약은 순서대로 이루어져야 합니다. = `대기열 시스템`
- 좌석을 예약하면 임시 할당됩니다. = `임시 할당`
- 결제가 이루어지면 예약이 완료됩니다. = `예약 완료`즉, 과제에는 이미 어느정도 유즈케이스가 나와있었다.
무작정 만들고 난 다음에야 깨닿게 되었고 자료로서 사용하는 것이 의미가 없다고 판단했다. 때문에 '요구사항을 분석하고, 분석된 자료를 다른 사람에게 인수인계한다'는 느낌으로 다시 한 번 생각해보았다.
2. 해결법
각각의 API에 대해 모르는 사람도 설명할 수 있는 자료가 필요했다.
고민 하던 중 Sequence Diagram을 사용하게 되었는데 그 이유는 다음과 같다.
- API의 흐름에 대해서 정의할 수 있다.
- 서버가 무엇을 할 수 있는지 알 수 있다.
- 요구사항을 어떻게 해결하는지 이해관계자들에게 설명할 수 있다.
Sequence Diagram을 Figma로 그렸는데 너무 비효율적이었다. 팀원 분들 중 DML로 다이어그램을 그릴 수 있는 Mermaid라는 도구를 추천해주셨다.
확실히, 그리는 것보다 작성하는 것이 효율이 더 좋았다.
Figma로 그린 Sequence Diagram, 역시 개발자는 코딩으로 다 해야함
3. 깨달음
이번 주차는 코딩보다 '어떻게 만들건지?'에 대해서 깊게 고민하는 주차였다.
이를 통해 제품에 대한 도메인의 이해도를 높이고, 백엔드 개발자가 아닌 프론트엔드 / 기획자 / PO 등의 이해 관계자들을 설득(?)시키기 위해 어떻게 할 건지 생각해보는 시간이었다.
회사에서 새로운 프로젝트를 진행할 때마다 내 생각을 정리하기 위해 자료를 싸지르기만 한 것 같다. 어떤 마음가짐으로 제품을 이해하고 소통해야할지 고민할 수 있는 시간이어서 코딩과는 또다른 재미가 있었다.
정리하자면..
- '요구사항을 어떻게 정의해야 할지' 또는 '문제에 대해 어떻게 접근해야 할지' 고민해보았다.
- 요구사항에 유즈케이스가 정의되어 있으니 이를 토대로 Sequence Diagram을 작성하였다.
- Diagram은 직접 그리지 말자.. (Mermaid나 UML로 코딩할 수 있는 도구 강추👍)
- 요구사항 자료를 통해 도메인에 대한 이해를 높이고 정의한다. 또한, 자료를 통해 이해관계자들도 볼 수 있는 자료를 만든다.
