FAQ 1 PRD와 SRS가 제대로 나왔는지 v1을 확정하기가 어렵습니다.

PRD와 SRS 통과 조건 충족 여부를 직접 판단하기 어렵다면,

각 문서에 대해 AI 가 검토해준 보고서 기준으로 10턴 이상의 대화를 나누세요.

→ 손을 좀 더럽히자! 뛰어들어서 파악해보자! ⇒ 10턴 이상 동안 발전한 상세 의문사항들을 기준으로 질문해 주세요!

• PRD 품질 검토 기준 및 패스 조건

  항목	기준	패스 조건
  목표·지표	북극성·보조 KPI 수치화	기준선·목표·측정 창구 명시
  스토리·AC (Acceptance Criteria)	Given When Then, SLO(Service Level Objective, 명확한 수치) 포함	실패 케이스 포함 2개 이상
  기능 요구	MSCW(우선순위)·근거·의존성	Could 이상 1스프린트 내 구현 가능성
  비기능	성능·보안·가용성·비용	임계치와 모니터링 항목 명시
  리스크·가정	ADR(Architecture Decision Record) = 제품 구조 설계 이유 기록	비즈니스 가설을 검증하기 위해 적절해야 함, 주요 리스크 3개 이상 및 대응책 명시
  범위	In/Out 명확	PM 의사결정 충돌 없음

• SRS 수용 기준(Definition of Done)

  - PRD의 모든 Story·AC가 SRS의 REQ-FUNC에 반영됨
  - 모든 KPI·성능 목표가 REQ-NF에 반영됨
  - API 목록이 인터페이스 섹션에 모두 반영됨
  - 엔터티·스키마가 Appendix에 완성됨
  - Traceability Matrix가 누락 없이 생성됨
  - UseCase(mermaid로 작성), ERD, Class Diagram, Component Diagram 등 핵심 다이어그램이 모두 작성됨
  - Sequence Diagram 3~5개가 포함됨
  - SRS 전체가 ISO 29148 구조를 준수함(전체 항목 명세를 커버할 필요는 없음)
  

FAQ 2 PRD 와 SRS 최종본 기준 “주제/범위/구현가능성” 진단하기

1) 유지 ( 지금 PRD/SRS 그대로) VS **축소 (**주제는 유지하되 기능/운영 범위 축소) 판단을 어떻게 하는가?

1-1. PoC 수준의 “최소화된” MVP 규모로 줄일 경우의 기준

• CRUD 중심 서비스
• 검색 / 필터 / 저장
• 단순 대시보드
• 외부 API 1개 정도 연동
• 정적 데이터 또는 일괄 업로드
• 관리자 수동 운영이 가능한 구조
• 단일 저장소, 단순 배포
• 인증이 필요하면 최소 수준만
• PMF 검증 대비용 최소 이벤트 설계는 유지
  • 방문 → 핵심 행동 1개 → 전환 또는 저장/재방문 의도

1-2. 초보자로서 실패할 가능성이 높은 MVP 기능 리스트

• 다중 시스템 간 실시간 동기화가 필수인 구조
• 계속 엄밀한 최신 상태를 맞춰야 하는 외부 데이터 파이프라인