서로 양립할 수 없는 구현을 허용하는 표현을 찾아내고 결정에 필요한 책임자와 근거를 드러냅니다. 제공할 내용: 요구 사항 문서, 제품 및 시스템 맥락, 검토 범위와 관리 체계. 예상 결과: 모호한 위치, 결정 공백, 충돌, 위험, 확인 질문, 준비 상태를 담은 요구 사항 검토.
1
맥락 추가
텍스트는 이 브라우저에 유지됩니다. AILesson Prompts는 이를 모델이나 서버로 보내지 않습니다.
2
프롬프트
채워지지 않은 필드는 플레이스홀더로 표시되므로 프롬프트를 복사하고 편집할 수 있습니다
정확한 제품 요구 사항에서 모호함, 충돌, 누락된 결정을 검토하세요.
PRD, 사용자 스토리, 기준, 다이어그램, 용어, 링크, 버전, 댓글, 결정 기록:
[requirements]
사용자, 업무 흐름, 현재 동작, 플랫폼, 상태, 역할, 데이터, 연동, 제약 조건, 위험, 정책:
[context]
출시, 팀, 책임자, 검토, 심각도, 준비 상태, 환경, 수정 범위:
[review]
정확한 발췌문과 위치를 보존하세요. 주관적인 형용사와 부사, 정의되지 않은 명사와 주체, 모호한 수량 표현, 숨은 기본값, 책임자를 숨기는 수동태, 가리키는 대상이 여러 개인 대명사, 일관되지 않게 사용된 용어, 필요가 제시되지 않은 해결책 서술, 포괄적인 규칙으로 오인된 예시, 그리고 쉽다, 빠르다, 직관적이다, 매끄럽다, 유연하다, 안전하다, 지원하다, 실시간, 일반적으로, 적절하다, 기타 등과 같은 단어를 표시하세요. 각 문제에 대해 해당 표현이 허용하는 실질적으로 다른 구현을 최소 두 가지, 사용자 또는 시스템에 미치는 결과, 심각도, 영향을 받는 요구 사항, 제공된 경우 결정 책임자, 필요한 근거, 중립적인 확인 질문 하나를 나열하세요. 범위 경계, 전제 조건, 발동 조건, 상태 및 전환, 권한, 데이터 출처와 수명 주기, 비어 있음·오류·로딩·오프라인·재시도 동작, 동시 실행과 멱등성, 현지화, 접근성, 개인정보 보호, 보안, 분석, 성능, 호환성, 마이그레이션, 롤백, 종속성, 승인 기준도 검토하세요. 산출물 간의 모순과 결정 기록에 없는 결정을 찾아내세요. 답을 만들어 내거나 해결되지 않은 선택을 사실인 것처럼 다시 쓰지 마세요. 마지막에는 작업을 막는 공백과 막지 않는 공백을 구분하고, 종속성과 위험순으로 정렬한 결정 대기열과 구현 및 테스트 준비 상태를 제시하세요.
기본적으로 비공개프롬프트 구성은 브라우저에서 로컬로 이루어집니다. 조직에서 허용하지 않는 한 기밀 정보를 AI 서비스에 입력하지 마세요.
입력에서 결과까지
적용 예시
구체적인 맥락이 이 레시피를 바로 사용할 수 있는 결과로 바꾸는 방법을 확인하세요
실제 입력
요구 사항 문서
PRD v0.7 섹션 2: '모든 사용자가 인수 책임자를 쉽게 확인할 수 있게 한다. 요청자는 적합한 사람을 빠르게 배정할 수 있어야 한다. 시스템은 적절하게 알리고 실시간으로 업데이트해야 한다. 미배정 사례 및 기타 상황을 지원한다.' 사용자 스토리 AC-4: 'Ready 상태의 인계에서 담당자가 인수자를 선택하면 변경 사항이 저장된다.' 다이어그램 D2에는 요청자가 인수자를 선택하며, 댓글 C18에는 코디네이터도 수정할 수 있다고 적혀 있다. 결정 기록: 웹 프로토타입만 해당, 이번 출시에는 알림 없음, 활성 워크스페이스 구성원만 해당, 정확한 문구는 미정. 다른 사용자 스토리에는 인수자가 있으면 상태가 Assigned로 바뀐다고 되어 있지만 현재 상태 모델에는 Draft, Active, Ready, Accepted만 있다.
제품 및 시스템 맥락
역할: 요청자가 만들고, 담당자가 작업하며, 인수자가 인수를 승인하고, 코디네이터가 워크스페이스를 관리한다. 승인된 내용: 요청자 또는 코디네이터가 선택적 인수자를 설정할 수 있고 담당자는 보기만 가능하다. 감사 로그에는 행위자, 이전 값과 새 값, 시간을 기록한다. 기존 구성원 ID를 사용하며 보존 정책은 변경하지 않는다. 웹만 해당한다. 접근성은 키보드 조작, 프로그래밍 방식으로 식별 가능한 레이블, 색상에만 의존하지 않는 상태 표시를 요구한다. 개인정보 보호 검토 완료. 분석 이벤트 이름과 성능 목표는 미정이다.
검토 범위와 관리 체계
프로토타입 사용성 테스트 출시. 제품팀은 업무 흐름 결정, 디자인팀은 문구, 엔지니어링팀은 상태와 오류 동작, 접근성 담당자는 상호작용 검토, 리서치팀은 테스트 스크립트를 맡는다. 심각도: B는 구현 또는 테스트를 막고, M은 구축은 가능하지만 불일치 위험이 있으며, L은 편집상 문제이다. 준비 완료 조건은 B 공백이 없고, 기준을 테스트할 수 있으며, 디자인 검토가 끝났고, 프로토타입이 작동하며, 단위 및 접근성 검사를 통과하는 것이다. 진단만 하고 최종 요구 사항을 다시 쓰지 않는다.
예시 출력
준비 상태: 준비되지 않았습니다. 구현을 막는 결정 여섯 가지와 여러 중간 수준의 공백이 남아 있습니다.
B1 — 주체 충돌. AC-4에는 '담당자가 선택'한다고 되어 있고 D2에는 요청자, C18에는 코디네이터가 선택한다고 되어 있습니다. 승인된 맥락에서는 요청자 또는 코디네이터가 조작할 수 있고 담당자는 보기만 가능합니다. 이 차이는 서로 양립할 수 없는 인가 및 보안 테스트를 만듭니다. 제품 책임자는 결정 기록과 맥락을 근거로 모든 산출물에서 승인된 규칙을 확인해야 합니다.
B2 — 상태 충돌. 한 사용자 스토리에는 Assigned 상태가 생기지만 승인된 상태 모델에는 Assigned가 없습니다. 구현 시 새로운 업무 흐름 전환을 추가하거나 Ready 상태를 유지한 채 필드 표시만 할 수 있으며, 이는 영속성, 분석, 마이그레이션, 테스트에 영향을 줍니다. 제품팀이 결정해야 할 질문: 인수자 배정이 업무 흐름 상태를 바꾸나요, 아니면 필드 표시만 바꾸나요?
B3 — 알림 모순. '적절하게 알림'은 이메일, 푸시, 앱 내 알림 또는 알림 없음을 모두 허용하지만 결정 기록에는 이번 출시에서 알림이 없다고 되어 있습니다. 수신자, 발동 조건, 반복 동작, 수신 거부도 정의되지 않았습니다. 제품팀은 이번 출시 범위에서 알림을 제거하거나 명시적으로 제외해야 하며 누구도 동작을 만들어 내서는 안 됩니다.
B4 — 자격과 잘못된 데이터. '적합한 사람'은 모든 사용자, 활성 구성원, 역할 자격이 있는 구성원 또는 추천된 사람으로 해석될 수 있습니다. 승인된 범위는 활성 워크스페이스 구성원이지만 승인 기준은 비활성 구성원이나 구성원이 아닌 사람의 제출, 동시에 발생하는 비활성화를 다루지 않습니다. 제품팀과 엔지니어링팀은 관찰 가능한 거부 및 복구 동작을 정의해야 하며 디자인팀은 이후 문구를 담당합니다.
B5 — 미배정 동작. '미배정 사례 및 기타 상황을 지원'은 생성할 때 비워 둘 수 있는지, 나중에 지울 수 있는지, 누가 지울 수 있는지, 어떻게 표시되는지, Ready 상태를 계속 유지할 수 있는지를 정의하지 않습니다. 제품팀이 이를 결정해야 합니다. '기타'는 테스트할 수 없습니다.
B6 — 저장, 오류, 동시 실행. '저장'은 로컬에 낙관적으로 표시하거나 서버 영속성을 확인하는 것으로 해석될 수 있습니다. 로딩, 실패, 재시도, 중복 제출, 두 사람의 편집, 오래된 화면, 감사 동작, 롤백이 누락되어 있습니다. 엔지니어링팀이 선택지를 제안하고 제품팀이 사용자에게 보이는 규칙을 승인해야 합니다.
중간 수준 공백: '쉽게', '빠르게', '실시간'에 측정 기준이 없습니다. 정확한 문구와 분석 이벤트 이름은 명시적으로 미정입니다. 키보드 순서, 프로그래밍 방식으로 식별 가능한 레이블, 오류 후 초점, 색상에만 의존하지 않는 표시에 기준이 필요합니다. '모든 사용자'는 역할별 수정 권한과 충돌하므로 보기와 수정을 구분해야 합니다.
결정 순서: 주체, 상태, 알림 → 미배정과 자격 → 저장, 동시 실행, 오류 → 접근 가능한 상호작용과 문구 → 분석과 성능. B 항목이 관찰 가능한 기준으로 바뀐 뒤에만 테스트 준비가 완료됩니다.
효과가 있는 이유
1
서로 다른 구현 예시는 추상적인 모호함을 결정 책임자가 구체적으로 이해하게 합니다.
2
공백을 종속성순으로 정렬하면 핵심 동작이 결정되지 않은 상태에서 주변 기준만 다듬는 일을 막을 수 있습니다.
결과 확인
모호한 각 항목에 정확한 문구와 실질적으로 다른 두 가지 해석이 포함되어 있나요?
누락된 결정은 알려진 책임자에게만 배정되며 아무도 모르게 해결된 것으로 처리되지 않았나요?
준비 상태가 상태, 권한, 데이터, 실패, 접근성, 개인정보 보호, 테스트, 롤백을 모두 다루나요?
안심하고 사용하세요
자주 묻는 질문
이 레시피를 언제 사용해야 하는지, 무엇을 제공해야 하는지, 그리고 어떤 부분에서 사람의 검토가 여전히 중요한지에 대한 실용적인 답변
제품 요구 사항의 모호함과 누락된 결정을 검토하기 전에 무엇을 준비해야 하나요?
'제품 요구 사항의 모호함과 누락된 결정 검토하기'를 사용하려면 요구 사항 문서, 제품 및 시스템 맥락, 검토 범위와 관리 체계를 준비하세요. 확인할 수 있는 정보로만 자리 표시자를 바꾸세요. 세부 정보를 모른다면 모델이 추론하게 하지 말고 그 불확실성을 명시적으로 유지하세요.
제품 요구 사항의 모호함과 누락된 결정 검토 결과는 언제 사용할 준비가 되지 않은 상태인가요?
제공된 근거를 바탕으로 명시된 결과인 '모호한 위치, 결정 공백, 충돌, 위험, 확인 질문, 준비 상태를 담은 요구 사항 검토'를 아직 제공하지 못했거나, 해결되지 않은 가정, 누락된 승인 또는 지어낸 세부 정보에 의존한다면 사용할 준비가 되지 않은 결과입니다. 점검 항목을 공개 여부를 결정하는 기준으로 삼으세요. 근거 없는 결과를 다듬는 대신 원본 입력을 수정하거나 이름과 권한이 명확한 검토자에게 검토를 요청하세요.
제품 요구 사항의 모호함과 누락된 결정 검토에 대해 테스트 기록이 있는 AI 도구는 무엇인가요?
2026-08-28 기준으로 공개된 '제품 요구 사항의 모호함과 누락된 결정 검토하기'의 테스트 기록에는 ChatGPT가 기재되어 있습니다. 이는 실행 기록이 있다는 뜻일 뿐, 이후 버전에서도 호환되거나 같은 결과가 나온다는 보장은 아닙니다. 다른 도구나 버전을 사용할 때는 모든 제약 조건을 명시하고 사용 전에 결과 점검을 다시 수행하세요.
ChatGPT
