🍒 2025.11.18 🍒
✏️ 오늘의 할 일 계획
- 고객 관점 요구사항 정의서 전면 수정하기
- 기술 정의서 만들기 → 문서화 하기
- 코드 컨벤션
- 수행계획서
- WBS
- API 명세서
‼️ 강사님 피드백
1. 로그인 전 홈 페이지
• 로그인 전에 기능 제공: 챗봇 기능설명 UI가 로그인 전에 기능을 보여줄 수 있도록 하고, 채팅 내용을 미리 보여주는 방식으로 사용자가 기능을 이해할 수 있게 제공
2. 웨어러블 기기 연동
• 매봉역 회사에서 웨어러블 기기 수령: 한 명이 매봉역 회사에서 웨어러블 기기를 가져오도록 하며, API 연동 방식에 대해 논의하여 연동 방법을 결정하기
3. 백엔드 설계 및 구체화 단계
• 백엔드 설계 시작: 백엔드 설계를 시작하고, 연동을 위한 구체화 단계에 진입할 것, 백엔드에서 API 연동을 통해 특정 화면을 DB와 연결하고, 이를 기반으로 메인 스트림과 연계
• Pilot 상태에서 핵심 기능 구현: Sprint 1에서 핵심 기능을 구현하여 pilot 상태에서 돌아가도록 설정하기
4. SNS 공유 기능
• 사진 공유 제한: SNS 공유 시 사진은 유료 API를 사용해야 할 가능성이 있어, 글만 공유되는 방식으로 기능을 설계
• 대안: Reddit 활용: 사진 공유 대신 Reddit에 콘텐츠를 업로드할 수 있는 방법을 고려하여 동작을 테스트하고, SNS 공유 기능을 대체할 수 있는 방안을 모색할 것
5. 보험 제휴 서비스 연계
• 발전 가능성으로 보험 제휴 서비스 연계: 보험 제휴 연계 서비스는 추후 발전 가능성을 고려하여 나중에 구현
• 쇼핑몰 연계로 대체: 일단 쇼핑몰 연계 기능으로 대체하여 기본 서비스를 제공
6. 일지 작성 시스템
• 일지 포인트 산정 기준: 지역 정보와 사진을 얼마나 넣었는지 기준으로 포인트를 산정, 사진의 위치 정보와 강아지가 포함된 사진을 포함하면 점수를 더 높게 부여
• 비공개 산정 시스템: 사진 3장 이상 업로드 시 추가 포인트를 부여하는 방식으로 점수 산정을 비공개로 설정
• LLM 활용하여 점수 산정: LLM을 활용하여 일지가 얼마나 작성되었는지 1~9 척도로 환산하여 포인트를 주는 시스템을 정의하기
=> 예시: 네이버 블로그 환산 시스템처럼 지도, 동영상 등이 첨부되면 점수가 높게 산정
7. 문서 작성
• 수행계획서, 요구사항 명세서, WBS, DB 설계서, API 설계서 작성
=> 각 문서의 구체적인 요구 사항과 설계 사항을 명확하게 정리하여 진행
🔥 11월 15일 멘토님이 요구사항정의서관련 피드백해주신 내용 🔥
1) 고객의 언어로 작성: 개발자가 아닌 고객이 이해할 수 있도록, 기술적인 용어나 개발자의 언어는 피하고 고객이 쉽게 이해할 수 있는 용어로 요구사항을 작성해야 한다.
2) what을 정의하고, how를 배제: 요구사항 정의서에는 ’어떤 기능을 해야 하는지(what)’만 정의하고, ’어떻게 구현할 것인지(how)’는 포함하지 않도록 한다.
3) 도메인별 분류: 요구사항을 도메인(목적어) 기준으로 묶어, 예를 들어 쇼핑페이지를 ‘장바구니’, ‘상품’ 등으로 나눈다.
4) 기능 우선순위: 비즈니스적으로 중요한 기능(핵심기능)을 우선순위 높게 지정하고, 기능 구현 난이도에 따라 우선순위를 조정한다. 핵심 기능은 20% 정도로 정의하여 비전 수립에 도움이 되도록 한다.
5) 요구사항 정의서와 설계서의 차이: 요구사항 정의서는 사용자 관점에서 추상적이고 what을 정의하며, 설계서는 개발자 관점에서 구체적이고 how을 정의한다.
고객관점 요구사항정의서 1차 초안 일부
멘토님의 피드백 바탕으로 고객 관점에서의 요구사항정의서를 전반적으로 수정
프로젝트 수행계획서 1차 초안 일부
🌻 회고 🌻
오늘은 전반적으로 문서 작업과 기획 정교화에 초점을 맞춰 프로젝트를 진행한 하루였다. 요구사항 정의서, 수행계획서, WBS, 기술 정의서 등 프로젝트의 뼈대를 구성하는 핵심 문서들을 정리하면서, 단순히 문서를 채우는 작업이 아니라 서비스의 방향성과 구조를 다시 한 번 검토하는 중요한 과정이라는 점을 다시 느낄 수 있었다.
특히 고객 관점 요구사항 정의서를 전면적으로 수정하는 과정에서는 멘토님이 강조하셨던
“고객의 언어로, what만 정의하라”
는 원칙을 실제로 적용해보며 기존 문서와의 차이를 체감했다.
기술적인 표현을 배제하고 고객이 이해할 수 있는 문장으로 바꾸는 과정에서 기능의 본질이 더 명확해졌고, 서비스가 어떤 가치를 제공하려는지 다시 선명하게 정리할 수 있었다.
또한 강사님으로부터 로그인 전 홈 화면 구성, 웨어러블 연동 방식, SNS 공유 정책, 일지 포인트 산정 방식 등 실질적인 방향성과 고려해야 할 제약들을 구체적으로 피드백 받으면서, 서비스에서 어떤 부분을 우선 구현하고 어떤 기능을 후순위로 미뤄야 할지 판단 기준이 훨씬 명확해졌다.
문서를 작성하면서 느낀 점은, 프로젝트의 큰 틀이 잡혀가는 과정이라 뿌듯하고 의미 있는 하루였다.
특히 오늘 정리한 내용들이 단순한 문서가 아니라 팀 전체의 방향성을 맞추는 기준점이 된다는 점에서 책임감도 더 크게 느꼈다. 앞으로 남은 기능 설계와 개발 과정에서도 오늘처럼 근거를 갖고 판단하며 하나씩 쌓아간다면, 더 완성도 높은 결과물을 만들 수 있을 것이라는 기대감도 생겼다.
