Audit product requirements for ambiguity and missing decisions

작성자: AILesson9 분 소요테스트::ChatGPT검토일: 2026-08-28

빠른 답변

Find language that permits incompatible implementations and expose the owner and evidence needed to decide. 제공할 내용: Requirement document, Product and system context, Review scope and governance. 예상 결과: A requirement audit with ambiguity locators, decision gaps, conflicts, risk, clarification questions, and readiness status.

맥락 추가

텍스트는 이 브라우저에 유지됩니다. AILesson Prompts는 이를 모델이나 서버로 보내지 않습니다.

Requirement documentProduct and system contextReview scope and governance

프롬프트

채워지지 않은 필드는 플레이스홀더로 표시되므로 프롬프트를 복사하고 편집할 수 있습니다

Audit the exact product requirements for ambiguity, conflict, and missing decisions.

PRD, stories, criteria, diagrams, terms, links, versions, comments, and decision log:
[requirements]

Users, workflows, current behavior, platforms, states, roles, data, integrations, constraints, risks, and policies:
[context]

Release, teams, owners, reviews, severity, readiness, environments, and rewrite scope:
[review]

Preserve exact excerpts and locators. Flag subjective adjectives and adverbs, undefined nouns and actors, vague quantifiers, hidden defaults, passive voice hiding responsibility, pronouns with multiple referents, terms used inconsistently, solution statements without need, examples mistaken for exhaustive rules, and words such as easy, fast, intuitive, seamless, flexible, secure, support, real time, normally, appropriate, and etc. For each issue list at least two materially different implementations the wording permits, user or system consequence, severity, affected requirement, decision owner if supplied, evidence needed, and one neutral clarification question. Also audit scope boundaries, preconditions, triggers, states and transitions, permissions, data source and lifecycle, empty/error/loading/offline/retry behavior, concurrency and idempotency, localization, accessibility, privacy, security, analytics, performance, compatibility, migration, rollback, dependencies, and acceptance criteria. Identify contradictions across artifacts and decisions absent from the log. Do not invent answers or rewrite unresolved choices as facts. End with blocked versus non-blocking gaps, a decision queue ordered by dependency and risk, and implementation/test readiness status.

Playground에서 사용해 보기

기본적으로 비공개프롬프트 구성은 브라우저에서 로컬로 이루어집니다. 조직에서 허용하지 않는 한 기밀 정보를 AI 서비스에 입력하지 마세요.

입력에서 결과까지

적용 예시

구체적인 맥락이 이 레시피를 바로 사용할 수 있는 결과로 바꾸는 방법을 확인하세요

실제 입력

Requirement document: PRD v0.7 section 2: 'Make acceptance ownership easy to see for all users. Requesters should be able to quickly assign the right person. The system should notify them appropriately and update in real time. Support unassigned cases and etc.' Story AC-4: 'Given a Ready handoff, when the owner selects an accepter, then the change is saved.' Diagram D2 shows requester selecting accepter; comment C18 says coordinator may edit. Decision log: web prototype only; no notifications this release; active workspace members only; exact copy pending. Another story says status becomes Assigned when accepter exists, but current state model contains Draft, Active, Ready, Accepted only.
Product and system context: Roles: requester creates; owner does work; accepter authorizes acceptance; coordinator administers workspace. Approved: requester or coordinator may set optional accepter; owner may view only. Audit log records actor, old/new value, time. Existing member IDs; no retention change. Web only. Accessibility requires keyboard, programmatic label, non-color status. Privacy review complete. Analytics names and performance target unresolved.
Review scope and governance: Prototype usability-test release. Product owns workflow decisions, Design owns copy, Engineering owns state and error behavior, Accessibility reviews interaction, Research owns test script. Blocker severity: B prevents implementation/test; M permits build but risks inconsistent behavior; L editorial. Ready requires no B gaps, testable criteria, reviewed design, working prototype, unit and accessibility checks. Diagnose only; do not rewrite final requirements.

