무엇을 만들지 시험할 수 있는 문장으로 정합니다. 질문지에 답이 쌓이고, 빈칸과 부딪히는 답은 후속 질문으로 되묻고, 답이 요구사항 문장이 되는 과정을 실제 파일로 봅니다.
무엇을 · 왜#
| 만드는 것 | 뜻 |
|---|---|
| 기능 요구 (FR) | 무엇을 해야 하나 |
| 비기능 요구 (NFR) | 얼마나 빠르고 안전해야 하는지와 측정 방법 |
| 합격 기준 | 통과와 실패를 가르는 기준 |
| 출처 표시 | 문장마다 근거가 된 답([Q3], [desc]) |
| 후속 질문 | 답에서 빠지거나 서로 충돌하는 내용 확인 |
답하고 승인하는 사람은 PO·기획입니다. 결과 문서는 inception/requirements-analysis/requirements.md입니다.
따라 하기#
- 본 질문 4개. 최적 기준은 "가격 40%, 거리 40%, 이용 시간 적합도 20%의 종합 점수, 최적 1개와 비교 후보 2개를 이유와 함께"로 직접 답했습니다. 데이터와 결제는 A(목업 데이터 + 모의 결제)를 골랐습니다. 예약 완료 전달은 "모의 PG 승인은 비동기 웹훅, 승인되면 1초 안에 화면 표시, 180초 안에 승인 없으면 자동 취소"로 직접 답했습니다. 로그인은 A(없음)로 답했습니다.
- 후속 질문 3개. 답만으로 정할 수 없는 부분을 다시 묻습니다. 시간 적합도 점수 계산(A), 웹훅 승인 뒤 화면 전달 방식(A, SSE 서버 푸시), 180초를 세는 시점(A, 결제 요청 시점부터)이었습니다.
- 승인. 검토 판정은 NOT-READY였고, PO가 지적된 위험을 수용하고 승인했습니다.
산출물과 바뀐 점#
① 질문지 requirements-analysis-questions.md: 본 질문 4개 아래에 후속 질문 3개가 (후속) 표시로 이어집니다. 직접 쓴 답은 [Answer]: X. …로 남습니다.
## Q3. [개발] 결제가 끝난 뒤 "예약 완료"는 어떻게 사용자 화면에 전달할까요?
[Answer]: X. 모의 PG의 결제 승인은 비동기 웹훅으로 들어오고, 승인되면 1초 안에 화면에 예약 완료를 보여 줘. …
## Q6. [개발] (후속) 웹훅 승인 후 1초 안에 화면에 예약 완료를 띄우는 전달 방식은 무엇인가요?
[Answer]: A
② 요구사항 requirements.md: 맨 위 ## Sources에 출처가 있고, 답이 FR·NFR 문장이 됩니다.
### FR5. 비동기 웹훅 승인 처리
- FR5.3 같은 승인 웹훅이 여러 번 와도 예약은 한 번만 확정된다.
## 비기능 요구사항
- NFR1. 승인 웹훅 수신 시각부터 화면에 예약 완료가 표시되기까지 1초 이내여야 한다 (측정: 로컬 환경, 100건 반복에서 최대 1초).
③ 검토 reviews/review-01.md: 판정은 NOT-READY입니다. 결제 실패 후 동작이 빠졌다는 지적 등이 있었습니다. 빠진 내용은 다음 유저 스토리 단계에서 다시 질문했습니다.
④ 다음에 쓰이는 곳. 유저 스토리와 인수 조건, 도메인 설계, 품질 요구, 테스트 기준에서 이 문서의 FR·NFR 번호를 참조합니다.