[agricola 프로젝트 리뷰] 요구사항 분석이 부족해서 일어난 일

요구사항 분석
: 소프트웨어 개발의 초기 단계에서 사용자의 필요를 이해하고 이를 기능으로 변환하는 과정

 

배경

• 기획은 존재하는 상태 (아그리콜라 설명서)
• 우리가 해야 할 것은 [ API 명세 협의하여 작성하기 ]
• 구현하기

 

이를 위해 노력 한 것은

1. Entity 분석
2. 프로토타입 범위 정하기
3. 행동 기반 플로우 작성 notion을 공유함
4. FE UI state 부분까지 고려하여 개발
5. FE에서 API와 연동하여 개발하고자 함
 

근데 왜 잘 안됐지?

1. API 명세를 BE, FE가 서로 협의하지 않음 (소통의 부재, 필요 인지의 부재)

• 백엔드가 프론트엔드를 고려하지 않고 API 명세를 만드는 경우가 일반적이지 않다. 근데 우리는 이랬던 것 같다.
  : 백엔드 개발자가 API를 설계할 때는 프론트엔드의 요구사항을 반드시 고려해야 한다. 프론트엔드와 백엔드는 서로 다른 시스템이지만, 사용자에게 완성된 제품을 제공하기 위해서는 서로 긴밀하게 협력해야 한다. 따라서 백엔드 개발자는 API를 설계할 때 프론트엔드의 요구사항을 충족시키는 것을 목표로 해야 한다다. 이를 위해 API 명세를 작성하고 프론트엔드 개발자와 공유하며, 필요한 수정사항이 있다면 함께 논의하여 반영하는 것이 중요하다. (_copilot)
• 프론트엔드의 요구사항을 적은 "행동 기반 플로우 작성 notion"을 공유하였지만, BE에서 이해도가 부족했던 것 같다.

 

2. API 명세를 위한 소통은 했지만,
필요한 요소를 완벽하게 협의하지 못해서 FE 비즈니스 로직과 API 간의 싱크가 꼬임

++ API 명세 작성시 고려해야 할 주요 요소들

1. Endpoint: API의 URL을 정의합니다. 이는 API가 어떤 리소스에 접근하는지를 나타냅니다.
2. HTTP Method: API 요청의 유형을 나타냅니다. 주로 GET, POST, PUT, DELETE 등이 사용됩니다.
3. Parameters: API 요청에 필요한 파라미터를 명시합니다. 이는 경로 파라미터, 쿼리 파라미터, 바디 파라미터 등이 될 수 있습니다.
4. Request Body: POST 또는 PUT 요청에서 사용되는 데이터의 형식과 예시를 제공합니다.
5. Response Body: API 응답의 예상 형식과 예시를 제공합니다.
6. Error Codes: 가능한 오류 코드와 그에 대한 설명을 제공합니다.
7. Authentication: API가 인증을 필요로 하는 경우, 이를 어떻게 처리할지 명시합니다.

 

So 우리는

1. BE API List notion 문서를 만들어서 시나리오 기반으로 필요한 API들을 리스트업 해서 요청했다.
=> 그러나 ! 위에서 언급한 것처럼 API 명세에 필요한 요소들에 대한 소통이 부족해서 복잡한 parameters, request Body, response Body가 만들어지는 상황이 초래되었다.
=> 엄청나게 복잡한 코드 생성 ! 빠밤 !
 

부드러운 진행 과정이었다면

API 명세 협의한 후
-> FE는 mock 만들어서 하고 있기
-> BE는 API 개발하기
-> FE는 API가 개발 되는 대로 mock data를 사용했던 부분 변경하기
 
이렇게 진행되었을 것 같다.