9‐1. 자매품) 개발자의 궁금증을 요구사항으로

서비스가 궁금하다고 하여 처음부터 만들 수는 없었다.
멘토링이 끝나기 전에 대기열 시스템을 다 만들어야 했기 때문에 절대적인 시간과 지식을 습득할 시간, 구현할 시간, 삽질할 시간이 부족했다.
빠르고 간결하게 궁금증을 작성하는 것부터 시작하여 이슈를 만들어갔다.
그러나 막상 작성된 요구사항을 기준으로 개발을 하다보니 기능간 결합도가 강한 부분과 필요하지 않는 요구사항들이 생겼다.

“어디서 부터 잘못된 걸까?”

팔짱을 낀채 모니터를 뚫어져라 쳐다보아도 뭐가 문제인지 알 수 없었다.
나의 지식의 한계로 발생한 문제였고, 상황을 해결할 방법으로 빠른길도 없었다.
요구사항이란 무엇인가부터 시작했고 기존에 작성한 문서의 문제점을 찾게되었다.

기존 요구사항

• API(사용자, 좌석, 예매 등)를 구현한다
• 각 기능별 단위 테스트를 작성한다
• 동시성 이슈를 고려하여 구현한다
• 대기열 개념을 고려하여 구현한다

기존 요구사항 문제점

요구사항이 너무 추상적이고 범위가 광범위함

1. 문제점
   • "API(사용자, 좌석, 예매 등)를 구현한다" → API가 어떤 기능을 수행해야 하는지 명확하지 않음
   • "동시성 이슈를 고려하여 구현한다" → 구체적으로 어떤 동시성 이슈를 해결해야 하는지 정의되지 않음
   • "대기열 개념을 고려하여 구현한다" → 대기열의 동작 방식(우선순위, 만료 시간 등)이 정해지지 않음
2. 개선 방법
   • 기능 단위로 세분화하여 명확한 목표를 설정
   • 각 기능이 해결해야 할 문제와 기대 결과를 명시적으로 정의
3. 예시
   • 잘못된 요구사항: "예매 API를 구현한다"
   • 개선된 요구사항: "예매 API는 사용자가 특정 좌석을 선택하고, 결제가 완료되면 해당 좌석을 예약 상태로 변경해야 한다."

비즈니스 로직과 기술적 구현이 혼재됨

1. 문제점
   • "동시성 이슈를 고려하여 구현한다" → 비즈니스 요구사항인가? 기술적 구현 세부사항인가?
   • "대기열 개념을 고려하여 구현한다" → 대기열이 어떤 방식으로 동작해야 하는지 정의되지 않음
2. 개선 방법
   • 비즈니스 요구사항과 기술적 요구사항을 분리해서 정의
   • 요구사항 정의서에서는 "무엇을 해야 하는지"를 다루고, "어떻게 구현할지"는 설계 단계에서 결정
3. 예시
   • 잘못된 요구사항: "대기열 개념을 고려하여 구현한다."
   • 개선된 요구사항: "사용자가 좌석을 예매할 때, 좌석이 모두 예약되었을 경우 대기열에 등록된다. 사용자는 자신의 대기열 순위를 확인할 수 있으며, 좌석이 해제되면 순서대로 예매할 수 있다."

결합도가 높은 기능들이 한 요구사항에 포함됨

1. 문제점
   • "API(사용자, 좌석, 예매 등)를 구현한다" → 사용자, 좌석, 예매 API가 서로 엮이면서 결합도가 높아짐
   • 하나의 PR에서 여러 기능이 함께 구현되어 변경 사항이 많아짐
2. 개선 방법
   • 기능별로 독립적인 요구사항으로 분리
   • 각 기능이 수행해야 할 역할을 정의하고, 기능 간의 관계를 최소화
3. 예시
   • 잘못된 요구사항: "예매 API를 구현한다."
   • 개선된 요구사항:

     • 예매 요청 API

       • 사용자는 특정 좌석을 선택하여 예매를 요청할 수 있다.
       • 예매 요청이 성공하면, 해당 좌석은 임시 예약 상태가 된다.
       • 사용자가 결제를 완료하면 좌석 상태가 "예약 완료"로 변경된다.

     • 예매 취소 API

       • 사용자는 예매한 좌석을 취소할 수 있다.
       • 취소된 좌석은 다시 예약 가능 상태로 변경된다.

     • 대기열 API

       • 좌석이 부족할 경우 사용자는 대기열에 등록된다.
       • 좌석이 해제되면 대기열에서 가장 앞 순번 사용자에게 좌석이 배정된다.

비즈니스 규칙이 부족함

1. 문제점
   • 예매 API의 실패/성공 조건이 명확하지 않음
   • 대기열에서 사용자가 일정 시간 응답하지 않으면 어떻게 처리할지 정의되지 않음
2. 개선 방법
   • 엣지 케이스를 고려한 요구사항 작성
   • 실패하는 경우를 정의하고 예외 처리 방식 명시
3. 예시
   • 잘못된 요구사항: "예매 API를 구현한다."
   • 개선된 요구사항:
     • 예매 요청 API
       • 사용자가 예매 요청 후 5분 내 결제를 완료하지 않으면 좌석이 자동 취소된다.
       • 좌석이 부족할 경우 예매 요청은 실패하고, 대기열에 등록된다.
       • 대기열에서 호출된 사용자는 3분 내 응답하지 않으면 대기열에서 자동 제외된다.

테스트 및 검증 기준이 정의되지 않음

1. 문제점
   • "각 기능별 단위 테스트를 작성한다" → 어떤 테스트를 해야 하는지 명확하지 않음
   • 동시성 테스트, 성능 테스트 등에 대한 가이드 부족
2. 개선 방법
   • 테스트 시나리오를 요구사항과 함께 정의
   • 예상 입력과 결과를 명확히 명시
3. 예시
   • 잘못된 요구사항: "예매 API를 구현한다."
   • 개선된 요구사항:
     • 예매 API
       • 사용자가 좌석을 예매하면 상태가 "예약 중"으로 변경되어야 한다.
       • 결제 완료 후 상태가 "예약 완료"로 변경되어야 한다.
       • 결제 없이 5분이 지나면 예약이 자동 취소되어야 한다.
       • 여러 사용자가 동시에 같은 좌석을 예매할 경우, 가장 먼저 요청한 사용자만 예약할 수 있어야 한다.

결론

잘못된 요구사항으로 인해 문제가 중첩되어 터지고 있을땐 이미 프로젝트 마지막 즈음이라 요구사항을 재정립하지는 못하였고, 문제의 근원이였던 요구사항만 남겨두었다.
기억하고 기억해서 실수를 줄이기 위한 근거 자료로 쓰기 위해…