11장. PRD (Product Requirements Document)
이 장에서 다루는 것
- PRD의 역할과 방향 문서·허브 문서 개념
- AI와 함께 PRD를 만드는 3단계
- PRD → 정책서·BPMN·DMN·사양서 분기 규칙
도식: PRD 허브 구조: RIB 입력 → PRD → 정책서·BPMN·DMN·사양서·프로토타입·TC 분기
전제 지식: 8장(RIB) — PRD는 RIB의 출력을 입력으로 받는다. RIB 없이 PRD를 작성하면 문제 정의와 범위가 불명확한 채 시작된다.
이 장의 목적
이 장은 RIB에서 정리한 입력을 바탕으로 무엇을 왜 만들 것인가를 정의하는 PRD(Product Requirements Document)의 역할과 범위를 설명한다. 이 책에서 PRD는 모든 것을 담는 만능 문서가 아니다. PRD는 사용자 문제·해결 방향·범위·핵심 시나리오·성공 기준을 정렬하는 방향 문서이자, 정책서·BPMN·DMN·사양서·프로토타입·테스트케이스를 여는 허브 문서다.
이 장을 읽고 나면 다음을 할 수 있어야 한다.
- PRD의 역할과 한계를 설명할 수 있다.
- PRD에 들어가야 할 항목과 실제 템플릿을 이해할 수 있다.
- AI를 활용해 PRD를 만들 때 무엇을 맡기고 무엇을 직접 판단해야 하는지 구분할 수 있다.
- 완성된 PRD가 어떤 조건에서 다음 산출물로 넘어가는지 확인할 수 있다.
1. 이 산출물이 왜 존재하는가
실무에서는 운영·개발·디자인·리더십이 같은 과제를 다르게 본다.
- 운영은 현장의 불편과 예외를 본다.
- 개발은 구현 범위와 기술 제약을 본다.
- 디자인은 사용자 경험을 본다.
- QA는 검증 가능성을 본다.
- 리더는 우선순위와 일정 영향을 본다.
PRD가 없으면 각자 자기 언어로만 과제를 이해한다. 좋은 PRD가 있으면 팀이 다음 질문에 대해 같은 방향을 본다.
- 어떤 문제를 해결하려는가
- 왜 지금 이것을 다루는가
- 이번에 어디까지 할 것인가
- 어떤 시나리오가 핵심인가
- 무엇을 성공으로 볼 것인가
PRD의 가장 중요한 기능은 설명이 아니라 정렬이다.
2. 입력과 출력
2-1. PRD가 받는 주요 입력
| 입력 소스 | 내용 |
|---|---|
| RIB | 문제 정의·범위 초안·이해관계자·제약 조건·확인 필요 사항 |
| 기능 분류 체계 (FT) | 이번 과제가 속하는 기능 영역 |
| As-is 분석 자료 | 현재 운영 현황·기존 정책 문서 |
| 이해관계자 인터뷰 결과 | 우선순위·방향 판단에 필요한 의사결정자 의견 |
| 비즈니스 목표 | 이번 릴리즈의 사업 맥락 |
2-2. PRD가 넘겨주는 출력
| 다음 산출물 | PRD에서 받는 것 |
|---|---|
| Feature 정의 | 기능 목록·우선순위·배제 항목 |
| 시나리오 / AC | 핵심 시나리오·성공/실패/예외 조건 |
| 정책서 | 규칙을 정리해야 할 영역·운영/보안/법무 영향 항목 |
| BPMN | 역할이 얽힌 흐름·운영 개입 지점·예외 흐름 후보 |
| DMN | 조건 조합이 복잡한 판단 규칙 영역 |
| 시스템 아키텍처 | NFR·기술 제약·시스템 경계 |
| 사양서 | 구현이 필요한 기능 범위·외부 연동 포인트 |
| 프로토타입 | 핵심 UX 흐름·주요 화면과 인터랙션 범위 |
| 테스트케이스 | Acceptance Criteria·성공/실패/예외 기준 |
| RTM | 요구사항 원문 ID (추적 시작점) |
핵심 원칙: PRD가 잘 쓰이면 뒤 산출물은 빨라지고, PRD가 비면 뒤 산출물도 흔들린다.
3. PRD 구조와 템플릿
PRD는 9개 섹션으로 구성된다. 모든 항목을 처음부터 완성할 필요는 없다. 다만 핵심 4개(문제 정의·범위·성공 기준·후속 산출물)는 Feature 정의를 시작하기 전에 반드시 확정한다.
3-1. 구성 항목
| 섹션 | 내용 | 비고 |
|---|---|---|
| 개요 | 과제명·작성자·버전·상태(Draft/Review/Approved) | 한 줄 과제 설명 포함 |
| 문제 정의 | 어떤 사용자/운영 문제를 해결하는가 | 현상 + 영향 중심 기술 |
| 배경 및 목적 | 왜 지금 이 과제가 필요한가 | 사업 맥락 포함 |
| 범위 (In / Out of Scope) | 이번에 다루는 것 / 다루지 않는 것 | 명확한 경계선 필수 |
| 핵심 시나리오 | 주요 사용 흐름 3~5개 | 정상·예외·운영 시나리오 포함 |
| 성공 기준 | 무엇이 달성되면 이 과제가 성공인가 | 정량 지표 가능하면 포함 |
| NFR (비기능 요구사항) | 성능·보안·가용성·접근성 등 | 최소 기준 명시 |
| 리스크 및 전제 | 알려진 리스크·가정 | 미확정 전제 드러낼 것 |
| 후속 산출물 | 이 PRD에서 열리는 다음 산출물 목록 | 체인 시작점 명시 |
3-2. 템플릿 (마크다운 형식)
# PRD: [과제명]
작성일: YYYY-MM-DD
작성자:
버전: v1.0
상태: Draft / Review / Approved
---
## 문제 정의
[어떤 사용자/운영 문제를 해결하는가 — 현상과 영향 중심]
## 배경 및 목적
[왜 지금 이 과제가 필요한가 — 사업 맥락 포함]
## 범위
**In Scope:**
- [이번에 다루는 기능/영역]
**Out of Scope:**
- [이번에 다루지 않는 것 — 최소 2~3가지]
## 핵심 시나리오
1. [정상 흐름 시나리오]
2. [예외 흐름 시나리오]
3. [운영/관리자 시나리오]
## 성공 기준
| 지표 | 현재 | 목표 | 측정 방법 |
|---|---|---|---|
| | | | |
## NFR (비기능 요구사항)
| 항목 | 기준 |
|---|---|
| 응답 속도 | |
| 보안 | |
| 가용성 | |
## 리스크 및 전제
| # | 내용 | 유형 | 완화 방안 |
|---|---|---|---|
| 1 | | 리스크/전제 | |
## 후속 산출물
- [ ] Feature 정의서
- [ ] 시나리오 / AC
- [ ] 정책서
- [ ] BPMN
- [ ] DMN (조건 분기 복잡도에 따라)
- [ ] 시스템 아키텍처
- [ ] 사양서
- [ ] 프로토타입
- [ ] 테스트케이스
## 관련 문서
- RIB: [[]]
- Decision Log: [[]]4. AI와 함께 만드는 법
4-1. 흐름 개요
PM → RIB 전달 → AI 초안 생성 → PM 판단·범위 확정 → AI 보완 → PM 최종 승인
4-2. AI에게 맡기는 단계
단계 1: RIB 투입 → PRD 초안 요청
다음 RIB를 바탕으로 PRD 초안을 작성해줘.
[RIB 내용 붙여넣기]
PRD에 포함할 항목:
1. 문제 정의 (현상 + 영향)
2. 배경 및 목적
3. In Scope / Out of Scope 초안
4. 핵심 시나리오 3~5개 (정상·예외·운영)
5. 성공 기준 후보
6. 리스크 및 전제 후보
7. 후속 산출물 목록
주의: 해결안을 문제 정의에 혼입하지 말 것.
Out of Scope에 최소 3가지 명시적 제외 항목 포함할 것.
단계 2: 누락 시나리오 보완 요청
위 PRD 초안에서 다음 시나리오가 커버되는지 확인하고,
빠진 것이 있으면 추가해줘.
- 잠금/차단 상태에서의 사용자 흐름
- 운영자가 예외 처리하는 시나리오
- 데이터 불일치 발생 시 흐름
단계 3: 정책서·BPMN·DMN 후보 추출
위 PRD를 기준으로:
1. 정책서에서 명문화해야 할 규칙 영역 목록
2. BPMN으로 그려야 할 흐름 후보
3. DMN으로 정의해야 할 판단 규칙 후보
를 각각 정리해줘.
4-3. PM이 직접 판단·확정해야 하는 것
| 항목 | 이유 |
|---|---|
| 문제 우선순위 확정 | AI는 조직 맥락·전략 방향을 모름 |
| In/Out Scope 확정 | 이해관계자 조정·사업 방향 반영 필요 |
| 성공 기준 확정 | 측정 가능한 지표는 조직 데이터 기반으로만 결정 가능 |
| 이번 릴리즈에서 포기할 것 | 트레이드오프 판단은 사람만 할 수 있음 |
| 정책서/BPMN/DMN으로 넘길 항목 | 문서 체인 설계 책임 |
원칙: AI는 빈 페이지를 여는 속도를 높인다. 그러나 무엇을 이번에 하기로 결정할 것인가는 사람이 확정한다.
4-4. VS Code + AI 활용 흐름
- VS Code에서 RIB·기존 문서·관련 메모를 함께 연다.
- AI 채팅에게 PRD 섹션 초안을 요청한다.
- 초안을 마크다운으로 정리한다.
- PM이 범위·성공 기준·후속 산출물을 직접 확정한다.
- 정리된 내용을 기준 문서 도구(Confluence·Notion·Obsidian)에 올린다.
- Jira Epic/Story와 연결하고 상태를
Draft → Review → Approved로 관리한다.
→ 프롬프트 예시: wiser-prompt-examples-v1 — 1. PRD 초안 생성 예시, 2. PRD 리뷰 예시
5. 품질 기준 / 체크리스트
5-1. 필수 확인 (이것이 없으면 Feature 정의를 시작하면 안 된다)
- 문제 정의가 현상과 영향 중심으로 작성되었는가 (해결안 미포함)
- In/Out Scope가 명시되어 있는가
- 핵심 시나리오가 최소 3개 이상 있는가 (정상·예외·운영)
- 성공 기준이 있는가
- 후속 산출물 목록이 있는가
5-2. 품질 향상 항목
- 성공 기준에 정량 지표가 포함되었는가
- NFR(성능·보안·가용성)이 명시되었는가
- 리스크와 전제가 드러났는가
- 정책서·BPMN·DMN으로 내려갈 후보가 표시되었는가
- PRD가 공식 기준 문서 도구에 올라가 있는가
5-3. 자주 발생하는 오류
| 오류 유형 | 현상 | 수정 방향 |
|---|---|---|
| 해결안 혼입 | ”화면을 개선해야 한다” — 해결안이 문제 정의에 포함 | 현상과 영향만 기술: “완료율이 낮다” |
| Out of Scope 공백 | 제외 범위가 없음 | 최소 2~3가지 명시적 제외 항목 추가 |
| 성공 기준 추상 | ”사용자 경험 향상” | 측정 가능한 지표로 바꿈 |
| PRD 비대화 | 정책 규칙·API 조건까지 다 포함 | 규칙 → 정책서, 흐름 → BPMN으로 분리 |
| AI 초안과 승인본 혼재 | 어느 것이 공식 기준인지 불명확 | 상태(Draft/Approved) 명시, 기준 문서 도구에 공식본 보관 |
5-4. 실행 가능한 검증 기준
“Feature로 분해 가능해야 한다”는 선언은 PRD를 읽어보면 어느 정도 감이 온다. 그러나 PRD를 승인하기 전에 이 기준을 실제로 테스트할 수 있다. 아래는 텍스트 검토만으로 판단하는 구조 기반 검증과, AI를 실행해서 결과로 판단하는 AI 실행 기반 검증으로 나뉜다.
구조 기반 검증 (텍스트 검토)
| 항목 | 기준 | 판단 방법 |
|---|---|---|
| In Scope 항목 명확성 | 각 항목이 “기능명” 또는 “역할+동작” 형식인가 | ”사용자 경험 개선”처럼 추상 표현이 있으면 탈락 |
| 시나리오 구조 | 핵심 시나리오가 “행위자 + 동작 + 결과” 형식인가 | ”사용자가 X를 하면 Y가 된다” 구조 확인 |
| 성공 기준 정량화 | 성공 기준 항목 중 수치가 포함된 항목이 50% 이상인가 | ”향상”, “개선”, “증가” 단독 표현은 탈락 |
| Out of Scope 충분성 | Out of Scope 항목이 3개 이상 명시되어 있는가 | 항목 수 직접 세기 |
| 규칙·흐름 분리 | 조건 분기(“~이면”, “~인 경우”)나 정책 조항이 본문에 직접 쓰여 있지 않은가 | 있으면 정책서·BPMN 후보로 이동 |
AI 실행 기반 검증
PRD 초안을 AI에게 입력하고 결과물이 나오는지로 판단한다. 결과가 나오지 않거나 기준 미달이면 PRD가 다음 단계로 넘어갈 준비가 안 된 것이다.
검증 1 — Feature 분해 가능성
아래 PRD의 In Scope 항목을 독립 Feature 단위로 분해해줘.
Feature는 독립적으로 개발·배포 가능한 최소 기능 단위로 정의한다.
[PRD In Scope 섹션 붙여넣기]
통과 기준: 독립 Feature가 5개 이상 도출되는가. 5개 미만이면 In Scope가 너무 추상적이거나 범위가 지나치게 좁다.
검증 2 — Scenario 커버 여부
아래 PRD를 기반으로 Scenario 초안을 작성해줘.
각 Scenario는 "행위자 + 전제 조건 + 행동 + 기대 결과" 형식으로 작성한다.
[PRD 전문 붙여넣기]
통과 기준: AI가 생성한 Scenario 초안에서 PRD의 핵심 시나리오(N개) 중 70% 이상이 커버되는가. 예를 들어 PRD에 핵심 시나리오가 5개 있으면 Scenario 초안에 그 중 4개 이상의 흐름이 식별 가능해야 한다. 커버 안 되는 시나리오가 있으면 PRD 해당 시나리오의 서술이 불충분한 것이다.
검증 3 — 정책 조항 추출 가능성
아래 PRD에서 정책서에 명문화해야 할 규칙 후보를 추출해줘.
각 항목은 "조건 + 결과" 형식으로 정리한다.
[PRD 전문 붙여넣기]
통과 기준: 정책 조항 후보가 3개 이상 도출되는가. 3개 미만이면 PRD에 예외 처리나 운영 판단 기준이 충분히 담겨 있지 않다는 신호다.
검증 4 — BPMN 참여자 식별 가능성
아래 PRD의 핵심 시나리오를 읽고 BPMN으로 그릴 때 필요한 참여자(Pool/Lane)를 정리해줘.
[PRD 핵심 시나리오 섹션 붙여넣기]
통과 기준: 참여자가 2개 이상(예: 사용자 + 시스템, 또는 사용자 + 시스템 + 운영자) 식별되는가. 참여자가 1개뿐이면 시나리오에 역할 구분이 없는 것이므로 BPMN으로 넘길 수 없다.
검증 결과 활용
| 검증 항목 | 탈락 시 의미 | 조치 |
|---|---|---|
| Feature 분해 가능성 | In Scope가 추상적이거나 범위 과소 | In Scope를 기능 단위로 재작성 |
| Scenario 커버 여부 | 핵심 시나리오 서술이 불충분 | 시나리오에 행위자·조건·결과 보완 |
| 정책 조항 추출 | 예외·운영 판단 기준 미포함 | 시나리오에 예외 흐름·운영 개입 추가 |
| BPMN 참여자 식별 | 시나리오에 역할 구분 없음 | 시나리오에 역할(사용자/시스템/운영자) 명시 |
4개 검증을 모두 통과한 PRD는 Feature 정의·정책서·BPMN으로 안정적으로 분기된다. 탈락 항목이 있으면 승인 전에 해당 섹션을 보완한다.
6. 다음 단계 연결 규칙
6-1. PRD → Feature 정의 전환 조건
다음 조건이 충족되어야 Feature 정의를 시작한다.
- 문제 정의가 확정되었다
- In/Out Scope가 확정되었다
- 핵심 시나리오가 최소 3개 이상 있다
- 성공 기준이 명시되었다
- PRD 상태가 Approved로 변경되었다
6-2. PRD가 열어주는 병렬 작업
PRD가 Approved 상태가 되면 다음 산출물을 병렬로 시작할 수 있다.
| 병렬 가능 산출물 | PRD에서 받는 것 |
|---|---|
| Feature 정의 | 기능 목록·우선순위·범위 |
| 정책서 초안 (항목 식별) | 규칙 영역·예외 패턴 |
| 시스템 아키텍처 (초안) | NFR·기술 제약·시스템 경계 |
6-3. PRD에서 해결하지 않는 것
PRD는 다음을 결정하지 않는다.
- 세부 규칙과 예외 처리 (→ 정책서·DMN에서)
- 프로세스 흐름 (→ BPMN에서)
- 구현 상세 (→ 사양서에서)
- 화면 설계 (→ 프로토타입에서)
- 테스트 기준 (→ AC·테스트케이스에서)
이런 내용이 PRD에 섞이기 시작하면 PRD는 비대해지고, 뒤 산출물이 PRD와 중복되면서 역할이 흐려진다.
적용 예시: 이커머스 플랫폼 주문·결제·반품 처리 시스템 구축
이 과제의 PRD는 다음을 정리한다.
문제 정의: 주문·결제·반품 정책이 문서마다 다르게 정의되어 있어 구매자·판매자·운영팀의 이해가 불일치하고, 결제 후 취소 가능 시점과 배송 후 반품 허용 기간이 운영 현장에서 수동으로 판단되고 있다.
In Scope: 주문 생성·결제 처리·배송 추적·주문 취소·반품 신청 및 처리·환불 처리·판매자 어드민 주문 관리
Out of Scope: 소셜 커머스 통합·판매자 마진율 정책·멤버십 할인 정책·배송사 추가 선택지 제공
핵심 시나리오:
- 구매자가 상품을 선택해 결제를 완료하고 배송을 추적한다.
- 구매자가 배송 출고 전에 주문을 취소한다.
- 구매자가 배송 완료 후 7일 이내에 반품을 신청한다.
- 판매자 귀책 반품으로 배송비 환불이 필요하다.
- 운영자가 예외 반품(상품 결함 등)을 승인하고 환불을 처리한다.
성공 기준: 취소/반품 정책 일치율 100% / 수동 승인 처리 50% 감소 / 오류로 인한 환불 분쟁 0건
이 정도까지 정리되면 뒤 산출물이 어디서부터 시작할지가 선명해진다.
4분면별 PRD 적용 기준
PRD가 다루어야 하는 내용은 프로젝트 맥락에 따라 달라진다.
| 분면 | PRD에서 가장 먼저 잡아야 하는 것 | 같이 강하게 붙어야 하는 산출물 |
|---|---|---|
| 신규 구축 + 자사 서비스 | 문제 정의·가설·MVP 범위·성공 기준 | Feature 정의·시나리오·AC·프로토타입 |
| 고도화/운영 + 자사 서비스 | As-is 이슈·변경 목적·운영 반영 포인트 | 정책서·BPMN·DMN·테스트케이스 |
| 신규 구축 + 수주형 | 범위 합의·제외 범위·검수 기준·책임 경계 | RTM·일정·고객 검토본 |
| 고도화/운영 + 수주형 | As-is / To-be 비교·영향도·비영향 범위 | RTM·사양서·테스트케이스·Changelog |
4분면 구분이 처음 나오는 독자라면 4사분면별 적용 기준를 먼저 확인하면 좋다.
정리
PRD는 모든 것을 담는 문서가 아니다. 좋은 PRD는 문제·가치·범위·시나리오·성공 기준을 정렬하고, 정책서·BPMN·DMN·사양서·프로토타입·테스트케이스로 안정적으로 분기시키는 허브 문서다.
PRD에서 기억할 세 가지:
- 정렬이 목적이다 — PRD는 팀이 같은 방향을 보게 만드는 문서다.
- 허브 문서다 — 뒤 산출물이 PRD에서 입력을 받는다.
- 세부는 넘긴다 — 규칙은 정책서로, 흐름은 BPMN으로, 구현은 사양서로.
PRD를 산출물 기반 AI 하네스로 다루는 방법
전용 카드 노트: harness-card-prd-v1
앞에서 설명한 PRD의 역할을 실제 실행 구조로 바꾸려면 PRD를 설명 문서가 아니라 다음 AI 작업을 여는 기준 문서로 다뤄야 한다. 핵심은 PRD마다 입력·출력·조건·검증·기록을 붙여서 사람이 어디까지 판단하고 AI가 어디서부터 초안을 만들고 보완할지를 명확히 하는 것이다.
PRD 하네스 카드
| 항목 | PRD 기준 |
|---|---|
| 목적 | 문제·범위·성공 기준을 정렬하고 뒤 산출물의 기준 입력을 만든다 |
| 입력 | RIB, 범위 정의서, 문제 정의서, As-is/To-be 메모, 관련 정책/제약 |
| 출력 | PRD 본문, 후속 산출물 목록, 요구사항 원문 ID, 결정 로그 반영 포인트 |
| 선행조건 | 문제 정의가 합의되었고, 범위 초안과 이해관계자가 확인되었다 |
| AI 작업 트리거 | 입력 문서가 모두 열려 있고 PRD 필수 섹션(문제·범위·성공 기준·후속 산출물)이 채워질 수 있다 |
| AI가 해야 할 일 | PRD 초안 작성, In/Out Scope 정리, 성공 기준 구조화, 후속 산출물 분기 제안 |
| 사람 승인 게이트 | PM이 문제 정의, 범위, 성공 기준, 제외 범위를 최종 확인한다 |
| 검증 기준 | ① AI Feature 분해 시 독립 Feature 5개 이상 도출 ② AI Scenario 초안 생성 시 핵심 시나리오 70% 이상 커버 ③ AI 정책 조항 추출 시 후보 3개 이상 도출 ④ AI BPMN 참여자 식별 시 2개 이상 역할 확인 (상세 기준: §5-4) |
| 기록 | PRD 상태(Draft/Review/Approved), Decision Log, Changelog, RTM 시작점 |
| 운영 환류 | KPI/VOC/장애/운영 이슈가 발생하면 문제 정의·범위·성공 기준을 다시 연다 |
PRD 상태 전이
| 상태 | 의미 | 다음 행동 |
|---|---|---|
| Draft | AI 또는 사람이 초안을 만든 상태 | 누락 항목 확인, 범위/성공 기준 보완 |
| Review | PM/리드가 검토 중인 상태 | 판단이 필요한 항목 확정, 승인 여부 결정 |
| Approved | 공식 기준 문서가 된 상태 | Feature 정의, 정책서, BPMN, DMN, 사양서로 분기 |
| Revised | 운영 환류나 변경 요청으로 개정 중인 상태 | 변경 이유 기록, 영향 산출물 재검토 |
PRD 하네스 운영 규칙
- PRD는
Approved전까지 뒤 산출물의 공식 입력이 아니다. - AI는 PRD 초안과 보완안을 만들 수 있지만, 범위 확정과 성공 기준 확정은 사람이 승인한다.
- PRD가 수정되면 후속 산출물에도 어떤 영향이 있는지 Decision Log와 Changelog에 남긴다.
- 운영 단계에서 KPI 미달, VOC 누적, 장애 패턴이 반복되면 PRD를 다시 열어 환류시킨다.
PRD 하네스 체크리스트
- 입력 문서가 무엇인지 명시되어 있다
- PRD가 넘겨주는 후속 산출물이 명시되어 있다
-
초안 생성 가능 조건과승인 조건이 구분되어 있다 - 사람 승인 게이트가 명시되어 있다
- 검증 기준이 Feature/BPMN/DMN/사양서 분기 기준과 연결된다
- 운영 결과가 PRD로 다시 돌아오는 환류 경로가 있다
다음 장으로의 연결
PRD가 Approved 상태가 되면 두 방향으로 분기된다. Feature·Scenario·AC 정의와 NFR 정의가 동시에 시작된다. NFR 없이 Feature를 쓰면 AC에 성능·보안 조건이 빠지고, 나중에 사양서에서 억지로 끼워 넣게 된다.
PRD에서 NFR로 이동하는 항목
| PRD 항목 | 이동 형태 | NFR에서의 역할 |
|---|---|---|
| 사용자 규모 추정 | 예상 DAU, 동시 접속수 수치 | 성능 기준치(응답시간, TPS) 산정 근거 |
| 서비스 가용성 요건 | ”N시간 무중단” 등 요건 문장 | SLA, RTO, RPO 기준값 |
| 보안·인증 요건 | 인증 방식, 개인정보 항목 목록 | 보안 NFR 항목 입력 |
| 규제·법적 요건 | 적용 법령, 인증 요건 | 컴플라이언스 NFR 항목 |
| 운영 환경 조건 | 배포 환경, 클라우드 여부 | 유지보수성 NFR 항목 |
| KPI 수치 | 전환율·오류율 목표값 | 성능·품질 NFR 측정 기준 |
체인 전환 기준 (PRD → NFR)
| 확인 항목 | 기준 |
|---|---|
| 성공 기준 수치 명시 | KPI가 측정 가능한 수치로 기재되어 있는가 |
| 사용자 규모 추정 존재 | DAU 또는 동시 접속수 추정값이 있는가 |
| 운영 환경 조건 명시 | 배포 환경이 기재되어 있는가 |
| PRD 상태 | Approved 상태인가 |
- 이 장이 결정한 것: 제품 방향·목적·성공 기준·Feature 우선순위
- 다음 장이 시작하는 것: 성능·가용성·보안·유지보수·규제 기준을 수치화