3·4단계 유저 스토리와 화면

요구사항을 사용자 입장의 이야기와 인수 조건(Given/When/Then)으로 옮기고, 그 스토리를 화면 상태로 바꿉니다. 인수 조건 번호가 이후 시험과 완료 기준으로 이어지는 출발점입니다.

3단계 유저 스토리#

무엇을 · 왜#

Given/When/Then 형식은 단계 규칙 파일(phases/inception.md)에서 정합니다. 답하고 승인하는 사람은 PO·기획입니다.

따라 하기#

페르소나(운전자 1명), 스토리를 나누는 기준(사용자 흐름 순서), 결제 실패 때의 동작(같은 목록에서 다른 후보로 다시 결제)을 묻습니다. 마지막 질문은 요구사항 검토에서 누락이 지적된 내용입니다.

산출물과 바뀐 점#

inception/user-stories/stories.md에 스토리 9개가 작성되었습니다. 결제 실패 후 재결제(US3.2)가 새로 들어갔고, 스토리마다 인수 조건이 붙었습니다.

## US4.1 결제 승인 직후 예약 완료 보기
As a 운전자, I want to 결제가 승인되면 곧바로 화면에서 예약 완료를 보고, so that 예약이 확정됐다고 안심할 수 있다.
- AC4.1.1 Given 예약이 결제 대기이고 화면이 서버 푸시(SSE)로 연결돼 있을 때, When 모의 PG의 승인 웹훅이 오면,
  Then 웹훅 수신 시각부터 1초 이내에 화면에 예약 완료(주차장, 이용 시간, 결제 금액)가 표시된다.
- AC4.1.2 Given 같은 승인 웹훅이 3번 도착해도, When 처리하면, Then 예약 확정은 정확히 1회이다.

AC4.1.1은 이후 볼트 계획의 완료 기준과 테스트, 추적표에서도 그대로 사용합니다.

4단계 화면 (Refined Mockups)#

무엇을 · 왜#

스토리를 화면 상태와 상호작용으로 옮기고, 입력 방식·화면 구성 요소·접근성 범위를 정합니다. 화면마다 근거 스토리 번호가 붙습니다. 답하고 승인하는 사람은 디자이너·PO입니다.

따라 하기#

입력 방식(텍스트 입력창), 화면 구성 요소 라이브러리(없음, 직접 CSS), 접근성(데스크톱 기본)으로 답했습니다.

산출물과 바뀐 점#

inception/refined-mockups/mockups.md에 화면 상태 8가지가 스토리 번호와 함께 정리되고, interaction-spec.md(상호작용 규칙)와 accessibility-checklist.md가 함께 작성됩니다.

이 문서는 화면 유닛(u4)을 구현하고 테스트할 때 기준이 됩니다.