예시 출력

Readiness: not ready; six blocking decisions and several medium gaps remain.

B1 — actor conflict. AC-4 says “owner selects,” D2 says requester, C18 says coordinator, while approved context allows requester or coordinator and makes owner view-only. These permit incompatible authorization and security tests. Product owner must confirm the approved rule in every artifact; evidence is the decision log/context.

B2 — state conflict. One story creates Assigned, but the approved state model has no Assigned state. Implementations could add a new workflow transition or keep Ready with a field indicator, affecting persistence, analytics, migration, and tests. Product owns: does accepter assignment change workflow state or only field presentation?

B3 — notification contradiction. “Notify appropriately” permits email, push, in-app, or no notification; the decision log says no notification this release. It also leaves recipient, trigger, repeat behavior, and opt-out undefined. Product must remove or explicitly exclude notification for this boundary; no one should invent behavior.

B4 — eligibility and invalid data. “Right person” could mean any user, active member, role-qualified member, or suggested person. Approved boundary is active workspace member, but AC does not cover inactive/non-member submission or concurrent deactivation. Product/Engineering must define observable rejection and recovery; Design owns later copy.

B5 — unassigned behavior. “Support unassigned cases and etc.” does not define whether empty is allowed on create, clear is allowed later, who may clear, how it appears, or whether Ready can continue. Product owns these decisions; “etc.” is not testable.

B6 — save/error/concurrency. “Saved” could mean optimistic local display or confirmed server persistence. Missing: loading, failure, retry, repeated submission, two editors, stale view, audit behavior, and rollback. Engineering proposes options; Product approves user-visible rule.

Medium gaps: “easy,” “quickly,” and “real time” lack measures; exact copy and analytics names are explicitly pending; keyboard order, programmatic label, focus after error, and non-color indicator need criteria. “All users” conflicts with role-specific edit permissions and should distinguish view from edit.

Decision order: actor/state/notification → unassigned and eligibility → save/concurrency/error → accessible interaction/copy → analytics/performance. Test readiness follows only after B items become observable criteria.

효과가 있는 이유

1
Competing implementation examples make abstract ambiguity concrete for decision owners.
2
Dependency-ordered gaps prevent teams from polishing criteria around an undecided core behavior.

결과 확인

Does every ambiguity include exact text and two materially different interpretations?
Are missing decisions assigned only to known owners and never silently resolved?
Does readiness cover states, permissions, data, failures, accessibility, privacy, testing, and rollback?

안심하고 사용하세요

자주 묻는 질문

이 레시피를 언제 사용해야 하는지, 무엇을 제공해야 하는지, 그리고 어떤 부분에서 사람의 검토가 여전히 중요한지에 대한 실용적인 답변

What should I prepare before using “Audit product requirements for ambiguity and missing decisions”?

For “Audit product requirements for ambiguity and missing decisions,” prepare Requirement document, Product and system context, and Review scope and governance. Replace placeholders only with information you can verify. If a detail is unknown, preserve that uncertainty explicitly instead of asking the model to infer it.

When is the “Audit product requirements for ambiguity and missing decisions” result not ready to use?

The result is not ready if it does not yet deliver the stated outcome—A requirement audit with ambiguity locators, decision gaps, conflicts, risk, clarification questions, and readiness status—from the supplied evidence, or if it relies on unresolved assumptions, missing approvals, or invented details. Use the checks as release gates: revise the source inputs or assign a named, authorized reviewer instead of polishing an unsupported output.

Which AI tools have recorded tests for “Audit product requirements for ambiguity and missing decisions”?

The published test record for “Audit product requirements for ambiguity and missing decisions” lists ChatGPT as of 2026-08-28. This confirms recorded runs, not guaranteed compatibility or identical results in later product versions. For another tool or version, keep every constraint visible and repeat the result checks before use.

더 많은 탐색 방법