프로젝트 개요
•
프로젝트명: 굿오더 (GoodOrder)
•
선택 주제: 프로젝트 A - 음식 또는 음료 주문 소프트웨어
•
팀장: 2112 이기찬
•
팀원: 2118 이상은
1단계: 요구 분석
문제 상황 정의
•
대상: 고객, 매장 직원, 관리자
•
장소: 패스트푸드 매장
•
목적: 주문 효율 향상 및 실시간 주문 처리 시스템 구축
문제 상황 설명:
고객은 대기 시간과 복잡한 메뉴 선택에 불편을 느끼며, 직원은 주문 실수나 과다 주문에 대한 문제를 겪고 있다. 관리자는 실시간 매장 데이터를 파악하기 어렵다.
이 문제를 해결하기 위해 고객은 키오스크에서 빠르게 주문하고, 직원은 실시간 주문을 확인하며, 관리자는 데이터를 분석할 수 있는 소프트웨어를 개발한다.
유사 소프트웨어 분석
•
이름: 토스 플레이스
•
주요 기능:
◦
고객이 단말기로 직접 주문 가능
◦
재고 관리 간편
◦
진동벨 및 다양한 시스템 연동
◦
비 음식 업종과도 호환 가능
인터뷰 및 기능 요구사항 추출
핵심 인터뷰 요약
사용자 | 질문 | 답변 |
매장 직원 | 주문 확인 시 불편한 점은? | 외부에서도 휴대폰으로 확인하고 싶다 |
관리자 | 기존 메뉴 추가 방식은? | 키오스크 회사에 요청해야 했고, 직접 관리하고 싶다 |
고객 | 키오스크 사용 시 불편한 점은? | 카테고리별 메뉴, 결제 전 주문서 확인 기능이 필요 |
기능 요구사항 정리
1.
고객은 1개 이상의 상품을 주문서에 넣고 확인할 수 있어야 한다.
2.
매장 직원은 주문을 모니터 또는 휴대폰으로 확인할 수 있어야 한다.
3.
관리자는 메뉴를 추가하고 메뉴의 카테고리를 설정할 수 있어야 한다.
도메인 사전
개념 | 유형 | 설명 |
음식 주문 | 기능 | 매장 직원에게 음식을 주문하는 행위 |
주문 확인 | 프로세스 | 매장 직원이 고객 주문 내역을 시스템으로 확인하는 절차 |
2단계: 유스케이스 모델링
액터 목록
•
고객
•
매장 직원
•
관리자
유스케이스 목록
•
음식 주문
•
주문서 확인
•
결제수단 선택
•
결제
•
주문내역 확인
•
메뉴 관리
•
데이터 확인
•
카테고리 관리
유스케이스 다이어그램
유스케이스 명세
•
시스템 이름: 상품 결제 시스템
•
유스케이스 이름: 결제
•
액터: 고객
•
시작 조건: 주문서에 상품이 1개 이상 있어야 한다.
기본 흐름:
1.
고객이 결제하기를 선택한다.
2.
주문서 확인을 선택하여 주문서를 확인한다.
3.
고객이 확인을 선택한다.
4.
시스템이 결제 수단을 표시한다.
5.
고객이 결제 수단을 선택하면 시스템이 안내를 제공한다.
6.
결제가 완료되면 주문서가 주문내역에 추가된다.
7.
데이터베이스에 주문 내역이 저장된다.
대안 흐름:
•
6A: 결제를 실패하면 다시 안내하고, 계속 실패하면 오류 메시지를 표시한다. 고객은 메시지를 인식하고 유스케이스를 종료한다.
종료 조건: 주문 내역이 데이터베이스에 저장된다.
3단계: 분석 결과 공유
팀장: 이기찬
•
맡은 역할: 기능 요구사항 추출, 도메인 사전 작성, 유스케이스 다이어그램 작성
•
소감:
프로젝트를 요구사항 분석부터 시작해 유스케이스 다이어그램까지 완성해보며 사용자 중심의 분석의 중요성을 체감했다.
특히 draw.io를 통해 시각적으로 표현하는 작업이 흥미로웠으며, 팀 프로젝트를 통해 혼자일 때 보지 못했던 관점을 경험했다.
팀원: 이상은
•
맡은 역할: 문제상황 정의, 기능 요구사항 정리, 유스케이스 명세 작성
•
소감:
요구분석과 유스케이스 모델링이 실제 개발에 얼마나 중요한지를 느꼈다.
단순한 시스템이라도 이런 과정을 거치면 더 정확하고 명확한 기능 구현이 가능하다는 확신을 얻었다.
발표 후 피드백 소감
•
주요 피드백: 인터뷰 기반 기능 요구사항이 구체적이어서 좋았으나, 유스케이스 간의 관계(포함/확장)를 더 명확히 구분하면 좋았다는 피드백을 받았다.
•
배운 점:
포함 관계와 확장 관계의 구분은 기능 흐름 제어에 중요한 역할을 하며,
예를 들어 결제는 주문서 확인을 포함하고, 결제 실패는 확장 흐름으로 처리해야 한다는 점을 배웠다.